I'm working on figuring out deploying a Wordpress site from BB Pipelines to AWS EB. It all makes sense except for one thing, I want the repository to only contain the theme and plugin files.
I do not want the full WP directory being deployed each time. Media would be handled via an S3 bucket and the DB would use RDS.
What is the best way to get WP installed but only have the theme and plugins deploy through Pipelines? And when I want to update to the latest version of WP, how would that work?
Or am I going about this wrong?
The simple solution, and best practice in my humble opinion, is to repo the entire WordPress installation, including the WordPress core, and all your custom themes and plugins.
Having the entire installation in one repo solves many problems: you can can tag and release versions, and you can install all software locally with a simple git clone.
Regarding the file system, definitely consider EFS instead of S3. It is much more reliable and easier to mount in a linux-based system. Make sure and define set the file path environment variable, so you can point WordPress to the files. You will want mount this outside of the software file tree.
I have been running this kind of setup for 3 years with no problems. We do releases through the code deploy service daily. Very straightforward and easy to maintain.
To upgrade WordPress just check out the current version from the repo, then apply the upgrades release, do comparisons, test commit and release.
Related
For the continuous integration and deployment of websites, I am using this pipeline:
But for many CMS like wordpress, prestashop, magento and others, the configuration of the website and the installation of plugins is done in the back-office of the deployed website.
For now, I am building the docker image on top of the CMS base image, then replacing all the /var/html directory with the files in github. Then Kubernetes is deploying the containers and plug a database and a persistent storage
Hence, this is breaking my pipeline: imagine that someone is installing and configuring a plugin in the back-office, then someone else is doing a modification on a file and pushes it to github. The github repo doesn't have the info that a plugin was installed and will build and deploy a new image without it.
How to integrate all the modifications done in the back-office in my github repository?
The solution we use is an override of the DB class.
So we monitor a number of tables (Configuration, module, hook, etc ...) and we store all queries about it in a sql file.
So during commit, we also have a .sql actions to perform on the database side.
Once deployed, either you manually execute the sql, or a script detect that new SQL are present and executes.
In this way we are always up to date.
This solution we developed in the form of Prestashop modules to track all actions.
Regards
My (by any means not ideal) working solution:
Create plugins folder outside docker and symlink this folder in dockered /wp-content/plugins
recreate above in production
Then installing new plugin doesn't break CI flow but requires two independent installations and configurations, if you (or dev team) need to install something new.
So you basically treat plugin files same way as you already do it with DB.
I ran across the VCCW project and despite my unfamiliarity with Vagrant and Chef, decided to give a try. I followed their instructions and obtained the VCCW project itself by installing the GitHub Windows program and cloning the VCCW GitHub master repository. I should also mention that I have very little experience with Git.
Anyway, now I have VCCW Wordpress running on my machine, but I've no clue what to do from here. I wanted to set up a better and more formal Wordpress development environment so I could write my plugin and modify a theme, but I don't know where I should do that. I know where the actual Wordpress installation resides on my file system, so I suppose it would be easy to work from there, but I don't know how (if at all) that interplays with the Vagrant workflow - ie, when it comes time to use Vagrant to deploy my site, will my changes to the "www" folder (which was created by vagrant up) be captured? Somehow I doubt this. Just looking for any help as to how all these fancy new tools work with each other and what a humble PHP developer like myself should do to get started.
Edit: One more question: which IDE, if any, can I use in conjunction with this arrangement? Create a new project from existing sources, and let it pollute my deployment folder with project files?
From the Vagrantfile, it looks like you should look in ./www/wordpress after provisioning.
VCCW includes deployment tool WordMove.
You can deploy WordPress into your server from vccw if you set Movefile.
Movefile will be created automatically after provisioning, so you should add your server configuration in Movefile.
http://vccw.cc/#h2-10
https://github.com/welaika/wordmove
I just started developing plugins for WordPress (fun!) and am curious if there is a faster/better way to upload a new version of the plugin, without having to delete the current one first?
I am not using the WordPress.org Developer Center, as the plugin I am making will be strictly for internal purposes. I am just uploading the plugin folder (zipped) through the WP Plugin Dashboard.
Since I am new to developing plugins, I am doing a lot of testing and frequent updating of the code. Would be nice if I could save time with the whole delete-then-reinstall-and-activate process.
Several options:
Sync files with git, possibly on pushing to a central repo - that's what I use daily.
rsync (run manually when needed)
Some people are using capistrano or something similar, but I personally think that this is not necessary if you're making frequent changes in a staging environment.
I have been version controlling my WordPress site with Git and pushing to GitHub for quite some time. I develop locally, push to GitHub, and pull from GitHub to my production server.
I would like to scrap my current WordPress core on my local environment and replace it with a fresh new copy to then be pushed to GitHub and pulled to my production server.
My question is...am I going to run into any sort of tracking errors wit Git by replacing my WordPress core? Any other suggestions for me when I do this?
I handle this by adding the Wordpress core as a subrepository. WordPress maintains a mirror of their SVN repository on GitHub. Then you can update to a new version easily by going into the subdirectory containing the WordPress core files and checking out the tag for the current version:
git fetch --tags
git checkout 3.3.2
The repo also includes beta releases, if you prefer those.
Here's the guide that I used to set up this process: Install and Manage WordPress with Git
I understood you're talking about updating wordpress. You should note that, like documented in the update instructions, during update you should
check the requirements
take a backup of your database contents
disable the plugins you have
So all this you should do regardless. Also, you should be sure to update your database content, too, if needed.
Wordpress contains instructions on updating using svn, and it seems it is, according to them, a perfectly fine approach to have. I would see no major difference for you to do essentially the same thing with git, provided you can tell exactly which files are appropriate to store on version control and which aren't.
I like to use a simple Git workflow for static web sites but I build Joomla and Wordpress sites a semi-regular basis too. However I am at a loss as to how to use Git with with database driven site development.
For a static site I would 'Push' to dev.websitename.com, then push to www.websitename.com once the dev site checks out. How would I mimic that process with database driven site like wordpress or joomla.
Thanks in advance for you insight!
You can definitely use Git with your website code, such as changes to your WordPress theme/plugin, exactly as you would if you are developing a static website.
However, you wouldn't use it for your database. Git provides version control for code, while WordPress and Joomla already manage content stored in the database. Plus, Git wouldn't understand a database, so it wouldn't have any advantage over a periodic backup, which you should already be doing. Take a look at running a dev copy of your site for how to download your database directly from your server.
By the way, if you use Git with WordPress/Joomla, you should add e.g. cache, logs, tmp to .gitignore. There are also lots of tutorials out there--try searching e.g. http://google.com/search?q=wordpress+git.
In addition Chris, you may want to embark on your Git workflow without the handy script approach (at least initially). The script approach and using Git hooks can sure seem sexy (well, because they are) and handy too, but initially why not go with a more manual cmd line approach, which will also help you familiarize yourself with Git.
Once you've got your repo setup (GitHub, Bitbucket, somewhere else) and you've pushed your latest to it and are ready to deploy to production or staging, just login to your host and from wherever you've initialized the git repo (site root, example: /site) just do a:
git pull origin master
This will fetch and merge your code. Good idea to test this on a dev/staging environment and if the merge goes well then do it in production.