Upgraded Drush 8 to 9 Site Alias Not Working - drupal

I moved from using Docksal to Acquia ADS (Lando) which automatically upgraded my Drush from 8 to 9. My local site works fine but I can't get Drush 9 to "see" my Drupal 8 site. The aliases seem to have been created and added to the drush/sites folder and running drush site:alias does show them. However running drush status shows my Drupal root as /app. My Drupal root is /app/docroot. My alias files do have this as their root (for local). I'm not sure why Drush doesn't use the alias files it knows about. I've tried:
drush #self(or #local) list and I get some commands and this statement at the end:
[NOTE] Drupal root not found. Pass --root or a #siteAlias in order to see Drupal-specific commands.
Doing drush #local(or #self) cr returns:
In BootstrapHook.php line 32: Bootstrap failed. Run your command
with -vvv for more information.
With -vvv:
Exception trace: at
/app/vendor/drush/drush/src/Boot/BootstrapHook.php:32
Drush\Boot\BootstrapHook->initialize() at
/app/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/InitializeHookDispatcher.php:34
Consolidation\AnnotatedCommand\Hooks\Dispatchers\InitializeHookDispatcher->callInitializeHook()
at
/app/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/InitializeHookDispatcher.php:27
Consolidation\AnnotatedCommand\Hooks\Dispatchers\InitializeHookDispatcher->initialize()
at
/app/vendor/consolidation/annotated-command/src/CommandProcessor.php:145
Consolidation\AnnotatedCommand\CommandProcessor->initializeHook() at
/app/vendor/consolidation/annotated-command/src/AnnotatedCommand.php:289
Consolidation\AnnotatedCommand\AnnotatedCommand->initialize() at
/app/vendor/symfony/console/Command/Command.php:221
Symfony\Component\Console\Command\Command->run() at
/app/vendor/symfony/console/Application.php:1005
Symfony\Component\Console\Application->doRunCommand() at
/app/vendor/symfony/console/Application.php:255
Symfony\Component\Console\Application->doRun() at
/app/vendor/symfony/console/Application.php:148
Symfony\Component\Console\Application->run() at
/app/vendor/drush/drush/src/Runtime/Runtime.php:118
Drush\Runtime\Runtime->doRun() at
/app/vendor/drush/drush/src/Runtime/Runtime.php:49
Drush\Runtime\Runtime->run() at /app/vendor/drush/drush/drush.php:72
require() at /app/vendor/drush/drush/drush:4
drush status:
PHP binary : /usr/local/bin/php
PHP config :
PHP OS : Linux
Drush script : /app/vendor/drush/drush/drush
Drush version : 10.2.2 <-- Had 9.0.0 but currently trying 10, same issue
Drush temp : /tmp
Drush configs : /root/.drush/drush.yml
/app/vendor/drush/drush/drush.yml
/app/drush/drush.yml
Drupal root : /app
self.site.yml:
local:
root: /app/docroot
uri: example.lndo.site
Can someone please point me in the right direction?

Figured it out. No matter how many ways you try to tell Drush where to look to find your Drupal root, none of it will matter until you edit your composer.json file. Turns out the key to making Drush 9+ work is changing the name in composer.
My composer.json file name went from:
"name": "drupal/drupal",
to:
"name": "drupal-composer/drupal-project",
I don't think this feature was documented anywhere so I'm posting it here in response to my own question in case this helps anyone else.

I realize that this is an older question, however with Drupal 8 recently reaching end of life, and the high probability of many people (like myself) scrambling to upgrade now that clients have realized the risks of using EOL software, I want to take a moment to explain why #r00t's answer works.
r00t is correct that changing the "name" value in composer.json fixed the issue, however, the value that is set is not limited to drupal-composer/drupal-project. This seems to stem from the package webflo/drupal-finder and the way it works.
webflow/drupal-finder is a requirement of drush/drush, so it's going to be included even if you haven't added it manually. It's also a requirement of a couple of others that you may or may not have installed, like palantirnet/drupal-rector (which as a side note, is really helpful for this upgrade).
Within the code for drupal-finder is a method that looks for the install path of Drupal core based on a few items within your composer.json file.
Here is the code from DrupalFinder::isValidRoot()
foreach ($json['extra']['installer-paths'] as $install_path => $items) {
if (in_array('type:drupal-core', $items) ||
in_array('drupal/core', $items) ||
in_array('drupal/drupal', $items)) {
$this->composerRoot = $path;
// #todo: Remove this magic and detect the major version instead.
if (($install_path == 'core') || ((isset($json['name'])) && ($json['name'] == 'drupal/drupal'))) {
$install_path = '';
} elseif (substr($install_path, -5) == '/core') {
$install_path = substr($install_path, 0, -5);
}
....
Which is telling drupal-finder that if the "name" value is drupal/drupal then the install path of the site is at the base of the project, however if it is not drupal/drupal then use a value from extra.installer-paths to find the site install.
I'm still not aware if this is documented anywhere on either webflo/drupal-finder or in drush/drush, but understanding why it was an issue helped me out tremendously.
TL;DR:
If your site's docroot lives next to your vendor folder, change the name in composer.json to anything that isn't drupal/drupal. If your vendor folder lives inside your docroot, drupal/drupal will work for you.

Related

Drupal ComputedItemListTrait::getValue() must be compatible FieldItemList::getValue($include_computed = false)

Hey so my hosting provider dropped support for anything below php 7 so need to update my drupal site from 8.4 to 8.6 so i wont break etc.
when trying to update running the 'composer outdated "drupal/*"' command nothing is returned at all even when I added '"drupal/core": "^8.6.1"' to the 'require' section of the 'composer.json'
and the site is mostly fine but i cant add any content and get the following error :
Fatal error: Declaration of Drupal\Core\TypedData\ComputedItemListTrait::getValue() must be compatible with Drupal\Core\Field\FieldItemList::getValue($include_computed = false) in \core\modules\path\src\Plugin\Field\FieldType\PathFieldItemList.php on line 13
and here is some of my composer.json which mentions drupal
"require": {
"composer/installers": "^1.0.24",
"wikimedia/composer-merge-plugin": "^1.4",
"drupal/core": "^8.6.1"
},
"replace": {
"drupal/core": "^8.4"
},
so i'm summary im not even sure my drupal has been updated but the site works fine apart from where I add content I get a php error saying a module is not compatible for the core.
That error looks like a PHP 7 compatibility issue, so I would assume that your Drupal version has not been updated.
You can check your current version of Drupal on the status report page when logged-in - Reports > Status report (from the administrative toolbar) or https://yoursite.com/admin/reports/status
Running composer require directly (rather than editing composer.json) is the best way to ensure an appropriate version of Drupal core is correctly installed, as follows:
$ composer require drupal/core^8.6.1
This will ensure the composer.lock file is also updated when installing an appropriate version of Drupal core.

Sudden syntax error after deployment

I have a working symfony project. I have it on a private bitbucked repository and locally the website works without an issue.
Today I tried to deploy the project onto an external server linuxpl.com.
Steps taken include:
Istalling composer
Adding the mysql database
Running git clone to get the data into a proper location
Running composer install on the folder to install everything and connect to the db
Cleared the cache
Set the project root as ....domain/project_name/web
However after completing all these steps, when running the website with regular server:run I'm getting this odd error:
Parse error: syntax error, unexpected '.' in /home/spirifer/domains/surowcewobiektywie.pl/konkurs/vendor/twig/twig/lib/Twig/Extension/Core.php on line 1571
Not sure if this is of any importance but the mentioned code partion looks like this in my local files:
// Some objects throw exceptions when they have __call, and the method we try
// to call is not supported. If ignoreStrictCheck is true, we should return null.
try {
$ret = $object->$method(...$arguments);
} catch (BadMethodCallException $e) {
if ($call && ($ignoreStrictCheck || !$env->isStrictVariables())) {
return;
}
throw $e;
}
The local version does not differ from the one on the server.
My local machine has PHP 7.0.9 and the remove server has PHP 7.0.14
How could I fix this issue?
PHP 5.6 adds Variadic functions, with "...". However, Twig v1.x only required the use of PHP 5.2.7 or above.
If you didn't explicitly update to Twig 2.0, it's very possible you have used the 'death star' version constraint in the composer file - '*'. which allows uncontrolled version updates to the latest version. If this is the case, you will need to either update your version of PHP, or at least require just a previous version of Twig/twig, "^1.32" would be the latest in the version 1 series of Twig.

"Modules are Outdated" Error

I get this error when I create a new module:
"Please upgrade your database: Run "bin/magento setup:upgrade" from the Magento root directory.
The following modules are outdated:
Sangeeta_Octan data: current version - none, required version - 0.0.1";i:1;s:1781:"#0
I searched on google and found no solution other than reinstalling Magento. Such as:
version has been changed from "2.0.0.0" to "2.0.0" during development,
so update tool can't recognize that "2.0.0.0" <= "2.0.0". Please,
re-install your application from scratch to get latest version. `
Do I have any options apart from reinstalling?
Change the setup_version of your module (Sangeeta_Octan) in
app/code/Sangeeta/Octan/etc/module.xml. Try a different version
name like setup_version="2.0.1" or setup_version="3.0.0"
Run bin/magento setup:upgrade
If that doesn't work, disable your module by changing your module name in app/etc/config.phpfrom Sangeeta_Octan => 1 to Sangeeta_Octan => 0. Then run bin/magento setup:upgrade
I hope below solution also solve your problem.
https://magento.stackexchange.com/questions/112293/mysql-error-and-possible-duplicates-running-bin-magento-setupupgrade-after-rena/112299#112299
in mysql find the table setup_module It will have 3 fields. Find the NULL values in data_version & have them match the schema_version
As an alternative, you can access your magento database and look at the table setup_module
You will see a list of all installed modules and you can manually set the schema/data version numbers here.
Delete the offending rows from the setup_module table (if they are there) and run the command bin/magento setup:upgrade from your Magento 2 root directory.
This is happens because of something wrong while running "bin/magento setup:upgrade" and the data_version in Module versions registry is null. It is loaded from DB, We can just proceed by manually changing it in db.
Go db via php myadmin and check "setup_module" table, the
data_version which are mentioned "null".
Login to Mysql database => then update table setup_module of the "data_version" column same as "schema_version"

How to install mmoreramerino/GearmanBundle with Symfony 2.1.x?

I am pretty new to Symfony 2 and brand new to Gearman.
I am looking for a bundle to integrate Symfony 2 with Gearman.
mmoreramerino's bundle seems to be the most popular bundle according to packagist. Unfortunately something seems to be broken, the autoloader does not find the bundle.
Fatal error: Class 'Mmoreramerino\GearmanBundle\MmoreramerinoGearmanBundle' not found in ...
I tried switching to "dev-development" as I got from the issues that it was fixed in this branch, but it did not work for me as well.
Question: How can I install this bundle using Symfony 2.1.x?
Question 2: Are there any working & documented alternatives?
Edit In case someone else comes across this question: Here is how I got it up and running!
Install gearman, libgearman, the PECL extension for PHP (use recent versions!)
check that gearman shows up in phpinfo() (both cli and webserver version)
start gearmand in terminal 1 using "gearmand --verbose INFO" (you will see workers & clients connect to gearman - or not ;-))
start in terminal 2 reverse_worker.php from the gearman php extension example directory
start in terminal 3 reverse_client.php from the gearman php extension example directory
If this is working, you are ready for Symfony: install mmoreramerino/GearmanBundle using "dev-development"
copy dev.base.yml from the bundle to app/config/gearman/dev.yml
Now add TestWorker.php to your bundle as outlined in the documentation
enable the testWorker by using the console script "php app/console gearman:job:execute MmoreramerinoGearmanBundleWorkerstestWorker~test"
now you are able to send jobs to the listening testWorker in a Symfony controller (or somewhere else in Symfony). I had to specify the server though I am using the default host/port.
$gearman = $this->get('gearman');
$gearman->setServer('127.0.0.1',4730);
$gearman->doNormalJob('MmoreramerinoGearmanBundleWorkerstestWorker~test');
To install the bundle, you need to add the following line to composer.json
"Mmoreramerino/GearmanBundle": "dev-development"
and run composer update;
Then register it in app/AppKernel.php (it seems you have already done this)
new Mmoreramerino\GearmanBundle\MmoreramerinoGearmanBundle(),

Why does Symfony2 set the error_reporting?

I've been trying to remove the E_NOTICE and E_STRICT error levels to avoid this error:
Runtime Notice: Only variables should be passed by reference
I tried modifying php.ini but didn't work, error_reporting always is -1. Then I tried setting it dynamically in the current action, and worked fine. Then I also tried the same in the first line in app_dev.php and didn't work. Which means Symfony2 is setting it dynamically somewhere.
What should I do?
EDIT
For those who are not familiar with the error:
$user = $this->('security.context')->getToken()->getUser();
$first = reset($user->getRoles()); // error
$roles = $user->getRoles();
$first = reset($roles); // works fine
Whilst the notice is not 'retarded', this is a reasonable question in other contexts so: this is set in the Kernel instance, instantiated in app_dev.php (or app.php).
The second parameter to the construct is a boolean debug flag, and if true then error_reporting is set to -1 and display_errors to 1, otherwise default and 0 respectively.
$kernel = new AppKernel('dev', false);
symfony documentation
Hope this helps.
I got the same error in the following scenario i.e.
Scenario:
I lost the development environment for my existing LIVE project. But I got the whole code from GIT repo and then installed the symfony 2.4.2 (same version as on LIVE site) in my new development environment. Then I found that the web-application pages working on the LIVE site are broken in my new DEV environment.
Solution:
I spent quit a lot time to understand why the problem is then I found that i.e.
When I installed symfony 2.4.2 in my development environment using composer.phar then it created a new web/app_dev.php file in my development environment and it has the following entry to turn it off i.e.
Debug::enable();
Just comment the above line then the php notices will be off and then all the pages that were giving me notices are fixed.
I hope this will be helpful for someone having the same problem like me. Good Luck!
Cheers.
PS: But I will recommend to enable the above line in your new development projects so that you can see the PHP notices and then remove them during development.

Resources