Is WordPress suitable for large and complex WordPress websites? You should be concerned about building any complex project regardless of the underlying framework or a CMS.
Let me quote the original scope from the comment before discussing further:
I am currently in the process of obtaining quotes to build a website. The website is likely to be quite complex, with two user groups (e.g.buyers and sellers), payment system, etc. Should I be concerned by a quote from a web designer who proposes to build it within WordPress?
WordPress Platform Fundamentals
The first thing to consider is the high-end scope of your application. You’ve enumerated several key features:
- Some sort of a traded service/product
- Different user panels for both roles
You may be looking into additional features such as messaging, archive pages for solutions or available service providers, a search engine, etc.
Alternatives Of WordPress
If we ignore the preferred programming language for a second, the three high-end alternatives for starting a project are:
- Building an application from scratch
- Using a development framework and building upon
- Starting with a CMS like WordPress, Drupal, Joomla
The leading factor for selecting the first option is efficiency. Your application would be built from the ground – custom-tailored to your business needs.
There are several drawbacks to that “ideal” scenario:
- It would require a team of rock-solid engineers. Any deviations would drastically impact the end quality.
- It would take a ton of time since every single bit would be custom-made.
- It would cost a fortune for the reasons described above.
- The QA phase may take forever – too many new components that require thorough testing from all parties involved in the process.
- You cannot leverage existing features available as add-ons, modules, or plugins in existing CMS
The CMS approach solves most of those problems, however:
- You still need an expert team for a complex platform. The slightest oversight may cause ongoing stability or performance issues for the application.
- There would be some components that persist in the platform without taking advantage of them. It’s slightly discomforting and impacts the load times.
- The existing infrastructure of the platform (dashboard, APIs) may not be ideal for your business case.
The framework approach is somewhere in the middle. You get pros and cons from both scenarios.
Functional Analysis With WordPress
WordPress is a proven CMS that handles various applications handling millions of users and tens or even 100M views a month. From my experience, scaling from 10M to 50M is feasible, 50M to 100M is challenging, 100M – 200M is quite complex and 200M+ may require some serious engineering effort.
Then again, it really depends on the most complex components and handling the right solutions with the corresponding vendor. For instance, the payment part of your application is through PayPal or Stripe whereas accounting can be the trickier part of your workflow.
As long as you can leverage the WordPress core feature set, it would work well in the long run.
Here are the key features. Check below how you can leverage them with the WordPress Core.
- Sellers and Buyers are feasible with WordPress roles in different capabilities.
- You can trim the WordPress dashboard, including subpanels for each role.
- Handle most of the data management in the front-end as well – through protected page templates.
- The search functionality will be offloaded to Elasticsearch or a service like Swiftype anyway – therefore comparable in different implementations.
- Archives for jobs or sellers are fairly trivial and won’t impact the application as a whole.
- The template hierarchy of WordPress is incredible – and it would definitely come handy.
- Additional components could be introduced when forking existing plugins.
Overall, WordPress is not a terrible option for your solution. Think of the possible UX problems that you may have with WordPress as an application framework. Consider the growth of the platform over the next 3–5 years as well.
If you decide to go for WordPress and hire a top-notch team, they could pull it off.
Tips and Tricks for Enterprise WordPress Development
The amount of information on enterprise-grade WordPress development is scarce. Just a handful of agencies out there profile in building WordPress platforms, applications, plugins, or performing migrations and integrations for the enterprise.
I’ve written on this topic covering our experience building WordPress for banks and some of the main considerations of our clients. I also had a session here on Quora discussing enterprise WordPress questions which I’ve summed up here as well.
And I’ve discussed our toolkit at WordCamp Boston in MIT Labs a few years back:
There are a few important notes to take into account, too.
- Most vendors profile in small business websites. A small chunk of the service providers work with enterprises.
- Those consultants and agencies often don’t have the time and resources to write tutorials and share their know-how with the industry. Or they just don’t care (especially more hardcore engineers who don’t want to bother).
- WordPress is often not the core application that enterprises use in the first place as it’s another obstacle for many (like working on the front-end interface as 1% of the main platform running behind the scenes).
Other than that, WordPress developers who want to bid on enterprise projects can focus on several different areas:
- Studying the WordPress Core, APIs, and the surrounding ecosystem in-depth.
- Making sure that you’re comfortable with WordPress coding standards and best practices.
- Practicing in the main technical areas that enterprises care about – such as performance, security, scalability, and backward compatibility.
Hosting vendors are strategic players in the field and they occasionally work with high-scale applications. You can browse their resources and follow their blogs, knowledge base articles, and the like.
Most of the heavy lifting for enterprises happens on top of those layers. Therefore, it makes sense to dive deeper into their own communities and resources stressing on those topics – such as Blog: MySQL Performance Blog – Everything about MySQL Performance. – High Scalability – which also happens to link to another blog on MySQL tips.
It always helps to follow WordPress Core contributors, employees at enterprise-grade companies and the blogs of the leading agencies working with enterprises. You may find some relevant case studies, interviews with clients or other top engineers which could help you improve even further.
Handling WordPress Development, Deployments, and QA
This could be a tedious process or a trivial one – depending on the complexity of the WordPress website and the number of third-party services (and weird plugins) installed.
Some of our agency partners have asked us to upgrade WordPress websites that haven’t been touched in 5 years. The simple ones that represented a blog or a standard magazine website with a clean free theme and just a few small plugins didn’t need any updates whatsoever.
On the other hand, more complex solutions may completely collapse even when upgrading a minor version of WordPress. For instance, that happened with two WordPress websites recently with the upgrade to the minor version 4.8.2.
Technically, minor versions automatically update since they only introduce security fixes. That said, one of the database API updates stripped certain prepared statement variables which affected hundreds of popular plugins which stopped working right away.
Regarding the process of “checking”, here are a few things that larger agencies work on in order to reduce the number of issues post-upgrade.
- Staging environments – all professional vendors run several clones of the production environment used for testing (staging, dev, test, local etc). That helps with identifying issues before pushing to production.
- Unit/Integrational tests – writing PHPUnit, Behat, QUnit, Mocha tests will help you run a suite of these validation checks before deployment. Connect these to a CI server like Travis and Jenkins and it works like a charm even in GitHub before merging a pull request.
- Version-controlled environment – speaking of CI servers, version control is definitely a must. Even if something goes wrong, you can easily revert to a previous version or exclude just a specific feature branch.
- Automated deployment – tools like Capistrano or Chef let you automate your deployment in a fairly smart way. Instead of copying folders over (God forbid via FTP), you can automate the whole process. Capistrano creates folders with each release by default and points a symlink to the latest push. The rollback takes milliseconds.
- UI/screenshot tools – you can record Selenium tests, integrate a screenshot tool like BBC’s Wraith, or use Backtrac in order to catch UI bugs before pushing to production.
- Manual QA – most professional agencies employ quality assurance experts who run through the main feature set and ensure that everything runs smoothly.
- Careful log investigation – manually browsing PHP/nginx/MySQL error logs often is always handy in catching weird bugs. If you can afford New Relic, that could be well automated, too. An open source alternative is Zabbix which can also monitor your traffic/RAM/IO spikes if you are willing to write some custom scripts.
- Code reviews – most professional agencies conduct extensive code reviews even before taking on an existing project. Some are automated (like PHP Mess Detector, Code Sniffer, JSLint) while others are fairly manual. With experience, most agencies can easily spot certain security or performance issues, as well as using deprecated functions or popular yet incompatible ones.
There are other ways to prevent common issues in a production environment or notice them as early as possible. The same goes for intercepting these on staging before going live – for instance, we rarely push anything large on production before going through a QA cycle together with our own clients.
Sometimes, there are other quirks that happen even without a deployment. A 3rd party service outage or a JS conflict are two popular cases. We’re building our own testing toolkit comprised of dozens of small tools.
It runs cron jobs that verify certain features of each WordPress website (and specific pages that are feature-heavy). Automated form submissions, regex comparisons ensuring that a script is in place, XPath validation for the output of a certain widget, Mink tests validating search form results and more.
Security Reviews And Penetration Testing For WordPress
Since security is a common topic when it comes to WordPress, I wrote a lengthy article based on our experience working with banks and other enterprises:
I cover the essential problems reported by enterprises over the years, common misconceptions, and a recap of different attack vectors that malicious hackers leverage through their process.
We’ve just published a couple of security guides on DevriX this month as well with regard to WordPress websites:
- Interactive Guide: The Definitive Guide to Securing Your WordPress Website – DevriX (~6,000 words)
- How to Evaluate WordPress Plugins for Vulnerabilities – DevriX (~2,500 words)
With regards to penetration testing, it depends on different use cases:
- The sort of web application tested
- Which vendor conducts the penetration test
- What percentage of the web stack is WordPress
- Where the platform is hosted
- Does the platform interact with sensitive data (SSN, credit card records, other personal data), is that stored for a long period of time, etc
We have worked with security organizations such as Verizon Enterprise Solutions and the Department of Homeland Security for penetration tests conducted to applications developed or maintained by our team.
The types of reports are broken down into severity and priority. Those are taken into account when applying security fixes after discussing them with our clients.
Severity and priority may vary between different security companies. They comply with different standards and put emphasis on areas where they see a realistic risk or an upcoming breach.
More often than not, those risks follow a list of best practices. Sometimes, those regulations don’t make a lot of sense. An eCommerce business may be advised to get rid of the payment gateway integration in order to prevent possible risks with fake payments, data leaks, or a number of phishing websites.
This is an extreme example – but you get the point.
This is why we review each and every point carefully and discuss the impact on the business. Higher security usually affects user experience or actual business logic – and a client may decide to find a workaround that doesn’t solve the problem directly.
In the PHP world, hackers commonly use functions such as eval() or base64_encode() in order to hide possible exploits from the public. Most of the managed hosting companies even block plugins or snippets that rely on similar functions.
When secured carefully, they could still be instrumental for some components or libraries. Internal debuggers use them a lot. Proxy libraries and tools interacting directly with the file system need them. Third-party tools may require running a Python or a Ruby script and processing data through them, too.
One of our clients really depended on a Salesforce integration that was complex and used eval(). Since this had been marked as a critical problem by the security organization and the host, we had to spin off a separate VPS that served as a proxy. It was a terrible workaround but we had to comply without having to rewrite 20,000+ lines of complex code.
Most of the reported problems with WordPress website projects are related to:
- The hosting environment/configuration
- Apache/nginx, PHP, MySQL or other services ran on the Linux container
- WordPress plugins
- The WordPress theme
- Custom files and directories serving data within the WordPress core folder
- Insecure upload decisions within the main /uploads folder
- Publicly accessible files that may hold sensitive data (robots.txt, .htaccess, sitemaps)
- Password regulations (length, complexity, expiration times)
- User account regulations (logging in with 2-factor authentication, limited roles and capabilities, session timeouts, resetting passwords every X days)
WordPress Core is rarely the reason for a security breach. While there are security fixes every now and then, we haven’t seen a formal security review indicating a problem within the Core platform itself.
The problem is that an existing (and often popular) platform isn’t comprised of the WordPress Core alone. Most of the plugins and the existing themes include a ton of components that contain the core business logic. Some of those haven’t been reviewed carefully before integrating them in the platform – which causes the main trouble in relation to WordPress websites afterward.
So the technical vendor does several iterations of cleanup and implementing additional security layers in compliance with the review.
- Common and obvious fixes are applied right away.
- Some plugin glitches are fixed through the plugin APIs (actions and filters).
- A framework plugin/extension may strip out certain features that are not in use in order to avoid updating the existing code.
- The tech team forks a poorly maintained plugin uses it as a standalone solution.
- A complex and bloated plugin may be replaced with a custom one – or a lightweight and secure alternative.
- Theme logic unrelated to the presentation can be extracted as a separate plugin – optimized for security.
- Business processes and other server and code updates resolve insecure data or user management
At the end of the day, businesses try to stick to the proposed solutions for WordPress websites in the security report. Configuration updates or a code cleanup (plugins and themes) solve most of them. You can carefully dodge some if they impact the main business logic.
WordPress fits high-scale and enterprise-grade projects. Long gone are the days of referring to WordPress as a simple blogging platform; it’s a mature web content management platform, often used as a SaaS or an eCommerce engine.
Enterprise organizations use WordPress in different forms, building WordPress websites, and occasionally grow the pilot projects to mature platforms used by millions of customers.
If you’re still hesitant, here’s a compilation of the most common problems scaling WordPress websites struggle with.