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]
Comment | File | Size | Author |
---|---|---|---|
#18 | 2513034-18-not_really_a_patch_just_a_test.diff | 2.3 KB | C-Logemann |
Comments
Comment #1
Lennard CreditAttribution: Lennard commentedComment #2
Lennard CreditAttribution: Lennard commentedWow two weeks no answer or help ...
Really bad support for the Module
Comment #3
Lennard CreditAttribution: Lennard commentedComment #4
C-LogemannI 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.
Comment #5
C-LogemannI 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:
Comment #6
C-LogemannComment #7
C-LogemannComment #8
webchickThanks 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.
Comment #9
C-LogemannIn my case it's my new module chmod I tried to convert.
Comment #10
webchickCool, 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. :\
Comment #11
C-LogemannThanx @webchick for working on this error and for the complete module.
Comment #12
webchickWell, fair warning that this is about as far as I personally can take this, but happy to review/commit any patches.
Comment #13
pfrenssenI 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.Comment #14
webchickHm. Not a bad idea at all!
Comment #15
pfrenssenHad 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!
Comment #17
pfrenssen@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?
Comment #18
C-Logemann@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:
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.
Comment #19
pfrenssenI 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?Comment #20
C-LogemannTest 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.
Comment #21
webchickHm. Not able to reproduce.
No errors here. Moving to fixed.
Comment #22
C-LogemannI 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.
Comment #23
pfrenssen@C_Logemann, you're welcome, have fun hacking on Drupal 8!