Easing the move to a new server and re-running setup

Okay solved, It was an issue of ownership/chmod. Once that was done everything s back on line. Thanks.

I've got the exact same problem on a sloppy, crappy and insanely stupidly configured server right now. They've configured it so that it won't run without a "script" folder outside the public_html plus the server recognizes 777 only as 771, which is a totally new one to me. Seems like some wonky server admin had a bit of time on his hands and decided to fiddle around with the server's settings...

So in short, I've got the exact same error... Currently CHMODding the cache to 777. I've already tried to re-upload a fresh 2.2.1 core installation but that didn't do the trick. Mind that this only happens on the "home" (1) resource and not any others linked to it.

Ah and also it specificly happens when I re-enable the TV that has a "Text" option output... [ed. note: ReSpawN last edited this post 14 years, 5 months ago.]

I take it back... It was a sloppy, crappy and insanely stupid custom TV... Sorry MODX :$

Though! This server is still badly configured. They should be punished with a rake. [ed. note: ReSpawN last edited this post 14 years, 5 months ago.]

Quote from: devolute at Jan 12, 2012, 09:07 AM

Fatal error: Cannot redeclare class modTemplateVarInputRenderText in /var/www/vhosts/castroledge.com/httpdocs/core/model/modx/processors/element/tv/renders/mgr/input/text.class.php on line 10

I came here after finding this error too. Tried everything in this thread (bar the core modifications), but the actual problem for me was that I had removed a package that still had a TV looking for its components. I deleted the TV and it was all good.

Quote from: christianhanvey at Jan 21, 2013, 08:58 PM

I came here after finding this error too. Tried everything in this thread (bar the core modifications), but the actual problem for me was that I had removed a package that still had a TV looking for its components. I deleted the TV and it was all good.

I would love to see a ticket in the tracker describing this issue. Even if it only results in documentation or helps form best practices, I think it's important this behavior is considered when removing a package that has dependencies in core data.

There have been packages of mine that crashed Setup with a plugin. A plugin connected to a save event for Resources or Users can try to use an empty $user or $resource object. There is a constant set during Setup to avoid this, but it's not set early enough to work reliably. I'm not sure about Resources, but one 2.x upgrade saves the user before the constant is set.

It might be a good idea to have Setup set the constant very early and have the core check it before running any plugin and not run the plugin during Setup. Most plugin authors won't know enough to test for the constant.

Filed: http://tracker.modx.com/issues/9445

Quote from: christianhanvey at Jan 21, 2013, 08:58 PM

I came here after finding this error too. Tried everything in this thread (bar the core modifications), but the actual problem for me was that I had removed a package that still had a TV looking for its components. I deleted the TV and it was all good.

To clarify, this was a TV using a custom TV type (from the 'formz' add-on package) which had been removed. Without having investigated it in detail, I'm guessing editing the resource initiated the encounter of a tv type that didn't exist, forcing the error.

Possible solutions I can think of:
- Change in the package removal process to look for tv types added by the package.
- More graceful handling of an unfound tv-type when creating/updating a resource.
- Change process in setup to check existing tvs against listed tv types, and warn about any unknown tv types

Quote from: ReSpawN at Apr 04, 2012, 09:31 PM

I take it back... It was a sloppy, crappy and insanely stupid custom TV... Sorry MODX :$

Just experienced this for the first time myself. In the end, it also ended up being a "bad TV", however no custom type here. It was ported from Evo > Revo via Provisioner...not sure if it's related?

Oddly, editing the Resource worked fine until I made a change to the one of Rich Text TVs, then something got malformed during the Save process. I finally deleted it and voila! -- editing Resource was restored.

Just ran into this issue again.

In this occurrence, site was also ported from Evo > Revo via Provisioner...

The solution ended up being related to multiple TVs of (now) invalid type: "dropdown" ...by manually updating each "dropdown" TV to the new "listbox" Listbox (Single-Select), the error went away and I was able to move forward with editing Resources.

It seems there is a work-around to suppress this error: https://gist.github.com/pepebe/7318178 however the real solution appears to be related to "clean" TV types, and ensuring entries in the database are valid.

Quote from: opengeek at Jan 22, 2013, 09:40 AM

I would love to see a ticket in the tracker describing this issue. Even if it only results in documentation or helps form best practices, I think it's important this behavior is considered when removing a package that has dependencies in core data.

Here you go, Jason: https://github.com/modxcms/revolution/issues/11255