I'm helping my university switch from Lenya to Drupal for their CMS. We plan on offering a drupal install to every department that wants one. The installs will all share the same codebase (the custom drupal "template" I'm developing now) but will each have their own database, allowing each site to have its own users, nodes, etc.
The problem I have is when, after making changes to the template, I'd like to update all of the installations. If the change is to core code or that of an installed module, for example, there's no problem since all installations are running off the same codebase. If, on the other hand, I need to make changes to the database, I'm screwed because there's a tonne of installed databases, and they're all different and need to be preserved. Even for simple changes like installing a new module, the module shows up fine on the list of installed modules, but I have to manually go into each installation and enable it by hand.
There must be an easier way! Is there some easy way (like a module I haven't heard about) to force drupal databases to update certain tables from a master database? I'm thinking of something similar to the "update.php" script that I could invoke en mass from drush.
Thanks for the help, all!
You can try to use drush make for that. Check out this site http://drushmake.me/ to see example of how it looks like. All you need is to install drush script to your server http://drupal.org/project/drush. And later you can build your own .make files and run it for different database.
Related
I have a WordPress website up and running with many plugins installed on it and a huge database, I need to use chef-solo in order to create an environment in which can install the same website with all its plugins and and also importing its database.
I need it to be like, using chef to install the same website on a different server, exactly the same
Now here are my questions:
I know we can use chef to install WordPress but can we set it in a
way that we don't need to configure the the WordPress and everything
is already set once its running?
What to do with the plugins? can we install them using the chef or
now that should be done manually?
How about importing the database, that can be done with chef-solo
as well?
The whole website is on git, can I somehow import the whole
thing?
is there any other issue I may possibly face? if I want do that?
There is a wordpress cookbook openly available for chef.
When you mean configure, I take it you mean setup data in the database. Assuming that you've separated the database instance from the server instance, and you're attempting to scale up the number of servers then you should be able to skip data setup. You should be configuring the new server instance (node) to point to the same database via Chef.
I stumbled into this question looking for the answer to this question. From what I can tell the start may be here.
Kind of hand-wavy, but this should enable you to do some wordpress stuff via the command line with Chef, rather than the point and click it prefers.
As per #1, you should not need to import the database. If the database goes down, you'll want to focus on that as a separate but connected recipe, since then you'll want to be taking snapshots and uploading them somewhere like S3 via a cron job. I believe there are plugins that can enable this.
You'll have to be a little more clear by "import". If it's in a code base you may be able to short-cut your cookbook path by pulling down the git repo onto the host. You may want to look at git-archive.
Other issues that I'm looking at are images. We're migrating from a hosted solution to AWS, and it appears that instead of storing the images in the database, word-press pulls them into a local directory. This means that if we scale to > 1 host, we'll have issues with images. Something to think about, there's a wealth of plugins that can probably solve this.
Hope this is helpful,
Ben
I've developed WP sites and themes before, but mostly independently, and mostly live via FTP.
This seems to be frowned upon, and it also seems like a stupid way to continue if I want to start with preprocessors, which look amazingly useful and fun.
So local development makes sense, with MAMP for the WordPress requirements, and something like codekit because I am no terminal ninja. But I'm also going to working within a team -- so, test server that everyone can access?
I used Logmein to get into someone else's system years ago, but I can't imagine that's standard practice.
This seems like a basic thing, and I'm sure there's knowledge that I'm missing, but how do people set something like this up? What are best practices for team projects?
Working with WP is tough on a team. I can explain what I typically do when working within a team:
Git
USE IT!! This is especially when two or more people are working on the same project. Once you start using it, you will use it even when it is just you working on a project.
A team I freelance with uses Bitbucket as it provides free private repos, and a program called Sourcetree (made by the Bitbucket team), which is a decent git GUI. The GitHub app is pretty decent as well, however Sourcetree has a few more options.
Wordpress Workflow
Each team member works locally using MAMP, because using CodeKit or Grunt and LiveReload just makes the world a better place, and load repsonse times are way shorter.
Just the WP theme folder that is being developed is pushed with git to the repo.
We include a sql export folder (named 'db') within the theme folder, typically structured like this:
THEME FOLDER
|-(theme files and folders)
|
|-db
|-/-local
|-|-/-team_member_name_1
|-|-|-/-(local sql exports)
|-|-/-team_member_name_2
|-|-|-/-(local sql exports)
|-|-dev
|-|-/-(sql exports from development site)
|-|-production
|-|-/-(sql exports from production site)
The local folder has a folder for each team member to put their exports in. These can then be merged as needed for the dev site. (Note: The db folder is never put on the production server-it's just used to pass sql exports back and forth with git)
It seems like no matter what, importing and exporting sql databases are the only hurdle in a streamlined workflow. We just try to keep doing it to a minimum.
So our basic flow of a project is:
Setup and install a WP dev site (www.devcompanyurl.com/wpdevsite)and database
Setup and copy of the site locally using MAMP
Connect theme files to CodeKit/Grunt
Establish project repo, use git to push a master set of theme files that the rest of the team will download and work from.
Then it's just a matter of pushing, pulling, and merging files, and doing the occasional .sql import.
Hope this helps!
I have a drupal based website with too many enabled modules, and i need to know what are the modules that have updates?
in other words, i need to update all of my modules to the latest release.
how can i get a list of all of out of date modules and what is the best way to update them?
i think there will be a better choice to update modules than downloading the latest release to /sites/all/modules and the run update.php
thanks for your help
Actually, a manual update is the only solution (that I know for sure works in the way it is supposed to work) in Drupal 6.
You get a list of updated modules from the admin/reports/updates page.
With Drupal 7, you have the ability you use admin/reports/updates/update and update the modules. I haven't had the chance to test that myself but I assume that it should work ok. But still, Drupal core needs to be updated manually.
If you have SSH access to your website, consider installing http://drupal.org/project/drush Drush and use the command
drush pm-update
If all goes well, your site has the latest versions of all modules and Drupal itself upgraded in less than 5 minutes. Make sure to create a backup of the site before, however (modules and database).
I have been developing a Drupal 6 site on my PC using XAMPP. I'm done now, and everything looks peachy.
Problem is, I need to put all my content (including custom modules and themes) up onto a staging server which only has a fresh Drupal 6 install on it. I can't imagine having to set up all my custom content types and whatnot all over again on the staging server.
So I ask, how does one go about doing what I need to do? Which is essentially duplicating my Drupal install from my PC, to the staging server.
The staging server is running Linux, and I develop on a Windows PC, if that helps.
Thanks in advance.
Copy up all the files from development to live, and mysqldump your database and run that on the live server. Then all you have to do is change the settings.php file to point at the right database, if for some reason 'localhost' is not also your mysql database.
The quickest solution is probably the backup_migrate module. It is only a tool to copy your database. You could also use phpmyadmin or similar instead if you wanted. The backup_migrate module do have some good defaults settings as to which tables to skip (like cache tables). All the settings etc. that is not defined in code is stored in your db. So you only need to copy the db to be set. You can choose to exclude some tables, like the node or user table if you don't want to bring over your test data.
If you don't use subversion, then you gotta manually copy the files (rsync, scp, whatever) and the db (mysqldump).
what we usually do is have a hierarchy of independent subversion repos as follows:
core
sites/all/modules/contributed
sites/all/modules/custom
sites/all/themes/ (we develop our own and don't use contributed themes)
sites/all/libraries
then we use the svn:externals properties so that if you check out "core" you get every associated repo.
we got about 2 main developers with 4 other guys that may also contribute code to the site. each have their own local dev environment and we all got a common sandbox - where we make sure the stuff we wrote doesn't break someone else's module (it has happened before!).
we use svn commit hooks to update the beta/staging/sandbox site upon commit.
with all that setup, [re]deploying a site is a simple matter of going to the proper folder and issuing a "svn co http://repolocation/reponame ." and then updating the DB.
two last things to consider:
we are moving from svn to git
the features module will allow you to save changes you make to your own modules (views, content types, etc) and package all that into a deployable module so you don't have to duplicate your efforts. we are also looking into using this for ourselves.
I hope this helps you.
I second using backup_migrate. It's great.
When I'm installing a fresh site from development to production, I:
backup the site using backup_migrate module
copy all the files up to the server
edit the sites/default/settings.php to have the right database path and account info
do an import of the last backup_migrate dump (usually using mysql < backupfilename.sql, unless I already have drupal setup and have backup_migrate installed, then I use the GUI
But take a look here for the official version:
http://drupal.org/node/776864
Now, you didn't ask, but when the site is live and users are contributing content, moving future development versions of your site from development/staging to production without blowing away live content is a whole different problem, and one that Drupal doesn't have a good answer for...
Andy-
Can you help me to understand, how do I do Drupal website deployment and development?
Suppose, I developed 1.0 version of Berty&Frank website. I copied everything to their production server and it is alive and kicking now. Site is already full of contents and is growing.
I am asked to add additional features to the website. I am now experimenting with the way how I can implement them in a dev version. I am creating/deleting content types, fill created nodes with demo data just to see how they look like etc. Now I found the way and I want to upgrade production website to the same structure as my dev version now. How do I do that?
Is the only way to manually make every change I made in dev version?
I would explore the Aegir project for the future management of your website. It allows you to clone a site, then to upgrade the site to a new "platform" which could be the next release of Drupal or another Drupal system (such as OpenAtrium).
More can be found at the aegir wiki.
You can export/import views and contenttypes, but a lot of settings etc is stored in the db. This gives two options
Either to use something like backup & migrate to import your settings from dev. This wont work if you have test data though, as you would overwrite the db.
The other options is to repeat what you did on the live site.
A third options could be to take a fresh dump of the live site, do all the settings in that db in dev environment and overwrite the live db with that. You could loose some comments etc, but shouldn't be a big deal.
I use Subversion, and just do an update on my production server when I am satisfied with the code on my development server (actually, I have a staging server that is a duplicate of the production machine, so I update that before the production; I can see any bugs that might pop up).
For database changes, I haven't found anything better than just keeping track of my changes (usually adding/modifying CCK fields) and performing the same changes to the production database. I also download my production database regularly, so that dev and staging have almost the same content. That helps to minimize the confusion.
read http://www.drupal.org/upgrade/