Have you ever wondered what happens if you don’t renew your premium WordPress theme?
Different sites treat licensing differently, but the rule of thumb is:
You remain in control of your theme after your upgrade license has expired.
Yes, you no longer have access to theme updates.
If you run a really straightforward, minimalist theme, this shouldn’t be a serious problem.
However, complex themes — especially the bloated multipurpose themes with galleries, sliders, and what not benefit from frequent updates for multiple reasons:
Security fixes for libraries and frameworks used in the theme. These get patched by the corresponding teams for each library and responsible theme authors are supposed to keep your theme safe.
Incompatibilities when library patches are applied. Oftentimes JavaScript errors breaking features or styling messed up in certain places.
Additional compatibility patches for popular plugins out there (which you are likely to use at the moment or later on).
Improved support for page builders, sliders, and other integral plugins used by the theme.
Occasional new features.
Patches in compliance with WordPress Core updates, especially when large features like Gutenberg get introduced.
Probably new Gutenberg blocks or better interoperability with editable pages.
Are WordPress plugins highly overrated in terms of expecting each of them to work flawlessly on production?
Yes, totally overrated.
People keep mixing up multiple complex, heavy plugins, expecting them to behave as they have been authored by the same development shop.
(Honestly, even if they were, compatibility would still be a chore.)
I was recently reviewing a pull request by a team member. Yoast SEO, being among the most popular plugins ever, and the leading SEO plugin, was almost as large (codebase-wise) as the core of WordPress itself.
So you’ve got hundreds of contributors developing the core software over the course of 16 years. Resulting in 600,000+ lines of code.
Add a few complex plugins and suddenly, your project ends up with 2,000,000+ lines of code to maintain, expected to work flawlessly.
Now imagine:
A script that crowdsources 2,000,000 sentences from Wikipedia and bundling this into a book. Do you foresee this book as a piece of work that makes any sense at all, with chapters following a logical sequence?
Or 2,000,000 audio files in the same “album” that you can shuffle easily?
Even 2,000,000 LEGO pieces will likely be incompatible (coming from different sets over time).
WordPress plugins may adhere to well-designed coding standards. But you still end up with random bits of code that try to control the same environment, fighting for power, causing mishaps and overriding each other.
So every time you pick a few plugins and expect them to just work in a complex environment with a large, messy team and other plugins:
Don’t.
WordPress Plugins in Building MVPs
Now, in terms of proof of concept and building MVPs?
WordPress plugins are absolutely brilliant.
Test an integration with a complex CRM? Done, there’s likely a plugin for that.
Or a marketing automation software? Checked.
Would a membership solution match the UX model of your eCommerce store? Just try this out on a staging environment and see.
Rapid testing or running a demo pitch is blazingly fast when it comes to WordPress, thanks to the broad suite of available plugins.
But realistically, businesses don’t use them out of the box, override them, fork them, do something else.
Plugins are often a good foundation for starters — or an inspiration for implementational workflow in larger WordPress websites or projects. This doesn’t mean that they are being used out of the box all the time.
Of course, not all of them are bad, but there are plenty of reasons why some programmers fail to meet their web development project deadlines.
Top Reasons Programmers Have Issues Meeting Project Deadlines
Comics from www.dilbert.com
Vague Assignment
One of the most frustrating challenges that programmers face in web development projects is dealing with vague assignments. When project requirements are not clearly defined, it becomes exceedingly difficult to set realistic deadlines.
A vague assignment often leads to a vague deadline, creating a cycle of uncertainty that can derail a project’s timeline.
Incomplete Assignment
A specification may appear to be long and thorough – but it doesn’t prevent people from misinterpreting even the slightest details.
Context and Environment
An estimate is given for the feature set described in the proposal in a “vacuum” environment. Third-party services or solutions, vendors, assets, any other dependencies could adjust the scope or postpone the project.
Lack of Experience
Inexperienced developers are more likely to vastly underestimate an assignment. Once you go through a few dozen insanely overtime/over budget projects, you develop a 7th sense for scope creep.
Limited Industry Or Business Experience
A software developer may build something that works – and yet, that piece may not satisfy a customer. The fact that a feature “solves a problem” doesn’t necessarily equate to solving the problem for the right target audience within another project, depending on their industry expectations and more.
Scope Creep
The original assignment may actually evolve over time. My favorite client quotes are: “It was expected”, “It’s common sense”, “Of course this was a part of the assignment”. Obviously, it wasn’t quoted and agreed on.
Inefficient Estimation Process
There are dozens of approaches when estimating projects. Most of those evolve within organizations based on former experience with existing projects. Those techniques may include a series of steps, diagrams, office discussions in order to calculate the “best-case, realistic, worst-case” scenario.
I’ve tried the “estimation poker” with random estimates by several team members and comparing the edge cases. There’s also “top to bottom” and “bottom to top” – two popular techniques.
No Discovery Process
Regardless of the requirements, a lot of those caveats could be revealed during a proper discovery session. This should usually be billed within the contract and charged before sending the offer.
The discovery session may take a few weeks with regular meetings and internal discussions breaking everything down into semantic and actionable tasks that are easy to assess. This also includes the R&D phase for new features, services, tools to be evaluated before proceeding further.
Security, Performance, Scalability
A few of the common areas that require an overview before sending a proposal. We have worked with banks and telecoms requiring a completely different state of security, complex SLAs or certain requirements for concurrent users or a daily number of transactions.
Those are often requirements projecting some growth over the next months/years which should be discussed and estimated upfront.
Contract Loopholes
Many of those areas can and must be covered in the contract. I’ve seen formal proposals with a lengthy section covering the things which would NOT be supported in the platform exclusively – protecting against the type of scope creep requiring a complete revamp of the system.
The same goes for the number of revisions for design iterations, expected manageable load (users, traffic, data), load times and any other KPIs that are to be expected upfront.
The Bottom Line
I generally do avoid estimates whenever I can and use a series of different strategies in order to assess scope, budget, time frames (on top of applying agile in-house).
And more things worth mentioning.
Web development is a form of craft. It’s a service – not a product. It can’t be manufactured when you ask for a custom build. The reason why electronic devices or books are priced with a fixed amount is due to a repeatable and predictable process.
Since there is “uniqueness” in each and every web development project, some buffer is to be scheduled upfront. It’s often not enough and this has to be discussed prior to signing a contract.
Development is generally a combination of science, art, and craft. There’s a certain amount of knowledge to be consumed. It has to be practiced similarly to every other job. And there is the “art” which is often overlooked.
A developer has to maintain a state of focus within a normalized environment for maximum productivity. Any professional (meetings, errands) or personal (lack of sleep, cold) deviations will inevitably lead to delays or mistakes which could expand the scope or miss the deadline of a project – unless managed professionally.
If you want to steer clear, drop your plan of including your WordPress knowledge in your resume.
There are two possible scenarios:
The business won’t benefit from you having experience with WordPress so this would be relevant to the job application
The business may require some proficiency in WordPress and you would want to clarify your level of experience to avoid ambiguity
It’s hard to “gauge” your experience with WordPress, being one of the reasons this question is tricky in the first place. We get hundreds of CVs mentioning WordPress every month but since we’re a development agency, it’s an important keyword many rely on getting noticed.
And yet, half of them can’t tell a WordPress dashboard from a bank reporting software.
If you’ve spent 20ish hours as a part of a VA job or playing with a blog of yours, you can mention “Basic experience using WordPress” or so. If you’ve installed some sites for friends and family, searching for plugins and themes, digging into hosting panels, you can be “promoted” to a “WordPress power user”.
Basic features for basic template use (most functional ones are prohibited in the repo)
Additional CSS assets
Usually known libraries (both CSS and JS) for grids, jQuery add-ons, things like that
I had reviewed a hundred themes back in the day. 80% of them are similar.
The file/folder structure is almost identical.
There is a comprehensive process that goes through a sample set of data, covering known edge cases:
Large images overlapping the area
Long headlines
Archive pages
Pagination
Supporting all reasonable HTML tags like tables or <pre>
Child pages
Plugins are completely unique (and random at times.)
The team is small, just a handful of people who are employed elsewhere (they have “day jobs”, so to speak.)
And they tend to receive dozens of plugins on a daily basis.
Some may seem simple – 300 lines of code, straightforward use of filters and actions, all good.
What about:
Caching plugins?
eCommerce?
Membership?
Social media?
3rd party integrations by random SaaS?
It gets ugly, quickly.
What Makes The Review Process Complicated
So the team performs a general security review, confirming the leading best practices (code quality and using appropriate hooks). Things can, however, fall through the cracks.
More importantly…
Updates are not reviewed.
A plugin author can push multiple updates on a daily basis. With tens of thousands of available plugins in the repository, this would require an army of hundreds of full-time developers performing code reviews and actual usability tests.
This gets significantly more complicated when you consider the endless suite of use cases (combinations of dozens of plugins with a random premium theme on a $2/mo hosting plan with different content types).
This is what makes the review process complicated.
For the most part, things look fine. Every now and then, a security vulnerability may be disclosed. Performance and instability (regression) problems are observed quite a lot, too.
There are three separate responsibilities to make a multilingual WordPress site happen:
A technical matter, an implementation/tooling process, and a content/marketing assignment.
From a purely technical perspective, “redirecting users to the corresponding version” and providing options for a multilingual WordPress site is doable with different plugins out there.
The outcome depends on your content structure and the selection of a translation tool in use for the site.
Translations are a small part of the equation.
Some plugins are more flexible than others. More complicated cases would require a lot more to be compatible than merely translating a label into several languages.
For instance, 100 English posts may only have 30 translations in German or French. Opening the category in German shouldn’t display all 100 posts, but just the ones in the corresponding language. Or if the category label isn’t translated, this menu may be missing in general.
Entire sections or snippets may be missing in certain versions.
eCommerce is a great example here. Are all of your products available in every country and for every language?
Prices will likely be different, even in different currencies.
Medical products usually require approval by the local FDAs or other government structures per country, and even browsing a given language version is not enough if the IP corresponds to a different country.
The Semantics of Translation
So, content translation is separated into two areas: code and the database.
The translation plugins usually manage the database, usually aiming to support multilingual content such as posts, pages, custom fields, menu items, widget labels.
Automatic translation is rarely an option. Some plugins support that but this tends to backfire, which is why manually translating every piece is the industry standard.
Code translation will require a bulk translation of every single translatable multilingual string. The WordPress core already supports that but every single theme (and a plugin) comes with different rules.
The more popular plugins support multiple programming languages, though the final selection isn’t as rich. Starting with Spanish, German, French is more common, but you may be having a hard time looking for a full suite of plugins with Macedonian or Akan or Malay.
This is why you want to:
Ensure that all strings in every theme/plugin are marked as translatable
Finding multiple English versions in themes/plugins is rare because the differences are just a few and it’s a low priority for most plugin authors.
To sum this up, what you need to prepare in this case to ensure a multilingual WordPress site are the following:
List down the languages or variations you want to support
Finalize the list of plugins/theme you’ll be using (or swap some of them for those that support multilingual applications better)
Extract all translatable code snippets based on the localization guide linked earlier
Translate each plugin and the theme into each of the languages you want to support
Install a multilingual plugin like Polylang or WPML based on your business needs for a website (after some research of what they support and what you actually need)
Install the pro version of Polylang or a plugin like Geo Redirects
I believe that when it comes to choosing a top-level domain, this is subjective and depends on the industry/target market. But despite the fact that more and more top-level domains (TLDs) are getting introduced, .com still carries a lot of value, especially for US and international businesses that can’t benefit from a local TLD.
Both the original question and Eilon Reshef’s answer suggest that .io is common. I can only enumerate a small subset of .io B2B SaaS startups that have been around for longer than 2 years. Moreover, I went to SaaS 1000: List of the Top SaaS Companies and scanned through the first 300 startups – over 90% of those use .com domain names.
It also includes some company domains that are not necessarily SaaS – but still aggregate enough data.
Startups related to development/technology or big data could probably go with a .io domain. Otherwise, I don’t think it’s truly practical in most cases.
Some Tips When Looking for A Top-Level Domain
I’d make a good effort to get a .com domain.
Or even contact the original domain owner and get a quote on buying it.
You can also use a domain auction service to find similar domain names.
Check with a domain generator app that shuffles some handy names and verifies for the available domains.
Figure out a suffix that could be combined with a domain – like Delicious or something that ends up in .us, .co, .it, .uk, .me.
Sure, most .com domains are already purchased. Some are still available – especially for names that don’t use an actual dictionary word.
A domain name is a single element in a larger marketing and branding strategy. Product quality, customer service, marketing efforts, and operational efficiency substantially impact your business’ success.
Business isn’t static. Your understanding of your audience, product, and branding will evolve. What seems like a mistake today, like your domain name, could become an asset tomorrow—or at least become a non-issue as your business grows and adapts.
At the end of the day, picking the wrong domain won’t kill your business.Great startups can pivot and generate enough traction which even lets them change their domain later (such as Buffer or Sumo).
But even Buffer went for bfffr.com and later bufferapp.com instead of an alternative TLD. Sumo was SumoMe.com earlier. Twitter started as twttr dot com. Dropbox couldn’t get their existing domain and used getdropbox dot com.
While that was early on, I feel that everyone is quite attached to a good old .com domain.
Real developers are platform-agnostic and often language-agnostic since the concepts of software development revolve around solving business problems through algorithms, using data structures and paradigms embedded in the OS layer, web servers, the networking infrastructure and more.
WordPress developers are software (or web) developers who are familiar with the WordPress Core codebase and its APIs. They are in charge of building applications on top of the WordPress platform.
That may require theme development, framework design, creating plugins and extensions from scratch, scaling WordPress multisite networks, troubleshooting performance, security, stability issues.
Building a WordPress projectrequires a theme as well – serving the presentation layer of the website. Theme developers are those who profile in building themes. Site builders/customizing folks are those who may tinker with some CSS and HTML here and there and know a couple PHP actions or very basic jQuery.
The theme itself should be kept simple and to the point. Features are built as WordPress plugins in order to avoid a vendor lock. This is common with premium theme users. Whenever a theme contains new features, switching to a new theme would prevent the site owner from leveraging those as they are an integral part of the previous theme.
Themes or Frameworks WordPress Developers Specialize In
For theme developers – or capable WordPress programmers who are also in charge of the presentation layer – specializing in a certain framework may be an “okay” option.
Underscores is a good starter theme that requires CSS but provides a standardized markup that works in most cases.
Genesis is not a framework by definition as you can’t integrate it into an existing product (theme). It’s a parent theme that happens to have a large collection of child themes that are added on top of the core product. It adds on top of what’s available in the parent theme.
Genesis is generally stable, compliant, and fast. I’m not a fan of its architecture as it requires you to remove areas instead of building atop a foundation. It’s popular and works well in certain cases – and some people have specialized in building on top of it.
If you’re looking for a starter theme that’s overall flexible and stable, Genesis may do the work. However, I’d suggest starter themes like Underscores for theme developers and using the right titles for the different roles (or people) working in the WordPress ecosystem.
I studied Informatics, but we had several Economics classes as well during the first year. My professor was a Deputy Minister of Economic Development – a bright, wise, experienced industry professional who taught us a lot.
During the very first lecture, he said:
While pursuing a professional degree, you become public personas. Being able to express your thoughts and communicate with various audiences is mandatory. You represent the society and the future of the nation is dependent on clear and concise discussions and conversations with different parties.
That really sunk in, and I truly enjoyed the experience, having led technical training classes already.
In the age of personal branding, an industry expert should always try to improve professionally. Building a portfolio, creating a professional network, and engaging in influential activities are important for career growth and expanding one’s horizons.
Speaking at WordCamps may be a good branding exercise as someone involved in the WordPress community. Most WordCamps gather various profiles together – developers and designers, business owners, reps at hosting companies, product teams, bloggers.
WordCamp organizers often have a hard time gathering a good pool of speakers. I’ve co-organized local WordCamps several times and participated in the speakers selection for WordCamp Europe two years in a row.
From my experience, local events get less exposure and fewer suitable applicants – even though they often gather 300–400 people together. If there are two tracks of speakers in a single day, that makes 14–16 available speaker slots on average.
A WordCamp may receive 30–50 applications while the majority of those may not be quite suitable. Some applicants are outright self-promotional. Many lack speaking expertise or involvement in local meetups or communities.
There’s also an overlap with topic suggestions. WordCamps generally strive for some form of diversity – topics for different audiences, as well as covering the latest and greatest happening in the WordPress ecosystem.
If you’re actively involved in the WordPress world and have a great case study (or a professional tutorial) to share, definitely apply. The first talk or two may be challenging for you – but you’ll get used to them with time. Videos are generally uploaded on WordPress.tv and you can share them as training materials with colleagues or mentees.
It’s also a great way to support the WordPress community itself. Giving back is important since WordPress is a free software application that allows millions of people to earn a living.
