I have a module with a drupal_goto() that redirects users if they don't pass the age requirements (wine site) in hook_init(). The module is set with a heavier weight so it loads last.
On PHP 5.3, drush update fails. The same code and DB on a different server with PHP 5.2 runs fine.
Drush version: 7.x-4.4
PHP version: 5.3 example:
When I run: drush status, I get an error. Here is the output with the debug and verbose flag.
$ drush -d -v status
Bootstrap to phase 0. [0.02 sec, 2.47 MB] [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drush() [0.03 sec, 2.67 MB] [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_root() [0.06 sec, 5.49 MB] [bootstrap]
Initialized Drupal 6.22 root directory at /var/www/example.com/public_html [0.07 sec, 6.28 MB] [notice]
Drush bootstrap phase : _drush_bootstrap_drupal_site() [0.07 sec, 6.29 MB] [bootstrap]
Initialized Drupal site default at sites/default [0.07 sec, 6.29 MB] [notice]
Drush bootstrap phase : _drush_bootstrap_drupal_configuration() [0.08 sec, 6.29 MB] [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_database() [0.08 sec, 6.33 MB] [bootstrap]
Successfully connected to the Drupal database. [0.08 sec, 6.33 MB] [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_full() [0.09 sec, 6.67 MB] [bootstrap]
Drush command terminated abnormally due to an unrecoverable error. [0.34 sec, 31.38 MB] [error]
The question is now: Why does the drupal_goto() cause drush to fail on the PHP 5.3 server and not the PHP 5.2 server.
You should not issue redirects when there is an access denied. That is a logical error in any web-framework. You should issue an "access denied" when you want to deny access. Just like you issue a "the content has moved there, please go there" when your content has moved.
Instead of drupal_goto(), use drupal_access_denied(). If you truly want people to be redirected to another url, the place to do that, would be on the page that shows the denied access.
That said, issuing a drupal_access_denied(), or, in fact, sending any header in hook_init() is plain wrong. From the documentation: «Perform setup tasks.» Sending headers is not a setup-task. Moreover, that same documentation warns about another potential problem with your approach: «This hook is not run on cached pages», in other words, once an adult visits a page, and it is cached, underaged visitors will not be redirected or denied access, they will get the cached page served.
Now, on to what you should do:
A module such as Taxonomy Access (Lite) or the more appropriate Node Privacy By Role can be used to grant access to your content. Note that, by default, Views will not use these access: they will show lists of content, regardless of the access by the user: you will have to reconfigure all your views to either honor the access-rules or to be inaccassible entirely, to certain roles.
In addition, you need to give "minors" a separate role: that way you can grant them different access then the people in rol "authenticated user" or even in "adult". You will need some mechanism to automatically assign roles.
Related
When I try and run any drush commands within ddev (even just drush itself), I get a BadRequestHttpException. My drush version is 11.0.9 . I have tried ddev restart, ddev stop/start, and ddev delete; all have the same outcome. I ran ddev composer install too and no difference. It was working at some time, but maybe a week or so ago it just stopped. Here is the verbose response from ddev drush -vvv (sorry for the large output wall):
ddev drush -vvv
[preflight] Config paths: /var/www/html/vendor/drush/drush/drush.yml
[preflight] Alias paths: /var/www/html/web/drush/sites,/var/www/html/drush/sites
[preflight] Commandfile search paths: /var/www/html/vendor/drush/drush/src,/var/www/html/drush
[info] Starting bootstrap to max [0.8 sec, 3.2 MB]
[debug] Trying to bootstrap as far as we can [0.8 sec, 3.2 MB]
[info] Drush bootstrap phase: bootstrapDrupalRoot() [0.8 sec, 3.2 MB]
[info] Change working directory to /var/www/html/web [0.8 sec, 3.2 MB]
[info] Initialized Drupal 9.3.14 root directory at /var/www/html/web [0.81 sec, 3.27 MB]
[info] Drush bootstrap phase: bootstrapDrupalSite() [0.82 sec, 3.28 MB]
In DrupalKernel.php line 372:
[Symfony\Component\HttpKernel\Exception\BadRequestHttpException]
Exception trace:
at /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php:372
Drupal\Core\DrupalKernel::findSitePath() at /var/www/html/vendor/drush/drush/src/Boot/DrupalBoot8.php:109
Drush\Boot\DrupalBoot8->confPath() at /var/www/html/vendor/drush/drush/src/Boot/DrupalBoot8.php:158
Drush\Boot\DrupalBoot8->bootstrapDoDrupalSite() at /var/www/html/vendor/drush/drush/src/Boot/DrupalBoot.php:158
Drush\Boot\DrupalBoot->bootstrapDrupalSite() at /var/www/html/vendor/drush/drush/src/Boot/BootstrapManager.php:291
Drush\Boot\BootstrapManager->doBootstrap() at /var/www/html/vendor/drush/drush/src/Boot/BootstrapManager.php:477
Drush\Boot\BootstrapManager->bootstrapMax() at /var/www/html/vendor/drush/drush/src/Boot/BootstrapManager.php:412
Drush\Boot\BootstrapManager->bootstrapToPhaseIndex() at /var/www/html/vendor/drush/drush/src/Boot/BootstrapManager.php:384
Drush\Boot\BootstrapManager->bootstrapToPhase() at /var/www/html/vendor/drush/drush/src/Boot/BootstrapHook.php:32
Drush\Boot\BootstrapHook->initialize() at /var/www/html/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/InitializeHookDispatcher.php:44
Consolidation\AnnotatedCommand\Hooks\Dispatchers\InitializeHookDispatcher->doInitializeHook() at /var/www/html/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/InitializeHookDispatcher.php:36
Consolidation\AnnotatedCommand\Hooks\Dispatchers\InitializeHookDispatcher->callInitializeHook() at /var/www/html/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/InitializeHookDispatcher.php:29
Consolidation\AnnotatedCommand\Hooks\Dispatchers\InitializeHookDispatcher->initialize() at /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php:145
Consolidation\AnnotatedCommand\CommandProcessor->initializeHook() at /var/www/html/vendor/consolidation/annotated-command/src/AnnotatedCommand.php:335
Consolidation\AnnotatedCommand\AnnotatedCommand->initialize() at /var/www/html/vendor/symfony/console/Command/Command.php:221
Symfony\Component\Console\Command\Command->run() at /var/www/html/vendor/symfony/console/Application.php:1027
Symfony\Component\Console\Application->doRunCommand() at /var/www/html/vendor/symfony/console/Application.php:273
Symfony\Component\Console\Application->doRun() at /var/www/html/vendor/symfony/console/Application.php:149
Symfony\Component\Console\Application->run() at /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php:124
Drush\Runtime\Runtime->doRun() at /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php:51
Drush\Runtime\Runtime->run() at /var/www/html/vendor/drush/drush/drush.php:72
require() at /var/www/html/vendor/drush/drush/drush:3
include() at /var/www/html/vendor/bin/drush:112
Failed to run drush -vvv: exit status 1
Any guidance would be helpful.
So what the issue turned out to be was the port in the settings.ddev.php didn't match the port that was registered to the database - it didn't match what was returned with ddev describe. I deleted the settings.ddev.php file and ran a new ddev pull with my provider to regenerate the settings file and that resynced the ports and resolved the issue.
After succesfully installing local axon-server-se version 4.4 I am not able to register users. I am getting 403 back from axon-server (forbidden). Users command, which should list all users on axon-server, returns empty result.
Register a user:
java -jar axonserver-cli.jar register-user -S https://AXON_SERVER:8024 -t TOKEN -u admin -p test -r ADMIN
results in
Error processing command 'register-user' on 'https://AXON_SERVER:8024/v1/users': HTTP/1.1 403 - {"timestamp":1599137927417,"status":403,"error":"Forbidden","message":"Forbidden","path":"/v1/users"}
This is a known issue for Axon and it is already fixed on 4.4.1 version, which was released yesterday!
As of version 4.4.1, you have a new properties for this case: axoniq.axonserver.accesscontrol.adminToken. This property should get the token you want to use on CLI as Admin.
If you have to stick to 4.4 though, the workaround is to create the very first admin user with access control disabled and enable it afterwards.
I am not able to upgrade to drupal 8.6.2 using drush 8.1.17. Unfortunately, drush does not provide the reason behind its failure. I have no clue of what do do next, and even how to debug it further. Any help is appreciated, thanks in advance.
It follows an excerpt of the command $ drush --debug up drupal, you can find the (almost) complete log here (I only removed the untar output to have a smaller file such that can be pasted on pastebin)
Calling chdir(/var/www/html) [94.7 sec, 14.02 MB] [debug]
Calling is_readable(/tmp/drush_tmp_1539963315_5bc9f9b34e37c/drupal-8.6.2) [94.7 sec, 14.02 MB] [debug]
Calling is_writable(/var/www/html) [94.7 sec, 14.02 MB] [debug]
Calling rename(/tmp/drush_tmp_1539963315_5bc9f9b34e37c/drupal-8.6.2, /var/www/html/drupal-8.6.2) [94.7 sec, 14.02 MB] [debug]
Calling _drush_recursive_copy(/tmp/drush_tmp_1539963315_5bc9f9b34e37c/drupal-8.6.2, /var/www/html/drupal-8.6.2) [94.7 sec, 14.02 MB] [debug]
Unable to copy /tmp/drush_tmp_1539963315_5bc9f9b34e37c/drupal-8.6.2 to /var/www/html/drupal-8.6.2. [116.8 sec, 14.02 MB] [error]
Unable to move /tmp/drush_tmp_1539963315_5bc9f9b34e37c/drupal-8.6.2 to /var/www/html/drupal-8.6.2. [116.8 sec, 14.02 MB] [error]
Updating project drupal failed. Attempting to roll back to previously installed version. [116.8 sec, 14.02 MB] [error]
Returned from hook drush_pm_updatecode [116.8 sec, 13.92 MB] [debug]
Rolling back update of Drupal core code ... [116.8 sec, 13.92 MB] [notice]
Verifying signature for svn version control engine. [116.8 sec, 13.92 MB] [debug]
Executing: svn info drupal-8.6.2
sh: 1: svn: not found
Verifying signature for bzr version control engine. [117.1 sec, 10.88 MB] [debug]
Executing: bzr root drupal-8.6.2
sh: 1: bzr: not found
Calling drush_delete_dir(/var/www/html/drupal-8.6.2, 1) [117.2 sec, 10.88 MB] [debug]
Calling is_readable(/var/www/drush-backups/the_site_com/20181019153440/drupal) [121.8 sec, 10.88 MB] [debug]
Calling is_writable(/var/www/html) [121.8 sec, 10.88 MB] [debug]
Calling rename(/var/www/drush-backups/the_site_com/20181019153440/drupal, /var/www/html/drupal-8.6.2) [121.8 sec, 10.88 MB] [debug]
Backups were restored successfully. [121.8 sec, 10.88 MB] [ok]
A couple of info that might be useful:
root#host:/var/www/html# su www-data -s /bin/bash -c 'drush --version'
Drush Version : 8.1.17
root#host:/var/www/html# su www-data -s /bin/bash -c 'drush core-status'
Drupal version : 8.5.3
Site URI : http://default
Database driver : mysql
Database hostname : the-database-hostname
Database port :
Database username : the-database-username
Database name : the-database-name
Database : Connected
Drupal bootstrap : Successful
Drupal user :
Default theme : mytheme
Administration theme : seven
PHP configuration : /usr/local/etc/php/php.ini
PHP OS : Linux
Drush script : /usr/local/bin/drush
Drush version : 8.1.17
Drush temp directory : /tmp
Drush configuration :
Drush alias files :
Install profile : standard
Drupal root : /var/www/html
Drupal Settings File : sites/default/settings.php
Site path : sites/default
File directory path : sites/default/files
Temporary file directory path : /tmp
Sync config path : sites/default/files/config_xeVhGsWgDSMcUJNlA97zQiNNekC93e2MhX5aEtO5UcOtKQnwq7fjEB9K6Bk15kj53APj6h8Ibg/sync
That's probably very easy to explain.
Drupal 8 now requires Drush 9.
See the chart on http://docs.drush.org/en/master/install. D8.3- means with Drush 8 your Drupal can not be greater than or equal to 8.3.
I don't know how far you already got with your project. But you may consider to restart with drupal-composer/drupal-project which already always will have the right Drush version as local dependency on board. And it will also tell you to not update Drupal with Drush anymore. Do that with Composer instead.
I have server running Ubuntu 16.04 with Docker 17.03.0-ce running an Nginx container. That server also has ConfigServer Security & Firewall installed. Shortly after starting the Nginx container I start receiving emails about "Excessive resource usage" with the following details:
Time: Fri Mar 24 00:06:02 2017 -0400
Account: systemd-timesync
Resource: Process Time
Exceeded: 1820 > 1800 (seconds)
Executable: /usr/sbin/nginx
Command Line: nginx: worker process
PID: 2302 (Parent PID:2077)
Killed: No
I fully understand that I can add exe:/usr/sbin/nginx to csf.pignore to stop these email alerts but I would like to understand a few things first.
Why is the "systemd-timesync" account being reported? That does not seem to have anything to do with Docker.
Why does the host machine seem to be reporting the excessive resource usage (the extended process time) when that is something running in the container?
Why are other docker containers not running Nginx not resulting in excessive resource usage emails?
I'm sure there are other questions but basically, why is this being reported the way it is being reported?
I can at least answer the first two questions:
Unlike real VMs, Docker containers are simply a collection of processes run under the host system kernel. They just have a different view on certain system resources, including their own file hierarchy, their own PID namespace and their own /etc/passwd file. As a result, they will still show up if you ps aux on the host machine.
The nginx container's /etc/passwd includes a user 'nginx' with UID 104 that runs the nginx worker process. However, in the host's /etc/passwd, UID 104 might belong to a completely different user, such as systemd-timesync.
As a result, if you run ps aux | grep nginx in the container, you might see
nginx 7 0.0 0.0 32152 2816 ? S 11:20 0:00 nginx: worker process
while on the host, you see
systemd-timesync 22004 0.0 0.0 32152 2816 ? S 13:20 0:00 nginx: worker process
even though both are the are the same process (also note the different PID namespaces; in containers, PIDs are counted from 1 again).
As a result, container processes will still be subject to ConfigServer's resource monitoring, but they might show up with random, or even non-existent user accounts.
As to why nginx triggers the emails and other containers don't, I can only assume that nginx is the only one of your containers that crosses ConfigServer's resource thresholds.
I have followed instructions on http://docs.drush.org/en/master/install/ to install Drush (tried both global and individual options).
When I cd to the Drupal site root and type "drush status" I get the following:
Drupal version : 7.34
Site URI : http://default
PHP executable : /usr/bin/php
PHP configuration : /etc/php.ini
PHP OS : Linux
Drush script : /root/.composer/vendor/drush/drush/drush.php
Drush version : 7.0.0
Drush temp directory : /tmp
Drush configuration :
Drush alias files :
Drupal root : /var/www/site_dev
Site path : sites/default
When I type "drush cc all" I get:
No Drupal site found, only 'drush' cache was cleared.
'all' cache was cleared.
When I type "drush sqlc" I get:
exception 'ReflectionException' with message 'Class Drush\Sql\Sql7 does not have a constructor, so you cannot pass any constructor [error]
arguments' in /root/.composer/vendor/drush/drush/includes/drush.inc:113
Stack trace:
#0 /root/.composer/vendor/drush/drush/includes/drush.inc(113): ReflectionClass->newInstanceArgs(Array)
#1 /root/.composer/vendor/drush/drush/commands/sql/sql.drush.inc(605): drush_get_class('Drush\Sql\Sql', Array, Array)
#2 /root/.composer/vendor/drush/drush/commands/sql/sql.drush.inc(588): drush_sql_get_version()
#3 /root/.composer/vendor/drush/drush/commands/sql/sql.drush.inc(454): drush_sql_get_class()
#4 [internal function]: drush_sql_cli()
#5 /root/.composer/vendor/drush/drush/includes/command.inc(368): call_user_func_array('drush_sql_cli', Array)
#6 /root/.composer/vendor/drush/drush/includes/command.inc(219): _drush_invoke_hooks(Array, Array)
#7 [internal function]: drush_command()
#8 /root/.composer/vendor/drush/drush/includes/command.inc(187): call_user_func_array('drush_command', Array)
#9 /root/.composer/vendor/drush/drush/lib/Drush/Boot/BaseBoot.php(62): drush_dispatch(Array)
#10 /root/.composer/vendor/drush/drush/drush.php(70): Drush\Boot\BaseBoot->bootstrap_and_dispatch()
#11 /root/.composer/vendor/drush/drush/drush.php(11): drush_main()
#12 {main}
It strikes me that the problem has something to do with MySQL (because the status doesn't list the DB parameters), but I can't figure it out. Under sites there is only default folder, so it's not a multisite installation.
Can anyone advise what's wrong please?
UPDATE
I have upgraded PHP to 5.5.27 and reinstalled Drush 7.0.0.
Following an advice here I deleted my.cnf from the home folder and after that "drush sqlc" started to work, however when I type "drush -v -d status" it gives me:
Starting Drush preflight. [0.01 sec, 2.08 MB] [preflight]
Cache HIT cid: 7.0.0-commandfiles-0-81cc86c1995ab7206f383ec28ad43baf [0.01 sec, 2.14 MB] [debug]
Bootstrap to phase 0. [0.07 sec, 6.08 MB] [bootstrap]
Drush bootstrap phase : bootstrap_drupal_root() [0.08 sec, 6.43 MB] [bootstrap]
Initialized Drupal 7.34 root directory at /var/www/site_dev [0.08 sec, 6.43 MB] [notice]
Find command files for phase 1 (max=7) [0.08 sec, 4.48 MB] [debug]
Cache HIT cid: 7.0.0-commandfiles-1-a0882f4af91e1d6b72794cc62bb1b558 [0.08 sec, 4.49 MB] [debug]
Drush bootstrap phase : bootstrap_drupal_site() [0.08 sec, 4.49 MB] [bootstrap]
Initialized Drupal site default at sites/default [0.08 sec, 4.5 MB] [notice]
Find command files for phase 2 (max=7) [0.09 sec, 4.5 MB] [debug]
Cache HIT cid: 7.0.0-commandfiles-2-f17fc6bdab2f74278df75194ca483893 [0.09 sec, 4.5 MB] [debug]
Drush bootstrap phase : bootstrap_drupal_configuration() [0.09 sec, 4.5 MB] [bootstrap]
Find command files for phase 3 (max=7) [0.09 sec, 4.51 MB] [debug]
sql-query: SELECT 1; [0.09 sec, 4.62 MB] [status]
Executing: mysql --defaults-extra-file=/tmp/drush_CKiVHd --database=site_dev --host=localhost --silent < /tmp/drush_DG1fIs
1
Drush bootstrap phase : bootstrap_drupal_database() [0.1 sec, 4.62 MB] [bootstrap]
Successfully connected to the Drupal database. [0.11 sec, 5.13 MB] [bootstrap]
Find command files for phase 4 (max=7) [0.11 sec, 5.13 MB] [debug]
Drush bootstrap phase : bootstrap_drupal_full() [0.11 sec, 5.13 MB] [bootstrap]
Cannot modify header information - headers already sent by (output started at /root/.composer/vendor/drush/drush/includes/output.inc:38)[warning]
common.inc:698 [0.96 sec, 31.9 МБ]
Drush command terminated abnormally due to an unrecoverable error.
Sounds like it could be this issue: 7.x does not work with PHP 5.3.3.
There is a solution provided in this comment:
The base class SqlVersion class does not have a constructor and yet an
empty array is passed into its descendant (Sql6 or Sql7).
To workaround this, the line:
return $reflectionClass->newInstanceArgs($constructor_args);
should be replaced with:
return !empty($constructor_args) ?
$reflectionClass->newInstanceArgs($constructor_args) :
$reflectionClass->newInstanceArgs();
Alternatively you can upgrade PHP v5.4 or higher.
Or, you can downgrade Drush to 6.x.
If you're running this site in your local (dev) environment (hard to tell from the question ...)
then try changing the database host in Drupal's settings.php file from "localhost" to "127.0.0.1".
If you're working on Windows, you need to verify that your PATH Variable for MYSQL is properly set. I had the problem when I had upgraded my WAMP.
Example like this : C:\wamp\bin\mysql\mysql5.6.17\bin