Hello i have problem with the module....

if i will upgrade a module come this:

Fatal error: Unsupported operand types in c:\xampp\htdocs\drupal\modules\drupalmoduleupgrader\src\Plugin\DMU\Rewriter\GenericDeriver.php on line 50

Error: Unsupported operand types in c:\xampp\htdocs\drupal\modules\drupalmoduleupgrader\src\Plugin\DMU\Rewriter\GenericDeriver.php on line 50

Anyone knows what goes wrong ?? This come only on Upgrade.

Everytime comes this:

Illegal string offset 'hook' FlagHookDeriver.php:39 [warning]
Illegal string offset 'hook' FlagHookDeriver.php:42 [warning]
Invalid argument supplied for foreach() FlagHookDeriver.php:42 [warning]
Illegal string offset 'functions' FunctinsCallDeriver.php:41 [warning]
Illegal string offset 'functions' FunctinsCallDeriver.php:44 [warning]
Invalid argument supplied for foreach() FunctinsCallDeriver.php:44 [warning]
Invalid argument supplied for foreach() EnityOperationDeriver:43 [warning]

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Lennard’s picture

Issue summary: View changes
Lennard’s picture

Wow two weeks no answer or help ...

Really bad support for the Module

Lennard’s picture

Priority: Normal » Critical
C-Logemann’s picture

Category: Support request » Bug report
Priority: Critical » Normal
Status: Needs work » Active

I have the same problem and think it is a bug. I get the same errors.

Maybe this problem just affecting some configurations. By myself it's with MAMP and maybe similar like the XAMP situation. My configuration currently set to PHP 5.6.10 with Drupal 8.0.0-beta16 and actual drush 8 dev version.

Even if we both can't use the module currently it's not a critical situation yet.

C-Logemann’s picture

I made some tests and it seems that there something wrong data_type "taxonomy_term". When I make a hard coded if-exeption for this data_type the fatal error on GenericDeriver.php, line 50 disappears and the upgrade script is doing more than before.
In my setup and test data to upgrade with excluding data_type "taxonomy_term" I get this error messages:

Indexing...done.
Invalid argument supplied for foreach() EntityOperationDeriver.php:42                                                                                 [warning]
Object support when dumping a YAML file has been disabled.                                                                                            [error]
PHP Fatal error:  Call to a member function hasMethod() on null in /data/_DEV/_drupal_patch_work/drupalmoduleupgrader/src/Plugin/DMU/Routing/ContentRoute.php on line 225
Drush command terminated abnormally due to an unrecoverable error.                                                                                    [error]
Error: Call to a member function hasMethod() on null in /data/_DEV/_drupal_patch_work/drupalmoduleupgrader/src/Plugin/DMU/Routing/ContentRoute.php,
line 225
C-Logemann’s picture

Title: Error on Upgrade funktion » fatal error on drush dmu-upgrade
C-Logemann’s picture

Version: 8.x-1.1 » 8.x-1.x-dev
webchick’s picture

Thanks for the additional details. It would help a lot if you could point us at a module in contrib we could reproduce this error with, and/or pastebin the module you're trying to convert.

C-Logemann’s picture

In my case it's my new module chmod I tried to convert.

webchick’s picture

$ drush dmu-upgrade chmod
Indexing...done.
Object support when dumping a YAML file has been disabled.            [error]
Fatal error: Call to a member function hasMethod() on a non-object in /Users/webchick/Sites/8.x/modules/drupalmoduleupgrader/src/Plugin/DMU/Routing/ContentRoute.php on line 225
Drush command terminated abnormally due to an unrecoverable error.    [error]
Error: Call to a member function hasMethod() on a non-object in
/Users/webchick/Sites/8.x/modules/drupalmoduleupgrader/src/Plugin/DMU/Routing/ContentRoute.php,
line 225

Cool, I can reproduce. Have a feeling it's a "cascading" error from the "Object support when dumping a YAML file has been disabled. " error (which is coming from Symfony's YAML parser).

I noticed in http://cgit.drupalcode.org/drupalmoduleupgrader/commit/?id=f686394 we fixed a similar error about YAML files by casting the output of $this->t() to a string, so possible something similar here in the routing converters would fix it. Really hope we don't need to do that on every single $this->t() call, tho. :\

C-Logemann’s picture

Thanx @webchick for working on this error and for the complete module.

webchick’s picture

Well, fair warning that this is about as far as I personally can take this, but happy to review/commit any patches.

pfrenssen’s picture

I have been pondering that it would be nice to add the option to cast objects to strings automatically in the Symfony YAML component. This should be pretty easy, we can check if the object has a __toString() method, and call it if it exists.

webchick’s picture

Hm. Not a bad idea at all!

pfrenssen’s picture

Had a look, the "Object support when dumping a YAML file" error is due to #2576533: Rename SafeStringInterface to MarkupInterface and move related classes being merged in. This is unfortunate but will be easy to fix.

@C_Logemann, thanks so much for informing us which module causes the problem, this is a lot easier to figure out if we can replicate the issue!

  • pfrenssen committed e0b6fec on 8.x-1.x
    Issue #2513034 by pfrenssen: Rename SafeStringInterface to...
pfrenssen’s picture

Status: Active » Needs review

@C_Logemann, @Lennard, I have committed a fix that should get rid of the first warning. I have now been able to convert the chmod module without any errors. Could you please try again with the latest development version of Drupal Module Upgrader and check if it now works for you?

$ drush dmu-upgrade chmod
Indexing...done.

$ git status 
On branch 7.x-1.x
Your branch is up-to-date with 'origin/7.x-1.x'.
Changes not staged for commit:
	modified:   chmod.drush.inc
	modified:   chmod.module
	modified:   chmod.pages.inc

Untracked files:
	chmod.info.yml
	chmod.links.menu.yml
	chmod.links.task.yml
	chmod.permissions.yml
	chmod.routing.yml
	config/
	src/
C-Logemann’s picture

@pfrenssen Thanx for working on this problem. Sorry that I didn't pointed to my module at first. I know that's isn't easy all the time to reproduce an error. Maybe here is another problem that is hard to reproduce:

drush dmu-upgrade chmod
Indexing...done.
Invalid argument supplied for foreach() EntityOperationDeriver.php:42 [warning]
PHP Fatal error: Unsupported operand types in /data/_DEV/_drupal_patch_work/drupalmoduleupgrader/src/Plugin/DMU/Rewriter/GenericDeriver.php on line 50
Drush command terminated abnormally due to an unrecoverable error. [error]
Error: Unsupported operand types in /data/_DEV/_drupal_patch_work/drupalmoduleupgrader/src/Plugin/DMU/Rewriter/GenericDeriver.php,
line 50

This is with latest dev code of "Drupal Module Upgrader" but still on my local system as described above.

I can get the upgrade working when make an "is_array() condition on the foreach-error and do now an if condition for '$data_type != "langcode"'. The attached file is just for showing this and not a patch. I will try to test dmu-upgrade on another setup.

pfrenssen’s picture

I cannot replicate this using the latest Drupal core 8.0.x and latest 8.x-1.x of Drupal Module Upgrader. I tried both the minimal and standard installation profiles.

Did you run composer install after updating Drupal Module Upgrader? Can you try on a clean installation with the minimal profile?

C-Logemann’s picture

Test with "composer install" inside this module and fresh "standard installation" of D8 hits the same errors. I try to test other install profile and other test servers as soon as possible.

webchick’s picture

Status: Needs review » Fixed

Hm. Not able to reproduce.

$ cd ~/Sites/8.x
$ git pull --rebase
Current branch 8.0.x is up to date.

$ drush si --account-pass=admin -y
You are about to DROP all tables in your '8x' database. Do you want to continue? (y/n): y
Starting Drupal installation. This takes a while. Consider using the      [ok]
--notify global option.
Installation complete.  User name: admin  User password: admin            [ok]
All necessary changes to sites/default and sites/default/settings.php have[warning]
been made, so you should remove write permissions to them now in order to
avoid security risks. If you are unsure how to do so, consult the online
handbook.
Congratulations, you installed Drupal!                                    [status]

$ cd modules
$ git clone --branch 8.x-1.x webchick@git.drupal.org:project/drupalmoduleupgrader.git
Cloning into 'drupalmoduleupgrader'...
remote: Counting objects: 12406, done.
remote: Compressing objects: 100% (4826/4826), done.
remote: Total 12406 (delta 8049), reused 10150 (delta 6452)
Receiving objects: 100% (12406/12406), 1.60 MiB | 674.00 KiB/s, done.
Resolving deltas: 100% (8049/8049), done.
Checking connectivity... done.

$ cd drupalmoduleupgrader
$ composer install
# BLAH stuff

$ drush en drupalmoduleupgrader -y
drupalmoduleupgrader was enabled successfully.                            [ok]

$ cd ../../
drush dmu-upgrade chmod
Indexing...done.

No errors here. Moving to fixed.

C-Logemann’s picture

I did a new test with a D8 beta 16 minimal installation and now I also get "Indexing...done." without any errors. Maybe my last test was not as "fresh" as I thought. There are so many new things including new problems I have to learn with D8. But that's my private issue :-)

Many thanx to @pfrenssen and @webchick for testing and fixing this. Now I can move on with my work on my first Drupal 8 module.

pfrenssen’s picture

@C_Logemann, you're welcome, have fun hacking on Drupal 8!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.