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 :)
Related
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.
recently, i upgraded to Flex Hero 4.5 and created a new workspace. Then, i imported a project from the former workspace and started working. when i tried to upload the project from the new workspace to codereview, i got the error message: could not guess version control system. Are you in a working copy directory? How does one resolve this issue?
thanks
I have read somewhere that i need to checkout my svn but i thought that you only checkout when you want to get a folder/file from the svn.
Sounds like you've got a bit of a mess unfortunately. Hopefully you're not in the habit of doing a ton of changes without checking in. I would suggest you:
Back up your latest changes to a safe location
Check out the project from SVN into your new workspace (which is what you should have done initially) - creating a brand new project folder
Merge the changes you've made into the now-correctly-versioned copy of your project (you could do this by just copying files from the "latest"/project backup folder overwriting the SVN versioned files, but if you do--do NOT overwrite any .svn folders). You could also use a tool such as WinMerge or WinDiff to find differences between the two projects (of course ignoring .svn folders).
If you have a small number of changes it shouldn't be bad, but if there's a lot, you might want to follow SolarBear's branch suggestion, if WinMerge isn't going to cut it.
If I understand correctly your latest comment, you did a svn export on your code. The export command, as the doc mentions, creates a "clean" directory tree, i.e. without the .svn directory. So basically, these are files not controlled by SVN; also, you lose all the history of your files. The best way would have been, I think, to do a checkout in your new workspace and then work from there. It could take some time, but it's much easier to manage afterwards.
One possible way to make this work would be to checkout a clean copy your code somewhere safe and then merge your changes into this clean copy. However, if your trunk or branch changed a lot in the meantime, this could be very, very tedious. I could then suggest to branch your trunk, checkout that new branch, slowly merge your changes into that branch and when you're done and everything's working OK, merge the branch back into the trunk.
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-
I never know what to do when my Wordpress installation tells me there's an update available. I am using version 2.8 so whenever there is an update, all I have to do is click update, some magic happens behind the scenes, and it gets updated. But should I create backup files? And how? I have custom themes and plugins that I don't want to get lost because I don't have backups! Is it safe to assume that nothing bad will happen when you click the upgrade button? What is your process when you decide to upgrade to the newest version?
Backup the database, wp-content directory and configuration files first.
There are plug-ins to make this easier, but since you're asking on StackOverflow, I'll assume you could write a script to do it yourself. While you're at it, add the script as a cron job.
http://codex.wordpress.org/WordPress_Backups#Backup_Resources
Always backup before making a big change like that.
You'll want to copy all your files to a safe place via FTP. Copy 'em, zip 'em up, and keep them somewhere safe where you can remember where they are. You'll also want to backup or "export" the database and keep that also safe. This way if something goes wrong, you can restore it to the way it was.
There's a good backup script here for Wordpress sites:
http://www.guyrutenberg.com/2008/05/07/wordpress-backup-script/
based on Bash and bzip2.
I usually don't update nothing in production without testing it first, unless is a simple modification and is about security (like the 2.8.4 update).
The ideal thing to do is create a separate installation to be a test server: can be in your local machine, or just a whole different installation in your server. Why? Remember you have plugins installed and some may break, updating everything can't be a "blind" decision!
So, before updating in the production installation/server, always test in the "test environment".
Nothing is worse than having your website down because of an update error.