Solution 1. Devel + Drush:
You can use devel drush command for module re-installation with all the module dependencies:
drush devel-reinstall modulename
There is also alias for this command
drush dre modulename
Solution 2. Drush:
This is something that I would typically use drush for
drush pm-disable mymodule
drush pm-uninstall mymodule
You only need to move your modules to the your new location and rebuild the regisry. When the registry rebuilds the path to the modules will be updated. Check registry_rebuild().
Rescans all code in modules or includes directories, storing the location of each interface or class in the database.
Although, I would recommend you to backup you database ...
There's just one step, using module_enable():
$modules = array('module1', 'module2'); // Array of module names
$enable_dependencies = TRUE; // Whether or not to enable dependant modules
You shouldn't really delete any files. If you really wanted to, you could delete the install file and various txt files, but that's about it. A better solution if you are afraid of security is to not let the files be accessed through the web server. Drupal only use the index.php file for serving content.
I think you didn't select English in the first step, and probably your Internet connection is behind a proxy and I guess Drupal doesn't support it.
You can select English and continue or:
Go to Translation server and download the specific language, the Spanish for example
Copy the download file in sites/default/files/translations
Continue with ...
NOTE The issue described in the Question has now be fixed in the latest Drush version.
No, Drush does not need to be installed as root.
I've submitted Drush pull #2246 to update the current Drush install instructions.
This install method fixes the issue as per Drush pull #2246:
# Download latest stable release using the code below or browse to github....
The problem is in the data array change name by label:
$role = \Drupal\user\Entity\Role::create(array('id' => 'client', 'label' => 'Client'));
Or you can use:
//your data array
$data = array('id' => 'client', 'label' => 'Client');
//creating your role
$role = \Drupal\user\Entity\Role::create($data);
//saving your role
Please make sure your webserver (nginx/apache) is using the same PHP version as your cli one. For example, you may encounter this issue if your cli PHP version is PHP 7.1 and your webserver is using PHP 7.0.
Have a look at the Drush make project:
There is also a companion website at:
This website allows you to select the modules you want to package with Drupal, and produces a Drush-ready makefile.
There are other varieties of this functionality out there, so I advise experimenting and testing with ...
The WYSIWYG module is not compatible with CKEditor 4, because CKEditor 4 uses double quotes " around it's version string, where CKEditor 3 used single quotes '. This breaks the version detection regex in the WYSIWYG module.
You could use CKEditor 3, like Bruno suggests, or you could patch the WYSIWYG module like described here https://drupal.org/comment/...
This is an nginx configuration issue and discussed intensely on this page Yet curiously no solid solution could be offered. Some guy on an other page proposed a solution. I applied that proposed solution and can confirm that in works!
To apply proposed solution go to your nginx configuration file under
/etc/nginx/sites-available/ directory on Ubuntu and ...
Hopefully you're not installing Drupal 8 in the hope of using it as a stable website...it's nowhere near ready yet :)
That said, the reason you're getting the error is because the PHP const keyword has only been available for use in the global scope since PHP 5.3. Drupal 8 uses const in the global scope in a lot of places (correctly, as Drupal 8 will ...
You can do this in hook_requirements, from the documentation:
During the 'install' phase, modules can for example assert that
library or server versions are available or sufficient. Note that the
installation of a module can happen during installation of Drupal
itself (by install.php) with an installation profile or later by hand.
As a consequence,...
Nothing wrong with that.
It is recommend to have the config folder outside of the public web folder; Drupal just doesn't have that. To keep the installation simple for non-experienced users, it puts that folder in the files folder, which has to be writable anyway.
Just create that folder and give Drupal write permission to it; you'll be fine.
You're missing the length property for the varchar column ('list'). length is required so the CREATE TABLE query will fail.
From the Schema API docs:
All parameters apart from 'type' are optional except that type 'numeric' columns must specify 'precision' and 'scale', and 'varchar' columns must specify 'length'.
I restored a backup from production locally and tried to just move things and hit admin/modules or to run registry_rebuild() but it didn't stop fatal errors from being thrown. This makes sense to me since some modules may use includes or whatever in their hook_init(), or you may have a menu router path set that depends on a module or include that Drupal can'...
The file's called .htaccess and it's in the root of the Drupal installation. A lot of operating systems hide files that start with a ., so that might be way you can't find it.
If it's simply missing, just download a fresh copy of Drupal and copy the default .htaccess file from there.
Variables are cached, so deleting manually is fine so long as you invalidate that cache, e.g.
->condition('name', 'mymodule_%', 'LIKE')
There are a few things you can do to help debug your drush. Here is what you can try:
Use drush cc all -vvv
This will provide you with some valuable information in terms of what Drush is doing in the background and maybe show you the actual error message.
Check your settings.php
Depending on your setup you may be passing in environment ...
You need to have the PDO driver for MySQL installed for Drupal 7. This is indeed different from Drupal 6. Instructions are at http://drupal.org/requirements/pdo. I hope those instructions are sufficient for you.
Try the cool tool from Mark Sonnabaum: Drush Rebuild Project Paths. It automates the process; worked great for me. Uses Drush, of course.
I will second the suggestion that you try this on a copy of your site database, though.
This happened to me with a couple of modules last week; the solution was simply to run cron, allowing the fields marked for deletion to actually be deleted. After that I could uninstall the module in question without issue.
To take a different angle:
It's very possible to do this, but you shouldn't. Your web server user should not have the capacity to write to the web root (except for designated folders like the public files folder). You should therefore not be able to delete module folders from code. Doing so presents a security risk to your server.
This is one of the checks ...
Yes it's safe to remove them. But I would recommend you not doing so. These modules are just tiny modules and it won't give more than 1 MB of space to your system.
However, if you are no longer using a module, make sure you have uninstalled that module. If you had search module enabled and if you are no longer using it, disabling it and uninstalling it ...
So You Want to Build a Drupal Distro
Take a look at Packaging a distribution on Drupal.org
Here are the steps:
Assemble the pre-requisites
Create a Drush Make file
Convert to a Drupal.org-specific Drush Make file
Build and verify it works
Commit your code to Git
Release your code on Drupal.org
Maintain your distribution
Another great tutorial How to ...
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 ...
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 ...