Support » Plugin: iThemes Security (formerly Better WP Security) » Internal 404 – Plugin Path

  • Hello,

    I’m having an issue with iThemes Security where it’s getting an internal 404 error. This is causing all users to be locked out every time the log in. This WordPress site is running on a Windows server. I’m not sure if that’s part of the issue.

    Basically all the css and js files are being referred to as so:


    I believe part of the issue is __DIR__ .

    Can anyone shine some light on the situation? 🙂 If you need more information to help with a solution, just let me know. Much appreciated!

Viewing 8 replies - 1 through 8 (of 8 total)
  • Figured out the problem. If anyone else is having this issue, check the version of php you’re running. You can do this by creating a phpinfo.php page.


    // Show all information, defaults to INFO_ALL


    __DIR__ wasn’t included until after 5.3 and I was running version 5.2 of PHP.

    Nevermind that didn’t fix it.


    So I’ve figured out it’s this that’s the problem:

    $this->module_path = ITSEC_Lib::get_module_path( __FILE__ );
    	 * Returns the URL of the current module
    	 * @since 4.0
    	 * @param string $file     the module file from which to derive the path
    	 * @return string the path of the current module
    	public static function get_module_path( $file ) {
    		global $itsec_globals;
    		$path = str_replace( $itsec_globals['plugin_dir'], '', dirname( $file ) );
    		return trailingslashit( $itsec_globals['plugin_url'] . $path );

    Now if only I could find a solution…

    So I’ve gotten even further along and it seems that dirname ( __FILE__ ) is returning the wrong path. Perhaps related to configuration on the server?


    I have seen the same issue. It’s related to hosting on Windows.

    The code you posted is part of the problem, but also is how $itsec_globals are initialized on Windows.

    Line 82 in class-itsec-core.php
    ‘plugin_dir’ => plugin_dir_path( $plugin_file ), //the path of the plugin directory

    plugin_dir_path( $plugin_file ) will return something like this on Windows -> “C:\wwwroot\mysite\wp-content\plugins\better-wp-security/”

    Notice difference in back and forward slashes.

    So later in the get_module_path( $file ) function you posted, it’s trying to remove “C:\wwwroot\mysite\wp-content\plugins\better-wp-security/” from “C:\wwwroot\mysite\wp-content\plugins\better-wp-security\core” which never works because it doesn’t match.

    Then we end up with the physical path in the script URL when it’s used here.

    wp_enqueue_script( ‘itsec_file_change_warning_js’, $this->module_path . ‘js/admin-file-change-warning.js’, array( ‘jquery’ ), $itsec_globals[‘plugin_build’] );

    Essentially exposing to the world the physical path of your files on the server’s disk. This is not helping security.

    Hey Guys,

    Thanks for reporting this, I received the bug report as well. We’re doing some testing. I’ll report back here when I know more.



    Having the same issue on Windows as described and analyzed by Jeff-Lewis, there is an easy temporary fix until this is fixed by IThemes: replace the Windows Path Separators by the Linux ones. Luckily for us changes are only required in two places:

    – core/class-itsec-core.php:82 : Replace with 'plugin_dir' => str_replace('\\', '/', plugin_dir_path( $plugin_file )), //the path of the plugin directory
    – core/class-itsec-global-settings:388 : Replace with $path = str_replace( $itsec_globals['plugin_dir'], '', str_replace('\\', '/', dirname( $file )) );

    fgerneth: Thanks for this suggestion. I have the same issue as macdonaldr93 above. I see the relevant code to replace in that first location – core/class-itsec-core.php:82 – but in the second location – core/class-itsec-global-settings:388 – I just see the closing parenthesis and semicolon of an add_settings_field for itsec_global[user_lockout_message]. This doesn’t seem like the right line to replace. Could you list the actual code that needs to be replaced in this file with the code you’ve provided above? That would be great. Fixing just the one location hasn’t solved the 404 issue, so I’m assuming I need to also find a way to make that second fix.

    iThemes Support: Any word on a long-term fix for this issue? The 404s pile up because of the paths issue described above. I’m likewise hosting in a Windows environment.


Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘Internal 404 – Plugin Path’ is closed to new replies.