Upgrading and mod_security

Want to continue the thread from the old forum:
https://forums.modx.com/thread/105000/upgrading-and-mod-security#dis-post-564605

The response is not a error messeage but a long css definition beginning with
** * xtheme-modx * Copyright © 2009-2012,shaun@modx.com,MODX,LLC * * xtheme-modx is licensed under the terms of the GNU Open Source GPL 2.0 * or later license. * * This program is free software:you can redistribute it and/or modify it under * the terms of the GNU Genera

Isn’t this the managers css? No idea why this happens.

That was the response from connector/index.php shown on the response tab?

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

    {
    "success": true,
    "message": "",
    "total": 0,
    "data": [],
    "object": [{
        "icon": "\/manager\/templates\/default\/images\/restyle\/icons\/arrow_down.png",
        "tooltip": "Baum aufklappen",
        "handler": "this.expandAll"
    }, {
        "icon": "\/manager\/templates\/default\/images\/restyle\/icons\/arrow_up.png",
        "tooltip": "Baum zuklappen",
        "handler": "this.collapseAll"
    }, "-", {
        "icon": "\/manager\/templates\/default\/images\/restyle\/icons\/folder_page_add.png",
        "tooltip": "Neues Dokument",
        "handler": "new Function(\"this.redirect(\\\"index.php?a=55\\\");\");"
    }, {
        "icon": "\/manager\/templates\/default\/images\/restyle\/icons\/page_white_link.png",
        "tooltip": "Neuer Weblink",
        "handler": "new Function(\"this.redirect(\\\"index.php?a=55&class_key=modWebLink\\\");\");"
    }, {
        "icon": "\/manager\/templates\/default\/images\/restyle\/icons\/page_white_copy.png",
        "tooltip": "Neuer Symlink",
        "handler": "new Function(\"this.redirect(\\\"index.php?a=55&class_key=modSymLink\\\");\");"
    }, {
        "icon": "\/manager\/templates\/default\/images\/restyle\/icons\/page_white_gear.png",
        "tooltip": "Neue statische Ressource",
        "handler": "new Function(\"this.redirect(\\\"index.php?a=55&class_key=modStaticResource\\\");\");"
    }, "-", {
        "icon": "\/manager\/templates\/default\/images\/restyle\/icons\/refresh.png",
        "tooltip": "Baum aktualisieren",
        "handler": "this.refresh"
    }, {
        "icon": "\/manager\/templates\/default\/images\/restyle\/icons\/unzip.gif",
        "tooltip": "Sortier-Optionen anzeigen",
        "handler": "this.showFilter"
    }, "-", {
        "icon": "\/manager\/templates\/default\/images\/restyle\/icons\/trash.png",
        "tooltip": "Gel\u00f6schte Ressourcen endg\u00fcltig entfernen",
        "handler": "this.emptyRecycleBin"
    }]
}

is that the item you mean? The response doesnt look well.
There are another 8 index.php?.. with diffrent arguments

Sorry, I should have been more specific. Neither of those is the relevant one. Try this:

  1. Go to edit a chunk.
  2. Launch Dev. Tools.
  3. Select the Network tab
  4. If the Network tab is not already empty, click on the circle with the line through it at the left to clear it.
  5. Make a change to the chunk (add a space somewhere).
  6. Click on the “Save” button.

The index.php file you want is the first one. Hover should show you yoursite.com/connectors/index.php

The formdata section at the bottom of the Header tab should have the action as element/chunk/update.

On the response tab, you should see a JSON string containing the Chunk’s fields (or an error message).

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.

Can you paste the full Form Data section from the Headers tab (don’t paste the HTTP_MODAUTH token).

action: create
category: 0
modx-ab-stay:
propdata:
id:
props:
name: testchunk2
description:
static_file:
category: 0
locked: 0
clearCache: 1
static: 0
source: 1
snippet:

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.

:slight_smile: 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?

I would upgrade to 2.3.0, 2.4.0, 2.5.0 and 2.6.0, then try to install UGM again and upgrade to 2.7.0, and 2.7.1.

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

RewriteCond %{HTTP_HOST} piratelsat\.com [NC]
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://piratelsat.com/$1 [R,L]

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.

The rewrite condition for https is not the problem. Manually typing https already gets redirected to http.

1 Like

So, some additional questions:

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?

Make sure the server_protocol System Setting is set to https. You may also need an http -> https rewrite rule in .htaccess.

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.

1 Like

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”.