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).
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'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.
After months using Drupal for my websites I noticed module uninstall tab in the modules list.
I've always uninstalled my modules by deleting their folders from filesystem (after disabling them). I was wondering if this is the wrong way to remove them.
Thanks
When you uninstall the module, rather then just disabling and removing, you let the module clean up after itself, including:
Delete tables it created
Delete system variables it used.
So uninstalling is a good clean, for the health of your database. Things will work fine not doing it, but why keep unused tables in your database?
Note:
It's up to the module creator to create the code needed to do the clean up, so not all modules do this very well.
I've always uninstalled my modules by deleting their folders from filesystem (after disabling them). I was wondering if this is the wrong way to remove them.
The files used from a module is not the only thing a module leaves on a Drupal site; there are database tables, Drupal variables, cached values that still need to be removed, when uninstalling a module. It's also possible that a module adds rows into a database table created from a different module.
Deleting the module files, you are not removing any reference to the module contained in the table system. This means that if you are copying back the same module after you deleted it, and you did delete its tables, the module is not going to re-create the database tables it needs.
I would definitively say it is the wrong way to uninstall a module.
Uninstalling is sometimes needed, as hook_install() won't fire if a module is just disabled. So if for example a module has some corrupted data, disabling and re enabling won't remove that.
You will probably be ok in your approach. However one thing to be weary of is doing the following.
Disable
Remove folder
At a later date put module back again (not the same version)
Uninstalling.
The reason for this is hook_install() and hook_uninstall() should be mirror images of each other. Update hooks are used to keep a module schema and settings up to date with what is provided in hook_install(), if you were to use an updated module to uninstall (without updating) it will be trying to uninstall a different set up to what is expected. The risk is slim that something would go badly wrong, but it is worth being careful.
The uninstall tab will remove anything in your database related to the module. This operation requires the module to still be present in your modules directory.
Simply deleting the files isn't 'wrong', but it will leave unneeded cruft in your database. The uninstall tab will not remove the module files for you, you need to do that yourself as you have been doing.
Drush makes the module uninstall process much more pleasant, with something like:
drush pm-disable [module] // or its shorthand drush dis [module]
drush pm-uninstall [module]
In fact, Drush makes just about everything more pleasant (downloading/installing modules, dealing with install profiles, creating DB backups, and my personal favorite, updating your entire code base). If you're not already using it, I highly recommend giving it a try.
You can check this link - modules may have some additional uninstall instructions for them, but it looks like majority of them don't - that's why you didn't have any issues :)
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/