If you use Drush you can update all security issues with your site via (this is Core and 3rd party modules):
drush up --security-only
if you want to see what it will do, but not do any of the actual changes you can issue:
drush up --security-only --simulate
If you want an easy way to update Drupal Core to the newest release you can use a patch site such as:...
You can use drush pm-update to update any module, and add the version information to update to a specific version. For example if you want to update to a 7.x-1.x-dev version of a module, you can use the following command:
drush pm-update MODULE_NAME-7.x-1.x-dev
drush up MODULE_NAME-1.x-dev
so you can omit 7.x-.
As mentioned in the original question, and follow-up comments, there are a variety of contrib modules and manual methods to accomplish this.
To do it automatically, or in a custom fashion, I think hook_update_N() is still probably the most viable option.
For instance, this is an example from the Head 2 Head to update system.site to set the default_langcode:...
Solution 1: SQL Query
While checking updates Drupal creates some rows inside the key_value table which should be deleted after checking is complete but looks like they doesn't for some reason. So deleting the related rows manually solved my problem:
DELETE FROM key_value WHERE collection = 'update_fetch_task';
Solution 2: hook_update_N()
If it is not ...
In short, if your site runs on PHP 5.3, it will run on 5.5 as well, go upgrade! (Your dev environment, until a real release is out)
With the short answer out of the way, here are some more details.
With regard to "Does Drupal work on it", very little changed from PHP 5.3, to 5.4 to 5.5.
The one issue that showed up under PHP 5.4 was really just PHP being ...
drush entity-updates is a developer tool. If you change entity/field definitions in your custom module you can quickly apply this.
In production this should not happen. If you update a module between official releases, then the update code in the module should handle this.
But in your case you are mentioning that your site is in developing. So there are a ...
The schema_version column in the system table contains the version of the last successful update. Manipulate that value and you can re-test your update.
The name column is the machine name of the module, same as the info file is named.
This query will do the trick for you.
UPDATE system SET schema_version = XXXX WHERE name = 'name_of_module';
There are few ways of forcing module update.
Calling the update function directly.
$sandbox = ;
Resetting the schema version to the point of interest and run the updates again as usual.
Or reset to re-run only the latest update ...
FYI, in Drupal 8, the system table has been removed, and this information is now stored in the key_value table.
UPDATE key_value SET value='i:8000;' WHERE collection = 'system.schema' AND name = 'module_name';
(As noted above, the actual value should be less than the hook_update_N() you want to repeat, but higher than or matching the last update that does ...
If you're using drush, you may run:
drush eval 'menu_rebuild();'
If won't work, see: How to do menu rebuild when having PHP Fatal error?
drush php-eval 'drupal_rebuild_theme_registry()'
If you're using memcached, you've to restart it.
On Linux: /etc/init.d/memcached restart
On OS X (if using Homebrew): brew services ...
Just providing a code sample to help the chosen answer:
//dsm($projects); // view a list of projects
Enter the module name in the $projects variable to disable. If you're not sure what the slug is (will be lowercase and ...
Assuming you are using Composer to maintain your Drupal 8 installation, you can use the following command to update core and all modules (and dependencies).
composer update drupal/* --with-dependencies
If you started you project from "drupal-composer/drupal-project" the command becomes the following.
composer update drupal/* webflo/drupal-core-...
You can do it in two ways.
drush pm-updatecode --lock=module_to_ignore
Use the update_advanced module. It allows you to mark modules
that you want to ignore on the module administration page.
In particular, the per-project settings to ignore certain projects or
even specific releases, is absent in the core version of the module.
The "Update status ...
As I landed on this question as well but did not really find the correct answer for my situation here, I'd like to add another answer.
Please note: Anti-pattern ahead!
When we're developing projects we constantly update our test / acceptance environment with new configuration updates. Take for example a simple fictional News-module, we'd like to ...
"post_update" hooks that have been run are stored in the database, in the key_value table, post_update collection, but the data is serialized and awkward to update directly.
I used some of the details from @kiamlaluno's answer to create a drush script which you can use to reset a single hook. Here's a basic version (longer version is here):
Another reason why an update hook would not run is a mismatch between the update hook name and the major release number of the module (see .info file).
For example: the update hook mymodule_update_7001 does not run if the module version is 7.x.1.0. In such case you must rename the hook to mymodule_update_7101.
See the hook_update API documentation
Updates must be run before configuration is imported
A pending issue against core will ensure that the code and schema versions match before allowing configuration to be imported.
Problems with config import before updates
An update hook relying on a configuration value could end in a different result than if it were run on the pre-import value.
An update ...
Open the database schema, then delete all contents of menu_links and menu_router tables with the following SQL queries:
DELETE FROM menu_links;
DELETE FROM menu_router;
Then run http://example.com/update.php. It will call menu_rebuild(), which will populate these tables with 'fresh' data. It worked for me after a "PHP Fatal Error: Out of memory" turned ...
I presume that you are using drupal-composer/drupal-project as the basis for your project. If not, take a look at that project, and compare it with yours.
Also, you said that you want to use composer to manage Drupal 8 dependencies, so I presume that you have selected your contrib modules via composer require drupal/devel rather than drush dl devel.
Download drupal 8.0.2
Copy the core directory into your project.
Copy the .htaccess , composer.lock & composer.json files to your project
Copy the vendor directory to your project
Go to yoursite.com/update.php
Follow the on-screen instructions
Note: if you use composer then see my answer to this question
It might be issue with permissions of Drupal root directory.. Try running them as sudo
sudo drush up
Above command updates all enabled modules and core in Drupal...
sudo drush up drupal
which updates only core.. It worked for me.. I Updated from 7.22 to latest 7.27..
Try with -v for more information..
sudo drush up drupal -v
Use the theme installer service to enable and disable themes .
Install a list of themes:
Uninstall a list of themes:
Finally, i could update with these modifications.
Step 1, optional in case your composer.jsoncontains this. If it is ok, apply step 2
delete this folder :
delete this file :
composer update --with-...
No module needs to implement every hook. You can use hook_update_n() and not have a hook_install() function just fine.
You'll probably at 1 point want to define hook_schema() for these tables. An easy tool to get the "drupal" schema for any mysql table (already defined) in your mysql database is the Schema module.
Schema documentation: hyperlinked ...
The first bit of advice here is to always run drush up on a dev or staging site first, before running it on a production site. Sometimes, due to bugs or incompatibilities, upgrades can break a previously-working site. It is therefore always best to test your upgrade before bringing it live. After testing, it is also best if you move the exact files that ...
update.module doesn't know about git.
It only understands .info(.yml in D8) files. And .info.yml files only get their version as part of the package building process. If you look at your system.info.yml, it doesn't say anywhere that it is beta6.
There is a module called git deploy, that is trying to fill that gap and extracts version information from git ...