versionpress
Fatal error on activation
I got this error when try to activate WPML Multilingual CMS plugin. The same will be if try activate VersionPress after WPML Multilingual CMS.
As i understand, it's the same problem like in this issue: https://github.com/versionpress/support/issues/127
How can I resolve it?
Fatal error: ReflectionProperty::setValue(): Cannot write property in [...]/wp-content/plugins/versionpress/src/Utils/AbsoluteUrlReplacer.php on line 105
- VersionPress version: 4.0-beta
- WordPress version: 4.9.7
- OS, webserver, PHP: MacOS - 10.13.6 Apache 2.4.33 PHP 5.6
- Git version: 2.15.2
Hi @jr-jaguar,
I was not able to reproduce your issue. I tried to activate latest WPML 4.0.5 on my site with VersionPress active and I did not encouter this problem. Maybe it is related to another plugin (or combination of plugins)? But you are right, @JorgeDDW from #127 is also using WPML. Maybe it is related to specific WPML settings? Did you tried to activate WPML on clean testing site (with VP active)? I am not sure, is there any chance you can share database of your testing site?
We probably identified cause of this problem here: https://github.com/versionpress/versionpress/issues/1312
Did you try to use VP definitions for WPML plugin? Maybe @mkreckovic encountered similar issue?
Hello @pavelevap, @jr-jaguar,
I was able to reproduce the problem. The problem occurs when the Posts > Categories or Posts > Tags pages are open.
Problem is in replaceRecursively function, when we try to change property value, but we can't, even if we previously set setAccessible to true. It's because of some protected properties that can't be changed even if setAccessible is true, for example affected_rows, client_info, client_version...
We can exclude mysqli instance in replaceRecursively function:
$r = new \ReflectionObject($value);
$p = $r->getProperties();
if (get_class($value) != 'mysqli'){
foreach ($p as $prop) {
$prop->setAccessible(true);
$prop->setValue($value, $this->replaceRecursively($prop->getValue($value), $replaceFn));
}
}
@pavelevap Hi. I installed clear WP, WPML and added VP. If don't do soma settings in WPLM and activate VP all is fine. But when I turn off VP and did standard settings, added one language, added one post and category, added translation for them and try to activate VP I got error. I try fix that send @mkreckovic and it helped me on test clean WP and on existing site.
Hello @mkreckovic ! It works and helped me. Thank you very much!
Finally, I was able to reproduce this issue. Example for WPML is option wpml_notices which is stored in database:
a:1:{s:26:"taxonomy-term-help-notices";a:1:{s:8:"category";O:11:"WPML_Notice":22:{s:30:"WPML_Noticedisplay_callbacks";a:1:{i:0;a:2:{i:0;O:37:"WPML_Taxonomy_Translation_Help_Notice":2:{s:57:"WPML_Taxonomy_Translation_Help_Noticewpml_admin_notices";O:12:"WPML_Notices":5:{s:27:"WPML_Noticesnotice_render";O:18:"WPML_Notice_Render":3:{s:38:"WPML_Notice_Renderdismiss_html_added";N;s:35:"WPML_Notice_Renderhide_html_added";N;s:39:"WPML_Notice_Rendercollapse_html_added";N;}s:21:"WPML_Noticesnotices";a:1:{s:26:"taxonomy-term-help-notices";a:1:{s:8:"category";r:3;}}s:31:"WPML_Noticesnotices_to_remove";a:0:{}s:23:"WPML_Noticesdismissed";a:0:{}s:28:"WPML_Noticesuser_dismissed";N;}s:45:"WPML_Taxonomy_Translation_Help_Noticenotice";r:3;}i:1;s:26:"should_display_help_notice";}}s:15:"WPML_Noticeid";s:8:"category";s:17:"WPML_Noticetext";s:228:"Translating Categories? Use the Category translation table for easier translation.";s:27:"WPML_Noticecollapsed_text";N;s:18:"WPML_Noticegroup";s:26:"taxonomy-term-help-notices";s:35:"WPML_Noticerestricted_to_user_ids";a:0:{}s:20:"WPML_Noticeactions";a:1:{i:0;O:18:"WPML_Notice_Action":9:{s:27:"WPML_Notice_Actiondismiss";b:0;s:37:"WPML_Notice_Actiondisplay_as_button";b:0;s:24:"WPML_Notice_Actionhide";b:0;s:24:"WPML_Notice_Actiontext";s:7:"Dismiss";s:23:"WPML_Notice_Actionurl";s:1:"#";s:36:"WPML_Notice_Actiongroup_to_dismiss";s:26:"taxonomy-term-help-notices";s:31:"WPML_Notice_Actionjs_callback";s:40:"wpml_dismiss_taxonomy_translation_notice";s:42:"WPML_Notice_Actiondismiss_different_text";b:1;s:31:"WPML_Notice_Actionlink_target";N;}}s:28:"WPML_Noticecss_class_types";a:1:{i:0;s:4:"info";}s:24:"WPML_Noticecss_classes";a:0:{}s:24:"WPML_Noticedismissible";b:0;s:31:"WPML_Noticeexclude_from_pages";a:0:{}s:21:"WPML_Noticehideable";b:0;s:24:"WPML_Noticecollapsable";b:0;s:30:"WPML_Noticerestrict_to_pages";a:0:{}s:38:"WPML_Noticerestrict_to_page_prefixes";a:0:{}s:35:"WPML_Noticerestrict_to_screen_ids";a:0:{}s:34:"WPML_Noticehide_if_notice_exists";N;s:43:"WPML_Noticedismissible_for_different_text";b:1;s:31:"WPML_Noticedefault_group_name";s:7:"default";s:25:"WPML_Noticecapabilities";a:0:{}s:26:"WPML_Noticedismiss_reset";b:0;s:25:"WPML_Noticenonce_action";N;}}}
And our problem is probably related to recursive objects, see hidden r:3. During runtime (and unserialization) are objects autoloaded (for example SitePress, wpdb, mysqli, etc), but they are not needed for VersionPress and not stored into database. We should probably ignore replacing URLs for recursive objects as a whole and not only some exceptions. It will also have some positive performance effect, I guess (not trying to replace URLs in temporary autoloaded objects).