How to disable secure pages on a local server? - drupal

I've just moved a Drupal to my localserver and I forgot to disable Secure Pages.
Now I cannot access admin pages, because the site switches to HTTPS.
How can I disable it?

In your settings.php file:
$conf['securepages_enable'] = FALSE;
This will override the database setting.
In your sites/example.com/settings.php, leave this line out, and then it will use whatever value is in the database.

If you are using drush, you can keep the Secure Pages module enabled and just turn off the checkbox in the module's own config like:
drush vset securepages_enable 0
This will stop the redirect.
you can also change the URLs if you want, as follows, but the above is usually enough.
drush vset securepages_basepath http://nominet.dev
drush vset securepages_basepath_ssl http://nominet.dev
I'm running Drupal 7 btw, so YMMV, but seems to be a simple drush based solution following on from the above answer.

The way I've done it without disabling the module is to use SQL to change the variable setting. First backup your database (in case you put a semicolon in the wrong place; scratch that, always back up your database before making changes on the command line) and then run the following SQL on your database:
UPDATE variable SET value = 's:1:"0";' WHERE name = 'securepages_enable';
Then:
DELETE FROM cache;
DELETE FROM cache_page;
You need those two lines in order to clear the cache, otherwise the variable might stick around for a while.

If you have Drush installed:
drush dis -y securepages

I know this question is old and has been answered a few times, but there's another option that hasn't been suggested yet.
You could disable it completely:
// Disable SecurePages completely.
$conf['securepages_enable'] = FALSE;
and alter settings.php to enforce HTTPS depending on some context, e.g.:
if (isset($_SERVER['environment'] && $_SERVER['environment'] == 'staging')) {
$conf['securepages_basepath'] = 'http://staging.example.com';
$conf['securepages_basepath_ssl'] = 'https://staging.example.com';
} else if (isset($_SERVER['environment'] && $_SERVER['environment'] == 'production')) {
$conf['securepages_basepath'] = 'http://www.example.com';
$conf['securepages_basepath_ssl'] = 'https://www.example.com';
} else {
// We're on dev or some other server instance where SSL isn't needed.
$conf['securepages_enable'] = FALSE;
}
This is just an example, but it's been a helpful way for us to manage sites that exist on a dev server, a QA server, and a production server, where we want to track settings.php changes in version control without having to change things in each environment.

You can disable the module directly via the database. Just go into the system table, look for your module under the name column, and set the status field to zero.

Related

Javascript & CSS not loading after Drupal 8 migration

I have been given the task of moving two Drupal-based websites to a new server, not because I'm a Drupal expert but I'm the only one in the office with PHP programming skills. One is a Drupal 7 site, the other Drupal 8. These were both given to me as DevDesktop archives and SQL dumps. The Drupal 7 site was pretty straightforward - copied the contents of the docroot up to the new server, created and populated a new MySQL database and edited the default site settings file to point at the new dbase. So the Drupal 7 site works fine. Doing the same with the Drupal 8 site the main problem seems to be it won't load any CSS or Javascript.
In the Javascript Console it threw me off the scent slightly because it said the mime type of the CSS was incorrect, but on further inspection that's because the path to the CSS was returning a 404.
Compounding the problem is Antibot, and as Javascript isn't loading, although I have the username and password for the admin user, I can't login because Antibot keeps sending me back to the homepage telling me to enable Javascript. I have edited settings.php to enable /core/rebuild.php and tried that, but doesn't appear to make any difference. I've also manually truncated the 'cache_...' tables and that doesn't seem to work either. Note that I DON'T have access to SSH on the new server, so can't use drush.
Refused to apply style from '[]' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.
Failed to load resource: the server responded with a status of 404 (Not Found)
What it does look like to my non-expert eye is that Drupal is configured somehow to server up optimised versions of the CSS and JS from virtual directories /css/ and /js/, although those paths don't actually exist on the server. I checked the .htaccess file, but other than some clever stuff to deliver gzipped versions to gzip-capable browsers, couldn't see anything in there that would get the server to the correct file. Perhaps if someone could explain how Drupal routes a request to /css/ or /js/ to the right file, that would help my understanding further.
Ultimately I think this problem is because Drupal 8 wants to deliver optimised files, but the cache is screwed and Antibot won't let me get into admin to turn off aggregation.
I have full access to the server files and database, but not drush. Is there a way to turn off the CSS & JS aggregation apart from via the admin menus?
In this situation you can disable aggregation either :
by editing settings.php or settings.local.php :
/**
* Disable CSS and JS aggregation.
*/
$config['system.performance']['css']['preprocess'] = FALSE;
$config['system.performance']['js']['preprocess'] = FALSE;
or via sql, but you have to decode and unserialize blob data from the config table to make the changes, and then make the reverse process :
# Query :
SELECT name, CONVERT (`data` USING utf8) FROM config WHERE `name`='system.performance';
# Unserialize query output and edit data locally
$config = unserialize($output);
$data['css']['preprocess'] = FALSE;
$data['js']['preprocess'] = FALSE;
# Then serialize data and write it back into the config table
# (original encoding is probably `LONGBLOB` but it may differ depending on the backend).
Once you can ssh into the server, you will need to reset permissions and ownership under sites/default/files/ before enabling aggregation again :
mkdir -p sites/default/files/{css,js}
chown -R apache:apache sites/default/files/
chmod -R 0755 sites/default/files/
You may also want to check if the public file path setting (in settings.php) is properly set according to where these ressources are actually located :
$settings['file_public_path'] = 'sites/default/files';

Set default language for fresh Drupal 8 install

In Drupal 8 is there a way to automatically set the installation language for a new installation? I'll be basing it on the URL, I already have the logic to work out which language should be selected but unsure how to make it the default selection when doing a fresh install of Drupal.
To start, you can populate the install state parameters via some URL queries. Adding ?langcode=en would default it to English.
Otherwise, you would have to use a custom profile to ensure a proper default selection is made. The related code is in core/includes/install.core.inc. The install_drupal function is what performs Drupal's install. The langcode is determined in install_begin_request via the install state which is populated by install_state_defaults.
You'd need to get the langcode populated
if (!empty($install_state['parameters']['langcode'])) {
$install_state['parameters']['langcode'] = preg_replace('/[^a-zA-Z_0-9\-]/', '', $install_state['parameters']['langcode']);
}
Looking through the code, this is only possible via query parameters
// Add any installation parameters passed in via the URL.
if ($install_state['interactive']) {
$install_state['parameters'] += $request->query->all();
}
Unless you had a custom install profile that invoked hook_install_tasks to add a task at the beginning of the install process to set the default language code.

Symfony 2 reload translation cache

I'm using Symfony2 (soon 3), and we got some translations that are stored in the Database.
This means that when we run cache:clear the translations are fetched from the database and stored in the cache (on disk).
This also means users can change the translations directly in the database, but those changes aren't visible immediately.
Is there a way to only clear the translation cache files in Symfony? Without refreshing the whole cache?
I do this so
$cacheDir = dirname($this->getParameter('kernel.cache_dir'));
foreach (['prod', 'dev'] as $env) {
array_map('unlink', glob("$cacheDir/$env/translations/*"));
}
Just to complete answers already provided, removing the translations folder in cache/ won't be enough if you need to take new translation files into account.
For that, you'll need to also remove the file caching the path of all ressources and asset file.
Its name depends on the environment: appDevDebugProjectContainer.php or appProdProjectContainer.php.
So based on #Atmarama answer:
$cacheDir = dirname($this->getParameter('kernel.cache_dir'));
foreach (['prod', 'dev'] as $env) {
array_map('unlink', glob("$cacheDir/$env/translations/*"));
array_map('unlink', glob("$cacheDir/$env/app*ProjectContainer.php"));
}
Tested with Symfony 3.3.x.
Running ./bin/console cache:clear does not provide any options as to which cache folder should be removed. It just clears the complete folder and only handling warmup is configurable using options. For reference see the CacheClearCommand in the FrameworkBundle.
You could write your own command though that only checks for the translation-cache dir and clears it. By default it resides in a subfolder translations/ which should be easily accessible with a finder like this:
$finder = (new Finder)->in($cacheDir.'/'.$env)->directories()->name('translations');
foreach ($finder as $translationsDir) {
rmdir($translationDir->getPathname();
}

$cookie_domain value causes access denied upon login

I have FCK editor installed, and trying to enable FCK file manager.
It tells me that in order to use it, $cookie_domain must be set.
Easy enough, I set it to www.mysite.com. I can log in, register, etc just fine. However I started seeing a number of people get Access Denied after logging in or trying to access any protected area.
Commenting out $cookie_domain, users can get in fine.
I am looking for one of the following:
A. A harmonious answer where FCK file manager and $cookie_domain can be set
-or-
B. An alternative to FCK editor (like CK) that allows in-place file uploading without requiring cookie domain to be set (and interrupting user experience).
Change $cookie_domain in your settings.php into this:
$cookie_domain = substr($_SERVER['HTTP_HOST'], strpos($_SERVER['HTTP_HOST'], '.'));
This is what wound up working for me (Domain Access is installed):
$base_domain = explode('.', $_SERVER['SERVER_NAME']);
unset($base_domain[0]);
$base_domain = '.' . implode($base_domain, '.');
$cookie_domain = $base_domain;
Try setting $cookie_domain to simply mysite.com instead of www.mysite.com. This will avoid problems if users are accessing your site via just http://mysite.com or http://some-subdomain.mysite.com.
Try as an experiment to use the FCK filemanager when logged in at http://mysite.com (no leading www) -- does it fail or work under the current settings?
See under Domain and Path on http://www.quirksmode.org/js/cookies.html
Check the spelling of the domain name. I left an 's' off the domain name in the settings.php file and it caused this problem. Darn, I hate when I do that...
Just clear your browser cache and delete cookies as described here
Good luck!

Remove rows from the node table

Some nodes are displayed in the content list even if they don't exist anymore.
When I click on them I get an empty page.
I was wondering if I can just delete the rows from the "Node" table or I should clean something else.
thanks
First: on the administer page, go to performance, and click on the clear all caches button. If it doesn't solve your problem, then try disabling every contrib, and see if the problem still exists. If not, try enabling them one-by-one, and you will know which contrib made the problem. Report it to the module's issue queue.
If disabling modules doesn't solve your problem, download drush. Try deleting the node directly with node_delete. Example (if the wrong node's nid is 3):
drush php-eval 'node_delete(3);'
If you are not familiar with the command line, you can do the same with this little PHP file (put it into the Drupal's root):
include './includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
node_delete(3);
If it doesn't work then make a backup from your database, delete the node from the node table and go through every node-related table (which has a nid column), and delete the related entries.
This may not be your problem but:
You don't want to delete rows directly from the database. You'll end up with no way of knowing what shape your database is in afterwards. Node IDs exist in many tables and nodes are distributed through more than one table.
Go through the nodeapi and use the Drupal framework because that's what it's meant for! The node api will treat your database schema correctly.
See:
http://api.drupal.org/api/function/node_delete/6
So if you know the node ID, you can call node_delete.
Note that (depending on your Drupal permissions) you will likely need to be operating as a user with permissions to delete nodes -- such as user-1 rather than the default anonymous user. You can do this by pre-appending your node_delete() call with,
global $user;
$user = user_load(1);
You may also experience a timeout if deleting many nodes and invoking the PHP file via a browser. One fix for this is to invoke the PHP file via the command line (if you have shell access). For example,
php -f custom-script.php
Again, if you are deleting many nodes, you may also run out of memory. Increase the PHP memory limit for your script's invocation like this,
php -f custom-script.php -d memory_limit=512M
This works against my tests with Drupal 6. Note that you may also be able to fix the server timeout issue by setting an explicit timeout in the custom-script.php.

Resources