search

modxcms / revolution

MODX Revolution - Content Management Framework
https://modx.com/
GNU General Public License v2.0
1.36k stars 528 forks source link

MODX3 PHP Fatal error: Cannot declare class modTemplateVarInputRenderText #16402

Closed jolichter closed 1 year ago

jolichter commented 1 year ago

Bug report

Summary

PHP Fatal error: Cannot declare class modTemplateVarInputRenderText, because the name is already in use

I think this issue refer to to the old issue 16329, but my SQL database looks OK, 'modTemplateVar' has been replaced by 'MODX\Revolution\modTemplateVar'.

This upgrade was to another similar MODX 2.8.4-pl via UpgradeMODX to 3.0.0-pl and then to 3.0.3-pl (core/cache cleaned). When I try to edit a resource which use Text TVs, I get a blank screen. The browser console reveals:

GET https://myDomain.tld/manager/?a=resource/update&id=281 Status: 500 Internal Server Error Version: HTTP/2 Transferred: 371 B (0 B size) Referrer Policy: strict-origin-when-cross-origin Request Priority: Highest

PHP Error Log:

[proxy_fcgi:error] [pid 3292968] [client xx.xxx.xxx.xx:x] AH01071: Got error 'PHP message: PHP Fatal error: Cannot declare class modTemplateVarInputRenderText, because the name is already in use in /var/www/vhosts/myServer.tld//httpdocs/modx/core/src/Revolution/Processors/Element/TemplateVar/Renders/mgr/input/text.class.php on line 0', referer: https://myDomain.tld/manager/?a=element/tv/update&id=383

Step to reproduce

Observed behavior

I am currently using 3 contexts (web, web3 and web4) and this error only occurs with the web4 context.

Expected behavior

As workaround I modified the text.class.php (as mentioned here) and the website works as expected: no PHP Error or MODX Log Error.

Environment

Mark-H commented 1 year ago

I believe this error happens when there is a TV configured that cannot be found; that loads the text tv as a fallback but that may already be loaded and cause the error. The text tv itself is fine.

So what other TVs types are you using that may not be available after upgrading?

The root cause is the logic loading the TVs, not sure if that's something we can fix easily.

jolichter commented 1 year ago

Oops, that was the right tip: "So what other TVs types are you using that may not be available after upgrading?"

I found an old custom TV-input-type with jQuery as Datepicker. If I deactivate this or switch to Input Type Text everything works. I'll modify or remove it for MODX 3.

Anyway, thanks a lot Mark!

btw: It would be nice if in the future there would be a suitable message in the MODX Error Log?

Mark-H commented 1 year ago

I'm not actually able of reproducing this on purpose, which would be helpful in coming up with a fix. What was the type that was broken for you?

jolichter commented 1 year ago

Sorry, I'll try to explain it better. This probably won't happen often (maybe when MODX 4 comes out ;-). But I hope you can reproduce this:

In MODX 2 I had created a custom TV-input-type with jQuery Datepicker (Link) and stored it in: core/model/modx/processors/element/tv/renders/mgr/input/datepicker-multiple.class.php

Since this path no longer exists, I suspect it was removed during the update to MODX 3? Maybe the new path is (not tested): core/src/Revolution/Processors/Element/TemplateVar/Renders/mgr/input/

In my calendar resource this custom TV was included and since it was no longer available, as you mentioned it tried to load the Text TV as a fallback. But it works only with the previously mentioned fix in text.class.php.

My problem was that the PHP error message confused me (PHP Fatal error: Cannot declare class modTemplateVarInputRenderText), because I assumed that a Text TV was the cause.

Now that I know this happened because of the fallback, I found my mistake.

Therefore my question: In this case a MODX Error Log would be fine? e.g.: TV xxxxxx does not exist, fallback to Text TV.

smg6511 commented 1 year ago

I've run into this issue when developing one of my other PRs. If I remember correctly, it doesn't really matter what type the TV was, all that has to happen is for you to have at least one regular Text type TV in your template and one TV type that is missing for some reason.

Mark-H commented 1 year ago

Yeah, I've seen this issue before, but when I create a TV on the latest 3.x, then change the type to a fake one in the database, it doesn't actually break. And yeah I do have a different text TV enabled on the same resource as well.

Maybe it actually needs an invalid TV class?

Therefore my question: In this case a MODX Error Log would be fine? e.g.: TV xxxxxx does not exist, fallback to Text TV.

Yes, that's why I'm trying to purposely break it on my development install, to see if I can get it to just log an error. :P

halftrainedharry commented 1 year ago

The order is important. The TV with the wrong type has to be processed first, before the correct Text TV, to generate the error. Otherwise the class_exists of the fallback prevents that the file is included twice.

https://github.com/modxcms/revolution/blob/e7607a239218ba855dbd60805948e34119f913c5/core/src/Revolution/modTemplateVar.php#L487-L489

JoshuaLuckers commented 1 year ago

I can confirm this issue. Steps to reproduce:

Fatal error: Cannot declare class modTemplateVarInputRenderText, because the name is already in use in /Users/joshua/Projects/modx-3x/core/src/Revolution/Processors/Element/TemplateVar/Renders/mgr/input/text.class.php on line 0