I am looking to integrate version control into my Wordpress development workflow. I have experience with Git in rails application development, so that seemed like a good option. However, I haven't found any holistic information that pertains to my needs and is in my knowledge level.
I would like to be able to accomplish the following:
develop site locally(I would only be touching the theme files for the most part, so I would want to look to the production environment for the rest of the files to avoid redundancy)
have Wordpress look for theme information in my repository (most likely will be on Bitbucket, but am open to server hosting solutions)
I hope that I am describing this clear enough for someone to have insight. If not I am glad to go into more depth of my goals.
You can refer to "WordPress + Composer + GIT"
It uses (in addition of Git) Composer (a dependencies managing tool for PHP), and WordPress Packagist (a repositories site that automatically packages the plugins and themes available in WordPress site in the format required for working with composer)
That way, you keep a declarative approach where you declare ion a composer.json what you need: this is easier to version in a Git repo.
Related
Probably a silly question, but I cannot find any good advice on the internet so far, so hopefully you guys have some good advice. I would like to use GIT for version control and use it to deploy changes to my websites to the server(s). It's easy when I use NodeJS, but a bit more complicated when using a CMS system, to my opinion.
When I use NodeJS
When I use NodeJS it's quite easy to have a node_modules folder which contains all the external libraries which I will install on deployment. The rest(my own files) will be saved on Github and deployed to my server if changed. Obviously I will not store the node_modules folder on my Github account or send it to my server (node modules will be installed on the server, on deployment). So it's pretty easy to keep those two (third-party an my own files) seperated.
When I use Wordpress, Magento or something similar
Now it gets complicated. Mostly because CMS systems like Wordpress have a folder structure like wp_content/themes/theme_name/, so your own theme files are more or less entangled with the core structure, instead of separated like NodeJS. And it doesn't seem right to commit all my core files to my Github account as well or send all those core files to my server on every deploy (I would prefer to install them using composer or something, serverside), because I'll never touch the core files, obviously.
So is there any advice? Is there a better whey to handle this? Maybe change a configuration file with the path to my theme folder or something?
The best way to do this is to move your wp-content folder outside of your standard installation. I tend to have a folder called "wp" with the basic WordPress installation in it and a folder called "wp-content" at the same level for my content files. You can then tell WordPress that your content folder is elsewhere with the following:
define('WP_CONTENT_DIR', dirname(__FILE__) . '/content');
That goes into wp-content.php which you can also take out of the main WordPress install (and thus add to git) and place at the same level as your folders.
To make things even better consider looking at composer https://getcomposer.org/ and using that to bring in WordPress core and plugins https://wpackagist.org/ is your friend here. This guide got me started on using composer with WordPress and its a good start https://roots.io/using-composer-with-wordpress/ you can pull in your theme from git as well via composer which is great for when you deploy etc... Capistrano for example can run composer on a server :)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm currently working with Git, Git Flow, Gulp and Bower. I'm working on the develop branch and create releases with Git Flow to the master branch. So develop is equal to my local and test environment, release/version to the acceptance environment and the master branch is equal to the production environment. See: http://nvie.com/files/Git-branching-model.pdf. On every environment runs Git, so deploying is nothing more than: git pull origin master.
I've got some dependencies like Bootstrap and Font Awesome handled with Bower and I'm using Gulp to watch .less files for "compiling" to css, minifying css/js, etc.
Now toward to the questions: what should be in my Git repository? Let's say I'm working on a Magento project, it would be overkill to put Magento and all dependencies from Bower in the repository. Currently I'm excluding only the node_modules (for Gulp) and bower_components (contains dependencies) directories, when I run Gulp the .less files from Bootstrap will be "merged" and "compiled" with my project related .less files. The "compiled" .css file is currently included in my repository, else it's not possible to do a deploy with just git pull. To get it working without having the "compiled" version in Git I've to run Gulp on the production server.
What is the best method for not having my platform (Magento or Wordpress) in my Git repository, but keep the possibility to easily update? I came across this solution: http://blog.g-design.net/post/60019471157/managing-and-deploying-wordpress-with-git where they're using Git Submodules. Nice solution, but this way the platform needs to be in a sub directory. Not ideal because I've to "hack" to get it working that way (copy the index.php and change the include paths, etc).
What about plugins/modules? 3th party plugins shouldn't be in my repository too? Only the plugins I've created by myself. But not all 3th party plugins does have a Git repository to use with for example Git Submodules. For Wordpress it's just one directory, so in theory it's possible but for Magento the most plugins aren't just one directory (they have files in the app/code, app/design, skin, etc directories). I've a lot of Wordpress and Magento sites with multiple matching plugins/modules now every plugin/module is in each sites repository.
Should "compiled" files be in a repository? If you ask me: no, but I'm currently doing it so it's easy deploying. Is it general to have Bower and run Gulp on a production server for dependencies and to "compile" on the production server right after a git pull? Continues running a Gulp watcher (like I do locally) on production takes some extra unnecessary resources?
I hope someone can put me in the right direction.
It's difficult to provide a universal answer that works for Magento, WordPress, and other platforms. My answer primarily targets Magento, but I'm sure that similar concepts could be applied to WordPress and other platforms.
It's possible to automatically install Magento as a dependency using Composer with magento-composer-installer. You can either use a public mirror, like this one, or set up your own repository. Once you've installed Magento itself as a dependency, it should be very straight forward to update it, just like any other dependency.
You can use Composer for modules as well (after all, Magento itself is just a bunch of modules and a few scripts to glue everything together). FireGento has a lot of common Magento modules which can be used with Composer out of the box. You can also set up your own repositories to use with Composer (we do this for internal modules that we use for multiple sites).
As for modules that don't have their own repositories, well, you have three options: don't use them (the less modules, the better), create your own repositories for them, or just commit them along with the rest of your codebase.
In an ideal world, your repository should only consist of your own source files. Everything else - whether it's compiled, installed through a dependency manager, or otherwise somehow automatically created - should not be in the repository.
But we don't live in an ideal world - it's painful to run Composer, Bower, Git, Gulp, Sass, and everything else that you're using on each and every environment that you want to deploy to (development machines, testing server(s), staging server(s), production server(s), and so on).
And what if those dependencies have dependencies? What if you're using a Gulp plugin that works well on one of your servers, but fails on another one? What if someone makes a deployment and forgets to run some of the required builds via Gulp? Of course, the answer to these questions is testing and automation. You should be able to click a button (or type a command, for the purists) and have everything automatically deploy - a git pull is issued, the appropriate gulp commands are run, and so on. But unless you have the manpower and manhours to set up such a sophisticated system, it's not worth it.
Overall, we use a combination of the different points above. In the end, we end up committing (almost) everything to the repository - resulting in deployments as simple as git pull or svn up. Of course, configuration files (credentials, .htaccess files, and so on) don't go in the repository, and neither do fingerprinted files (which we manually upload).
Fabrizio Branca has an excellent blog post here which goes through many of the described points in order to clean up and upgrade a Magento setup.
I am not a CQ guy. I have to use CQ5 for one of my project. I have a CAT and a production environment. I have following doubts-
I want to use author instance of my CAT only. Once I publish the content in CAT it should publish in Production also. Is it possible ?
Once I update the build of AdobeCQ in my production say new build, code changes etc- will my content be lost ?
I read somewhere about Content package in cq5. Can I separate content changes and code changes in one CQ5 environment ?
Thanks in advance.
To answer question 1...
This is not a recommended setup, but a common misconception for someone unfamiliar with AEM/CQ5. The "author" and "publish" instances should be part of the same environment. For example you should have a production author, probably behind your firewall, and production publish to serve pages to the public.
Your CAT environment should have the same thing. You want your testing environment to match as closely as possible to your production environment, including web server and dispatcher setup, to ensure quality.
Consider this. You can use one production publish instance, but it's a single point of failure. It's a general best practice to load balance across at least two. Two is sufficient for most websites. If you do this, you'd want to mimic the architecture in CAT.
To answer question 2...
If your code is written, built, and deployed correctly, it should not delete your content. Just make sure you are never deploying anything to /content (to avoid deleting content) and to /libs and most of /etc to avoid overriding platform functionality. AEM/CQ5 is a very open product, so you can do very bad things. But, if you know what not to do you are safe.
Code deployments should typically be done as part of a CRX Content Package, which brings me to...
To answer question 3...
The way we build and deploy code is to have Maven compile the Java, package everything up in a CRX Package, then deploy to the instance using the Package Manager REST API. Adobe provides a Maven Archetype that will facilitate this.
A CRX Package is a file system representation of your content repository, wrapped in what is effectively an annotated Zip file. Your compiled Java code is included in that file system representation, in a folder (to become node) named "config". That compiled Java is an OSGi bundle, which is an annotated JAR. When CRX Package Manager deploys all those nodes to the system, OSGi accepts the bundle, assuming it's valid. This is why you can do "hot" deployments of live, production AEM/CQ5 instances, with very little risk.
So...
This is a very high level answer to some very big topics. I encourage you to do a lot more research before you set this up. There are many good blog posts and documentation pages out there to help you get this set up according to best practice. Good luck!
I have almost finished the development of a project developed with Symfony2, and wish to put the project online.
However, I suppose there are a lot of things that need to be done so that everything works ok. I suppose, the dev mode needs to be disabled etc....What needs to be done and how?
What are the most important things to do on a Symfony2 project that will be available to everyone on the web?
I suggest you to use Capifony for deployment. It does a lot of stuff out of the box and you can make it run any custom commands you need. See its documentation for details.
Regarding the dev mode, unless you've removed the IP checks from app_dev.php, you don't have to worry about deploying it. Of course, if you wish, you can tell Capifony to delete it on deployment.
The best way to handle deployment is to create "build" script, which will:
Remove all folders and files with tests from your bundles and vendors.
Remove app_dev.php file
Make sure that app/cache and app/logs are fully writable/readable.
Packs your project into archive (rpm f.e.)
Then, before deployment, you should create tag in your project - so it will mean, that certain version of your application is released (I recommend to follow this git branching model).
Create tag.
Run your build script
Upload archive to host
Unpack
Enjoy your project
Im currently researching the same thing.
The first thing you have to consider is "how professional" you want to deploy. There are a lot of tools you can use:
Continous Integration Server ( e.g. Hudson, Jenkins)
Build Tools (e.g. Phing, Capistrano --> Capifony, Shell scripts)
Versioning Tools (e.g. Git, SVN)
I think the simplest setup is using only a Build tool and i guess you are already using some kind of versioning.
Depending on which tool you use, the setup is different, but I think there are some things you should consider with your application (maybe not all are applicable to your application)
Creating a Tag in your Versioning
Copying the new Code in an folder on production
--> if you are in a new folder you dont need to clear the cache and logs, since these shouldnt be in your versioning the first time.
loading composer (if youre using it)
installing vendors
updating database schema
install assets from your bundles
move symlink from current version to the folder of the new site
These are the things I currently need for my application for production deployment, if you deploy to an test environment you should load fixtures and run your testscripts as well.
One other option that is very well described here is to deploy the Symfony2 application with Apache Ant. Apache Ant is a Java library and command-line tool whose mission is to drive processes described in build files as targets and extension points dependent upon each other.
I developed a website in wordpress and used several plugins. One of the plugin was http://wordpress.org/extend/plugins/background-manager/
Every thing was working fine on my machine. But as i get uploaded it to client server. the whole site stuck due to lower version of PHP. This plugin requires PHP 5.3 and on server we have PHP 5.2. Since its a shared server, we can't upgrade its PHP.
Then i look into the code of this plugin it was using PHP 5.3 feature namespaces. Is there any way to downgrade this plugin that it will work with PHP 5.2?
This is a really tricky problem, and of course, it's really, really bad practice to use old code for plugins as they may have fixed security vulnerabilities or other serious problems. It would be better for you to move the site to a server with more up to date PHP.
Having given that important warning, you can, however, browse to the tags directory in the plugin repository and extract the files you want for the previous version. Plugin history is public and always maintained.
For instance, for the plugin you mentioned, you can visit the SVN part of the plugin repository at:
http://plugins.svn.wordpress.org/background-manager/
You'll find the previous versions there under the "tags" folder, named after their versions.