Answer Type: WordPress

Some WordPress hosts let you connect your WordPress folder to a git repository in different ways.

• One popular option is setting up a plain git repository within your project folder. It won’t be connected to any hosted version control system – but it is still a git that you can update in the same manner.
• Others let you connect a GitHub repository right away.
• If you have ssh access, you can also clone the GitHub repository straight to your folder and pull the changes there.

Automated deployment is also possible and usually requires ssh. Capistrano is a good option that would also help to sync your databases, handling backups, and rolling back to a previous version in case of a problem. The same process is doable with chef or Ansible. This could be combined with a CI server that handles the heavy lifting.

GitHub offers webhooks which can be connected to your VPS as well. You can listen for certain events and update your install accordingly.

Beanstalk is a version-controlled hosting platform that lets you commit code, review, and push to production with a simple button.

DeployBot is another proxy service that comes handy whenever you don’t have ssh access. You can connect the bot to a GitHub repository and set your SFTP credentials in order to automatically pass git commits through an FTP stream uploading the files to production on your behalf.

Contributing to WordPress Can Take Various Forms

Individual contributors are those who support the WordPress initiative in different directions:

• Submitting bug reports.
• Submitting patches for known bugs.
• Reviewing WordPress themes.
• Creating and submitting free themes and plugins.
• Helping out in the support forums.
• Translating WordPress (and popular plugins) to another language.
• Organizing meetups and WordCamps around the world.
• Reviewing videos before approving them on WordPress.tv .

There are a few other areas related to design, marketing, and training that are loosely defined and still open to contributions.

As a web developer interested in contributing to the core WordPress codebase, the best option is installing the latest trunk version of WordPress locally, finding a bug, and uploading a patch on WordPress Trac. You can browse the available tickets and find something that has been reported and hasn’t been solved yet. Make sure you have the right WordPress development setup in place.

Some WordPress Core Tickets Are a Lower Priority

They can easily take months. The core approval process itself is complicated – especially for complex fixes with thousands of permutations.

Looking for the pipeline for a recent release (minor or major) would likely get this patch approved sooner. Of course, you need to adhere to the best WordPress Coding Standards while submitting your patch.

A few years ago, I gave a talk at a virtual conference that explains the foundations of debugging WordPress. It also includes a practical workflow for contributing to WordPress. My patch went in a week after the talk and you can follow the same flow demonstrated in the video:

Usually, No

Commercial WordPress themes generally include a large suite of scripts and styles, along with a comprehensive set of features in order to make them pop.

Most premium themes rely on a number of theme options, various widgets, eventually some sliders, content builders, galleries, social media integrations and the like.

Each of those components is written in PHP and often includes some JavaScript and CSS assets loaded separately. Those increase the load times due to the larger number of parallel HTTP requests for rendering a single page. Fonts and images may also get in the way.

Light, Simple Commercial Themes May Work Faster

Most of the commercial themes – especially the multipurpose ones – are simply trying to solve a large set of problems for different industries and types of websites. That’s what causes delays, instability, and possible security issues.

As a rule of thumb, the free themes hosted on WordPress.org only care about the presentation layer – usually comprised of markup and CSS. They’re fairly lightweight and simple, going through a rough reviewing process. The general principle of themes is that they should only serve for presentation of the standard blog/CMS content. Anything else should be distributed as a separate plugin – in order to keep things separated and avoid a theme lockdown whenever you decide to redesign your website.

First off, developers are people who actually specialize in programming.

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 Development Requires PHP

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 project requires 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.

WordPress Themes Handle Presentation

The theme itself should be kept simple and to the point. Features are built as WordPress plugins in order to avoid a vendor lock-in. 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.

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 Theme Framework

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. It’s a common misconception, though.

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.

Some workflows depend on staging and production environments while others add an extra layer – a dev server that runs the latest bleeding edge of the application.

Structuring WordPress Environments

The second approach is structured in the following way:

• Dev environment is constantly updated with the latest commits by the dev team.
• The test/staging environment is pending review from the product management team or other stakeholders on the client’s end.
• The production server is available to the public.

You can skip the dev server altogether although some hosting vendors provide 2 separate staging clones per site (or more if you want to test separate branches simultaneously).

Version-Controlled WordPress Projects

In terms of deployment, the best practices state that you ought to use a version controlled environment (git or svn) that’s pushed to the dev/staging site first. This could happen in various ways that I’ve described before.

So you push the changes to a repository that lives on the hosting and is automatically deployed, pull the changes directly on the server, or run a capistrano/Chef/Ansible deployment script that handles the heavy lifting.

The sync between staging and deployment may work in a similar matter – by pushing the same code base again to production once it’s ready to go. Depending on your hosting vendor and architecture, an easy “merge” button may exist (or a sync command that does that from the shell).

The one missing bit is the database sync. It’s a common problem with WordPress that gets trickier if you need to prepopulate database options, custom taxonomies, user data or anything else that is now configured in the staging environment.

Some hosting vendors again provide tools that let you override staging with production or even sync specific database tables instead. You can use WP-CLI and import a database export of posts or post types. Or use a plugin such as WP All Import/Export that allows for more complex export patterns.

In most cases, you won’t have to migrate a lot of custom database information to production. It’s either a couple of options that you can set/create manually, or there’s often a way to export a generated file that sets this up directly in the repository.

1. WordPress is a Platform

It’s an open-source software CMS that runs 29% of the web.

There’s a popular site named WordPress.com which offers a hosted version of the software. It’s fairly limited, although Automattic – the company owning the product (whose CEO is also a co-founder of the WordPress software) – continuously introduces some additions and extensions for hosted users.

But the free software could be running on almost any PHP host out there. Most also use cPanel which includes Softaculous or Fantastico (or a similar alternative) that would let you install WordPress with just a couple clicks if you don’t want to spend a few minutes creating the database and downloading the latest source.

2. A platform Doesn’t Make Developers Redundant

The aforementioned hosted platform is limited. You can’t bend it infinitely – which most customers want (from a UI perspective or feature-wise).

The open-source software is extremely extensible. On top of the available of free themes and plugins, millions of developers offer additional consulting and coding services – building new themes or plugins, migrating custom frameworks to WordPress, creating multisite network or even building SaaS and mobile applications on top of WordPress.

Some of the existing plugins aren’t of the highest quality, so handmade alternatives are built for larger accounts. And some may require additional features which usually happen through building extensions for them.

Let alone the fact that WordPress powers 29% of the web and not 100%.

3. WordPress is Flexible and Works Great in MOST Cases

While I’ve built and managed WordPress software for enterprises (automotive providers, airline companies, banks), there are certain cases where I wouldn’t suggest WordPress as a go-to choice.

I’ve discussed some of the architectural decisions in the WordPress platform during a PHP conference a couple years ago:

It’s indeed a fascinating platform that is extremely extensible. But there’s a core framework underneath that is suitable in most cases – including for enterprise-grade clients.

The database schema includes a predefined set of tables. Those could be omitted or extended with new tables – but this may be an overhead sometimes.

The dashboard also runs a number of validations, checks, conditionals that may not always be of use. Certain components like Media or Comments may not be applicable for certain sites.

The core posts table includes a number of default columns that may not be required in certain projects. That’s also an important consideration when starting a new web application.

For instance, I won’t build a Twitter, Instagram, Snapchat clone on top of WordPress. I will probably skip 70% of the default WordPress features which would impact the ongoing maintenance and touch on some performance issues.

In reality, it’s a great choice for 95% of web applications, if not more. But it should be revised carefully since there’s no ideal tool for any job out there.

Themify, most fancy premium themes, and most page builders are meant for solopreneurs, inexperienced business owners and freelancers who want to earn a quick buck for a site that won’t generate any traction anytime soon.

The market for providing “site builder” services with no additional value is generally oversaturated. You can probably get a new small project every now and then, but don’t expect to make a living off it unless it’s your main focus where you can find a specific niche that you can serve better than others.

A proper solution would still require additional services such as content marketing, SEO, SMM, optimizing for a higher CRO, user experience and the like. If that’s your passion, you can build a small digital marketing agency profiling in those services for starting businesses.

If you’re actually passionate about PHP and want to use WordPress, aim for professional PHP development. WordPress is a great application framework that powers 54% of the top 100 companies in Inc 5000. We’ve been maintaining and growing large multisite networks, SaaS solutions and magazines generating over 20,000,000 monthly views on top of WordPress.

There are various opportunities for plugin developers, programmers specializing in migrating custom solutions to WordPress, performance experts or security folks with WordPress background.

A proficient PHP developer can easily switch between platforms and frameworks as well. If you want to take on a Laravel or Symfony project, the learning curve would be lower than if you specialize in PHP development.

Pick your battles wisely.