Wordpress with Git deployment issues

Question

I'm new to wordpress, coming from the python/django world where there are pretty established standards for development workflows and site deployment, so I'm trying to find some guidance on how to manage a deployment.

For some background on what I'm trying to do: I'm taking over an e-commerce wordpress deployment hosted on Digital Ocean. The site is live, and although in the long term we will likely migrate to a different platform, so this is a somewhat temporary solution to be able to make some customizations to the installed themes and easily deploy to digital ocean while keeping things under (version) control.

I had initially tried deploying WP to heroku with a port to use MySQL of Mhoofman's repo. The problem I ran into there was that the WP Read Only extension was breaking things like the importer and thumbnails, and it seems like it's not really under development anymore. That would otherwise be my preferred solution.

My latest attempt has been trying out Efeqdev's method setting up wordpress as a submodule. After running into issues serving static files in MAMP on OS X, I finally got it working.

Now I'm getting these problem with installed plugins:

Strict Standards: Redefining already defined constructor for class WXR_Parser_Regex in [...]/project-wordpress/wp-content/plugins/wordpress-importer/parsers.php on line 408

Strict Standards: Declaration of WP_Import::bump_request_timeout() should be compatible with WP_Importer::bump_request_timeout($val) in [...]/project-wordpress/wp-content/plugins/wordpress-importer/wordpress-importer.php on line 38

Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at [...]/project-wordpress/wp-content/plugins/wordpress-importer/parsers.php:408) in [...]/project-wordpress/wp-content/plugins/ninja-forms/ninja-forms.php on line 638

Warning: Cannot modify header information - headers already sent by (output started at [...]/project-wordpress/wp-content/plugins/wordpress-importer/parsers.php:408) in [...]/project-wordpress/wordpress/wp-includes/option.php on line 750

Warning: Cannot modify header information - headers already sent by (output started at [...]/project-wordpress/wp-content/plugins/wordpress-importer/parsers.php:408) in [...]/project-wordpress/wordpress/wp-includes/option.php on line 751

Of course, once I did all the work and reading through the comments on post, it seems like the they had moved onto deploying using Bedrock. My hesitation about using Bedrock is that it seems like Composer will manage the plugins for me and might wipe out any customizations I may have made to them. As I said, not extremely familiar with PHP/Wordpress, so if I'm wrong about that, and it seems like a saner option, please do let me know.

It seems like moving around parts of WP has a lot of potential for things to break. Would it make more sense to keep the wp-content subdirectory in a git submodule and everything else in a standard way? Not entirely sure how to deal with stuff in the uploads folder, not a good idea to keep it in git, it gets modified in the server when new images are uploaded, and we're using cloudflare for media distribution.

Answer 1

I commit all WordPress because I consider it one big ball of code that pertains to one site, this means updates to core WordPress files, plugins and themes are all part of the commit history.

I don't use sub-modules or any other weird nested revision setups. If you have a complicated structure of including multiple repos, I suggest keeping them separate and just using composer or another tool to update your main repo with files and not separate application histories.

What I do git ignore which is WP specific:

• Any cache or temp files ( for example objectcache/, pgcache/, etc )
• /wp-content/uploads/
• Backup directories, logs, sitemaps
• Configs (wp-config.php, .htaccess, any cache configs, etc)

Not every site is the same, I sometimes commit wp-config.php with multi-environment code, or sometimes I will commit /wp-content/uploads/ because it makes sense.

Also some plugins and themes upload media files into other locations which is annoying, so sometimes I blanket ignore file types.

Some opinionated notes:

I don't understand why people don't commit all WP in the repo, you have way less liability when you have WP changes in your history for updates (careful with auto-updates).

Take the time to get the setup right and test things, stuff will run a lot smoother having a good workflow as opposed to what happens if you try to change it later on.

I take the stance of committing more is better, because it sucks to turn around looking for something only to realize it's not there. But is also sucks to commit things you don't want so keeping it simple reduces brain meets desk scenarios.

Here is an example of a .gitignore I start with: https://gist.github.com/wycks/574052a64eee9307b06c