I reviewed it again.
I find two index.php. On hover they show
connectors/source/index.php
and
connectors/resource/index.php
both have the ext-base.js as initiator
I didn’t find anything like the propdata at the header tab
Under the response tab both show
I get a chunk.php with connector/element/chunk.php
The respondes json is
Warning: preg_match(): Compilation failed: invalid range in character class at offset 38 in /www/htdocs/www/core/xpdo/validation/xpdovalidator.class.php on line 82
{“success”:false,“message”:"",“total”:1,“data”:[{“id”:“name”,“msg”:“Der Chunk-Name ist ung\u00fcltig.”}],“object”:}
The new created chunk name was “testchunk2”. Updating existing Chunks was ok, but not creating new ones. I cannot see, why the name should be invalid.
I’m stumped. I don’t see any reason why that wouldn’t work. My only thought is that you have a missing or corrupted core file. That’s fairly common if you transfer the files individually with FTP.
If you use UpgradeMODX, you can set the MODX settings_version System Setting back to an earlier version of MODX and then “upgrade” to the version you already have. That will give you all new MODX core files, clear the cache completely, and re-run setup.
UpgradeModx cannot be installed properly, that was the starting point of my odysse.
So I think, I have to do it manualy. The installed version is 2.2.6. So would you recommend to fix 2.2.6 by reinstalling manually, or upgrading directly to the latest version?
So, finally I managed to get it done. After manualy upgrading to 2.3.0 UGM was working again and all other version steps could be installed via UGM.
But I now ran into a different problem with switching to https. Modx seem to redirect all requests to http. I cannot find any configuration that is responsible for that. Forcing https leads to redirect errors. Without forcing all https is redirected to http. Any configuration I missed out or even some that could be still there from the upgrades?
Do you have a system setting or context setting set for site_url or scheme? If not, do you have your <base href="[[++site_url]]"> uncached or cached (it should be uncached (with the !))? Do you have any rules in hour .htaccess file or nginx configuration that is redirecting to http? Do you have hardcoded paths to assets or js or are you using cached [[++site_url]] (it should always always be uncached [[!++site_url]]?
You can re-write requests to http in your htaccess file on the server. Mine has this which I believe works, I spent awhile working out the https solution, which was hard to pin down.
The header as Jay says is also a possible place to do this, but it may lead to errors (which are in the browser right next to the url). It was hard to get that icon to stay on green
tried that already. There must be another configuration that I do not find.
I tried also to alter the link_tag_scheme to 1 / https and site_url with https in system settings. I switched from contextrouter to gatewaymanager and back.
Each time I use https in the browser I get redirected to http.
.htacces ist also checked. My hoster has no logs on it. Must be something caused in the client.
When you look in the network tab of the web inspector, do you see a 301 happening?
Does this occur if you change browsers?
Does this occur if you try the site on mobile?
What happens if you disable the routing plugin you have in place?
Now I found it. It was an old pluginscript that caused the redirection. It was in a totaly different place as I was expecting.
So thanks everyone for your support. You helped me focusing.
This topic was automatically closed 2 days after discussion ended and a solution was marked. New replies are no longer allowed. You can open a new topic by clicking the link icon below the original post or solution and selecting “+ New Topic”.