Are you running upgrade.php in a code editor? That would explain the port number in the URL and the problem. When you switch to a different port, the session is lost and you're no longer logged in. If you're running it in MODX, it should just forward you to the script without changing the port number, unless you have something unusual in .htaccess.
Quote from: BobRay at Aug 26, 2018, 08:54 PMAre you running upgrade.php in a code editor? That would explain the port number in the URL and the problem. When you switch to a different port, the session is lost and you're no longer logged in. If you're running it in MODX, it should just forward you to the script without changing the port number, unless you have something unusual in .htaccess.
The port was my idea. I was telling you that the default port (80) was in use. The URL reads: https://myserver/upgrade.php.
This is all I have in .htaccess: I have removed all the comments for brevities sake:
RewriteEngine On
RewriteBase /
# The Friendly URLs part
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
Is there anything weird going on here?
James
Quote from: jxarms3 at Aug 27, 2018, 12:19 AMQuote from: BobRay at Aug 26, 2018, 08:54 PMAre you running upgrade.php in a code editor? That would explain the port number in the URL and the problem. When you switch to a different port, the session is lost and you're no longer logged in. If you're running it in MODX, it should just forward you to the script without changing the port number, unless you have something unusual in .htaccess.
The port was my idea. I was telling you that the default port (80) was in use. The URL reads: https://myserver/upgrade.php.
This is all I have in .htaccess: I have removed all the comments for brevities sake:
RewriteEngine On
RewriteBase /
# The Friendly URLs part
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
Is there anything weird going on here?
James
Quote from: jxarms3 at Aug 27, 2018, 07:28 AMQuote from: jxarms3 at Aug 27, 2018, 12:19 AMQuote from: BobRay at Aug 26, 2018, 08:54 PMAre you running upgrade.php in a code editor? That would explain the port number in the URL and the problem. When you switch to a different port, the session is lost and you're no longer logged in. If you're running it in MODX, it should just forward you to the script without changing the port number, unless you have something unusual in .htaccess.
The port was my idea. I was telling you that the default port (80) was in use. The URL reads: https://myserver/upgrade.php.
This is all I have in .htaccess: I have removed all the comments for brevities sake:
RewriteEngine On
RewriteBase /
# The Friendly URLs part
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
Is there anything weird going on here?
James
my root/manager directory has a ht.access file that was never converted to .htaccess.
Also, when click the "Upgrade MODX" button. I am logged out.
As far as being logged out. UGM logs everyone out when it launches the script, so that's normal. It should be launching the upgrade.php script in the root of the MODX site. If you go to http://yoursite.com/upgrade.php in your browser, you should see it. MODX only steps in if the requested file is not found, so it could be a file or directory permission problem with the upgrade.php file.
That's really strange. The Widget snippet opens that file at MODX_BASE_PATH . 'upgrade.php' for writing and throws an error if the file isn't opened successfully. I don't know how it could fail to exist with you getting an error message. Even if the write failed, there's be a 0-length file there.can I simply put the file there? Can I download the extra locally and manually place the file there? Would there be an error in the error log as to why the file was not present?
Quote from: BobRay at Aug 27, 2018, 12:44 PMThat's really strange. The Widget snippet opens that file at MODX_BASE_PATH . 'upgrade.php' for writing and throws an error if the file isn't opened successfully. I don't know how it could fail to exist with you getting an error message. Even if the write failed, there's be a 0-length file there.can I simply put the file there? Can I download the extra locally and manually place the file there? Would there be an error in the error log as to why the file was not present?