New Login URL – 404 not found

Edit: I deleted WordPress from my mySQL database and reinstalled it. First thing I did afer reinstallation was updating wordpress and then installing the Solid Security Plugin. After changed the login slug, still the same problem.

Permalinks are enabled and cache is cleared, tried different browsers. Does not make any difference whether redicrection is enabled or not

Could it be a problem with the Apache server? With my other website, there are no problem with changing the URL although it runs on the same server. These are my sever settings:

Server architectureLinux 5.10.0-26-amd64 x86_64Web serverApachePHP version8.0.30 (Supports 64bit values)PHP SAPIapache2handlerPHP max input variables1000PHP time limit30PHP memory limit256MMax input time-1Upload max filesize50MPHP post max size50McURL version7.74.0 OpenSSL/1.1.1wIs SUHOSIN installed?NoIs the Imagick library available?YesAre pretty permalinks supported?YesCurrent time2024-03-22T23:04:59+00:00Current UTC timeFriday, 22-Mar-24 23:04:59 UTCCurrent Server time2024-03-23T00:04:58+01:00

Related topics with the same problem:
https://www.ads-software.com/support/topic/hide-backend-changed-but-still-wp-admin-login-slug-working/
https://www.ads-software.com/support/topic/hide-backend-error-404/

I just deactivated that function that I am able to login again tomorrow.

• This reply was modified 8 months ago by wpzugang.
• This reply was modified 8 months ago by wpzugang.

Update: I checked the security and it looks like the script cannot access the the apache config file:

Module Core
Type Critical Issue
Description Empty file encountered when attempting to update apache config file.

I contacted the the service provider but they also could not find out why the script has no access to the server.

Hi @wpzugang, glad you reached out and we appreciate the details of your troubleshooting!

That error indicates that Solid Security cannot properly write to your filesystem. It’s a bit unclear why this happens as we haven’t replicated this in our test environment, but I’d suggest that you try disabling the “Write to Files” setting in?Security > Settings > Global Settings?and manually add the plugin rules to the server config files. To get the plugin rules, go to?Security >Tools?and locate the “Server Config Rules” and the “wp-config.php Rules”.

Once done, please check if you’re still getting that error and if you can access the custom HBE link.

Looking forward to hearing how it goes!

Hi @chandelierrr;
I added the server config rules to wp-config.php at the bottom and after the website did not work anymore. So I must have done something wrong.

Can you explain a bit more detailled how to add the config rules? Do I have to delete the already existing part of Solid security in the wp-config.php? Do I have to add only the part “Server Config Rules” or also “wp-config.php Rules” from Securit -> Tools section?

This is the part I added at the bottom of wp-config.php:

# BEGIN iThemes Security - Do not modify or remove this line# iThemes Security Config Details: 2    # Protect System Files - Security > Settings > System Tweaks > System Files    <files .htaccess>        <IfModule mod_authz_core.c>            Require all denied        </IfModule>        <IfModule !mod_authz_core.c>            Order allow,deny            Deny from all        </IfModule>    </files>    <files readme.html>        <IfModule mod_authz_core.c>            Require all denied        </IfModule>        <IfModule !mod_authz_core.c>            Order allow,deny            Deny from all        </IfModule>    </files>    <files readme.txt>        <IfModule mod_authz_core.c>            Require all denied        </IfModule>        <IfModule !mod_authz_core.c>            Order allow,deny            Deny from all        </IfModule>    </files>    <files wp-config.php>        <IfModule mod_authz_core.c>            Require all denied        </IfModule>        <IfModule !mod_authz_core.c>            Order allow,deny            Deny from all        </IfModule>    </files>    # Disable Directory Browsing - Security > Settings > System Tweaks > Directory Browsing    Options -Indexes    <IfModule mod_rewrite.c>        RewriteEngine On        # Protect System Files - Security > Settings > System Tweaks > System Files        RewriteRule ^wp-admin/install\.php$ - [F]        RewriteRule ^wp-admin/includes/ - [F]        RewriteRule !^wp-includes/ - [S=3]        RewriteRule ^wp-includes/[^/]+\.php$ - [F]        RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F]        RewriteRule ^wp-includes/theme-compat/ - [F]        RewriteCond %{REQUEST_FILENAME} -f        RewriteRule (^|.*/)\.(git|svn)/.* - [F]        # Disable PHP in Uploads - Security > Settings > System Tweaks > PHP in Uploads        RewriteRule ^wp\-content/uploads/.*\.(?:php[1-7]?|pht|phtml?|phps)\.?$ - [NC,F]        # Disable PHP in Themes - Security > Settings > System Tweaks > PHP in Themes        RewriteRule ^wp\-content/themes/.*\.(?:php[1-7]?|pht|phtml?|phps)\.?$ - [NC,F]    </IfModule>    # Disable XML-RPC - Security > Settings > WordPress Tweaks > XML-RPC    <files xmlrpc.php>        <IfModule mod_authz_core.c>            Require all denied        </IfModule>        <IfModule !mod_authz_core.c>            Order allow,deny            Deny from all        </IfModule>    </files># END iThemes Security - Do not modify or remove this line

• This reply was modified 7 months, 3 weeks ago by wpzugang.

Hi @wpzugang,

Security >Tools > Server Config Rules –> .htaccess file (Apache config file)

Security >Tools > wp-config.php Rules –> wp-config.php file (WordPress config file)

When you disable the “Write to Files” setting, no Solid Security rules are automatically written to the .htaccess (Apache config file) or wp-config.php (WordPress config file) file. This also means that any Solid Security rules that have been written to these 2 files in the past should automatically be cleared. If that is not the case (for whatever reason) it’s probably best to have clean files (That is, without any SolSec rules) to begin with.

Below I will attempt to give you an overview of how these 2 files are structured once the SolSec rules are manually included. Hopefully this will answer most of your questions. First the .htaccess file (Apache config file):

# BEGIN iThemes Security - Do not modify or remove this line
# iThemes Security Config Details: 2
...
# END iThemes Security - Do not modify or remove this line

# BEGIN WordPress
# The directives (lines) between "BEGIN WordPress" and "END WordPress" are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

Where … represents the actual SolSec rules. For clarity’s sake I’m not including the actual rules. Note: The old iThemes Security plugin name is still in use in the SolSec plugin comment lines (These serve as templates that can be used by the plugin code to find stuff). No need for panic. This is probably for backward compatibility reasons (right @shanedelierrr?)

On to the structure of the wp-config.php file (WordPress config file):

<?php

// BEGIN iThemes Security - Do not modify or remove this line
// iThemes Security Config Details: 2
...
// END iThemes Security - Do not modify or remove this line

define( 'ITSEC_ENCRYPTION_KEY', 'Vh9HWGprIEFzXvRZbEk3bzw0MDAsM0spNVJoP4dIVzh+bj5kU1NabC52RjtoamM7M3VLPGlQTllyRTQtQFsoNA==' );

/** 
 * The base configurations of the WordPress.
 *
 * This file has the following configurations: MySQL settings, Table Prefix,
 * Secret Keys, WordPress Language, and ABSPATH. You can find more information by
 * visiting {@link https://codex.www.ads-software.com/Editing_wp-config.php Editing
 * wp-config.php} Codex page. You can get the MySQL settings from your web host.
 *
 * This file is used by the wp-config.php creation script during the
 * installation. You don't have to use the web site, you can just copy this file
 * to "wp-config.php" and fill in the values.
 *
 * @package WordPress
 */
...
/** WordPress absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
	define('ABSPATH', dirname(__FILE__) . '/');

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

Again I am using … to represent omitted lines that are irrelevant. Note there is a line included outside the SolSec plugin template that defines the ITSEC_ENCRYPTION_KEY constant. One would expect that to be within the SolSec plugin template but (probably for good reasons) it’s not ??

I hope this helps.

You are correct @nlpro! As always, we appreciate your assistance!

@wpzugang please see nlpro’s detailed reply on how the plugin rules will be added to the config files. If for some reason there is still an issue, you can always reach out to our support?channel, so we can look at your config files.

Please let us know how it goes!

Thank you for that detailled expanation.

I checked .htaccess file and wp-config file.

Edit. Forget what I wrote before. The .htaccess file was completely missing on the server for this domain! Instead, there is a .htaccess in the root folder of the server, independently from the domains. This is what I checked before and why I thought everything is okay. No idea why it is there.

I just copied the htaccess from my other, older working website and inserted it at the new domain wp root folder. This is how it looks now (complete)

BEGIN iThemes Security - Do not modify or remove this line iThemes Security Config Details: 2

# Protect System Files - Security > Settings > System Tweaks > System Files
<files .htaccess>
    <IfModule mod_authz_core.c>
        Require all denied
    </IfModule>
    <IfModule !mod_authz_core.c>
        Order allow,deny
        Deny from all
    </IfModule>
</files>
<files readme.html>
    <IfModule mod_authz_core.c>
        Require all denied
    </IfModule>
    <IfModule !mod_authz_core.c>
        Order allow,deny
        Deny from all
    </IfModule>
</files>
<files readme.txt>
    <IfModule mod_authz_core.c>
        Require all denied
    </IfModule>
    <IfModule !mod_authz_core.c>
        Order allow,deny
        Deny from all
    </IfModule>
</files>
<files wp-config.php>
    <IfModule mod_authz_core.c>
        Require all denied
    </IfModule>
    <IfModule !mod_authz_core.c>
        Order allow,deny
        Deny from all
    </IfModule>
</files>

# Disable Directory Browsing - Security > Settings > System Tweaks > Directory Browsing
Options -Indexes

<IfModule mod_rewrite.c>
    RewriteEngine On

    # Protect System Files - Security > Settings > System Tweaks > System Files
    RewriteRule ^wp-admin/install\.php$ - [F]
    RewriteRule ^wp-admin/includes/ - [F]
    RewriteRule !^wp-includes/ - [S=3]
    RewriteRule ^wp-includes/[^/]+\.php$ - [F]
    RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F]
    RewriteRule ^wp-includes/theme-compat/ - [F]
    RewriteCond %{REQUEST_FILENAME} -f
    RewriteRule (^|.*/)\.(git|svn)/.* - [F]

    # Disable PHP in Uploads - Security > Settings > System Tweaks > PHP in Uploads
    RewriteRule ^wp\-content/uploads/.*\.(?:php[1-7]?|pht|phtml?|phps)\.?$ - [NC,F]

    # Disable PHP in Themes - Security > Settings > System Tweaks > PHP in Themes
    RewriteRule ^wp\-content/themes/.*\.(?:php[1-7]?|pht|phtml?|phps)\.?$ - [NC,F]
</IfModule>

# Disable XML-RPC - Security > Settings > WordPress Tweaks > XML-RPC
<files xmlrpc.php>
    <IfModule mod_authz_core.c>
        Require all denied
    </IfModule>
    <IfModule !mod_authz_core.c>
        Order allow,deny
        Deny from all
    </IfModule>
</files>

END iThemes Security - Do not modify or remove this line BEGIN WordPress The directives (lines) between "BEGIN WordPress" and "END WordPress" are dynamically generated, and should only be modified via WordPress filters. Any changes to the directives between these markers will be overwritten.

RewriteEngine On RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] RewriteBase / RewriteRule ^index.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] END WordPress

Now I can access to my custom URL and all changes are saved correctly So Hide Backend works now.

The only difference in the wp-config is now that the new, not working website has an if statement for debug while the old working website has not.
Old working website:

define( 'WP_DEBUG', false );

New, not working website:

if ( ! defined( 'WP_DEBUG' ) ) {    define( 'WP_DEBUG', false );

• This reply was modified 7 months, 3 weeks ago by wpzugang.
• This reply was modified 7 months, 3 weeks ago by wpzugang.

Unfortunatley, that didn’t solve the problem for long-term. Today I again got a 404 error message at my custom login URL.
Strangely, I can still login via /wp-admin with hide-backend activated. The files in wp-config and .htaccess look still like yesterday.

The only thing I changed was installing the W3TC Browser Cache plugin yesterday so now I also have some lines for that plugin in the .ataccess.

Any other ideas?

Hi @wpzugang, I understand the issue persists.

We’re having trouble replicating this issue on our end, so we might need to take a look at a staging environment to investigate further. Can you please reach out to us here?

Hi there,

I’m following up to see if you still require assistance with the issue or if you were able to contact our help center. Tracking notifications on this forum can become tricky over time, and as we haven’t heard back from you, I’ll mark this post resolved.

If you still need help, please let us know. Thank you!

Hi, thank you for asking. The issue persists not anymore. I think it was a problem with the server because the cache is reset only every 24 hours.