Forum Replies Created

Viewing 15 replies - 1 through 15 (of 752 total)
  • Thank you, I really appreciate your feedback.

    Hmm, in another identical topic I received confirmation that it definately fixed the very same issue. I’m pretty confident (99.999999%) it should fix the issue in your env too. I’m not guessing. Did my homework, before coming up with this solution. Perhaps (Cloudflare) caching is preventing the fix from getting effectuated.

    One thing is for sure, it’s a plugin conflict. You could try and temporarily deactivate all plugins except iThemes Security. That should make the Settings page work again. Then activate the other plugins one by one and keep testing the Settings page.
    This way you should be able to identify the conflicting plugin.

    The more plugins your site is using the higher the chances this particular plugin conflict will occur.

    Please share the list of active plugins in your site. This will help identify plugins that are shared on sites that run into the same issue.

    In the other topic it turned out to be the plugin named:

    Ultimate Addons for Elementor (This is a paid for premium plugin).

    According to the iTSec plugin 7.8.0 Changelog:

    Enhancement: Remove quick bans. Persist banned hosts to .htaccess or nginx.conf on an hourly schedule.

    The plugin uses WP cron to write the IPs to the .htaccess file. The cron task is named flush-files and runs hourly.

    • This reply was modified 2 days, 20 hours ago by nlpro.

    Ok, great. It looks like you solved the issue! So now you need to restore the backup copy of the better-wp-security/core/lib/class-itsec-lib-file.php file.

    That should solve the new error.

    • This reply was modified 2 days, 21 hours ago by nlpro.
    • This reply was modified 2 days, 21 hours ago by nlpro.
    • This reply was modified 2 days, 21 hours ago by nlpro.

    Yes, that is correct. I’ve decided to change our debugging strategy. Let’s run the itsec-write-test.php script now. Update the topic with the output.

    Remember you can only run the itsec-write-test.php script from a second tab after logging into WordPress Dashboard from the first tab of the browser.

    We need the WordPress authentication cookie to exist in the browser in order to be able to run the itsec-write-test.php script. Just a bit of background info 😉

    Oh, almost forgot. Is there currently anything related to the iThemes Security plugin in the .htaccess file ? (I guess not).

    iThemes entries in the .htaccess file will be between 3 lines as seen below:

    # 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

    Note these lines could be translated in the local language.

    • This reply was modified 2 days, 21 hours ago by nlpro.
    • This reply was modified 2 days, 21 hours ago by nlpro.

    Ah, it looks I haven’t explained it properly. Probably best to start using line numbers(#).

    Use this to help you find your way in the code.

    The 3 new lines need to be added right before line #154. Below the code line to search for:

    #154 foreach ( $trial_perms as $perms ) {

    The better-wp-security/core/lib/class-itsec-lib-file.php file starts with code for the read() method (#27-102). Next is the code for the write() method (#114-236). We will focus on the code between line #154 and #236 inside the write() method.

    The foreach line exists in both the read() and the write() method. Make sure to add the 3 new lines within the write() method (before line #154).

    Goodmorning. Ok, let’s put some extra debugging code in the write() method of the better-wp-security/core/lib/class-itsec-lib-file.php file. This will help us understand what execution path is followed.

    The write() method makes use of 2 possible PHP file write functions (fwrite() or file_put_contents()).
    Below 3 extra lines of code that need to be added. You can ignore the 3 dots (…). They are only there to indicate there is other code before and after the code snippet. The $callable variable holds which of the 2 PHP write functions are available in your system.

    ...
    
    echo '<pre>';         //New line
    print_r( $callable ); //New line
    echo '</pre>';        //New line
    
    foreach ( $trial_perms as $perms ) { //Search for this line in the write() method.
    
    ...

    If you have any questions about this change let me know. Let’s do this step by step. First confirm the above change in the code. Once confirmed I’ll post a second code change. When both code changes for debugging are implemented we will run the test script (itsec-write-test.php ) and evaluate the output.

    • This reply was modified 3 days, 1 hour ago by nlpro.
    • This reply was modified 3 days, 1 hour ago by nlpro.

    Ok, great. Thank you for the extra info. Let’s continue with debugging tomorrow 😉

    Ah, my mistake. But it’s also good news because the test script seems to be able to reproduce the issue. Which means we can continue debugging!

    Let’s correct the code mistake I made. Change the following line in the itsec-write-test.php file:

    echo 'Error msg: ' . $result::get_error_message();

    Into:

    echo 'Error msg: ' . $result->get_error_message();

    Undo the changes to the wp-config.php file.
    Then retest.

    • This reply was modified 3 days, 15 hours ago by nlpro.

    Ok. It seems it doesn’t always send the email. Try and add the lines below to the wp-config.php file:

    define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );
    define( 'WP_DEBUG', true );

    Note: The WP_DEBUG line is already present in the wp-config.php file. By default it is set to false.

    With both WP constants set to true, retry.

    • This reply was modified 3 days, 16 hours ago by nlpro.
    • This reply was modified 3 days, 16 hours ago by nlpro.

    Ok. Not big. Are you able to look into the email send to the site admin ? There may be additional php error info in that email.

    Ok, so the code is ok, but php cannot handle writing to the .htaccess file.

    What is the current file size of that .htaccess file ?

    Ok, let’s do one step back to the original code (that worked):

    <?php
    
    /** WordPress Administration Bootstrap */
    require_once __DIR__ . '/admin.php';
    
    /** Only users with manage options capability allowed */
    if ( ! current_user_can( 'manage_options' ) ) {
    	wp_die( __( 'Sorry, you are not allowed to manage options on this site.' ) );
    }
    
    /** Write to a new test file */
    $result = ITSEC_Lib_File::write( '/var/www/html/wordpress/test1.txt', "This is a test.\n" );
    
    /** Check and show the result */
    if ( is_wp_error( $result ) ) {
    	 echo 'Error msg: ' . $result::get_error_message();
    } else {
    	 echo 'File writing ' . ( $result?'succeeded.':'failed.' );
    }

    Run the test to make sure this code works.

    If it still doesn’t work delete the current wp-admin/itsec-write-test.php file and make a new one. Probably best to copy/paste the code from this post into the new file. Then retry. We need to make sure we have a working test script before moving on to the next step.

    Once the script works again replace the string “test1.txt” with “.htaccess”. Nothing more, nothing less.

    Make sure you have a proper backup of the .htaccess file !

    Then retest.

    Last option, remove the extra comment line:

    /**$result = ITSEC_Lib_File::write( '/var/www/html/wordpress/.htaccess', "This is a .htaccess test.\n" );*/

    Using Wordfence should not be a problem.

    I think adding .htaccess twice may be the problem.

    So change the write line to look like this:

    $result = ITSEC_Lib_File::write( '/var/www/html/wordpress/.htaccess', "This is a test.\n" );

    Then retry.

    Ok, great.

    The test script is based upon the wp-admin/index.php file. There is no php end tag included in that file so I saw no reason to add it to our test script 😉 Also most WordPress php files do not include the php end tag. It’s not a fatal error …

    Anyway, we have a positive result when writing to a NEW file in the same folder where the .htaccess file exists. Did the second write test also return a positive result ? (Oh, to keeps things tidy you can delete the newly created test1.txt file).

    Before starting debugging we need to make sure we can reproduce the issue when using the test script. So next we will try to write to the existing .htaccess file.

    IMPORTANT: First create a backup copy of the .htaccess file !!

    Then change the test script (itsec-write-test.php) and simply change the filename “test1.txt” into “.htaccess”

    Now run the test script again. If the issue reproduces it should return:

    Error msg: /var/www/html/wordpress/.htaccess could not be written. This could be due to a permissions issue. Ensure that PHP runs as a user that has permission to write to this location.

    If the issue does not reproduce, check the content of the .htaccess file. If the content is overwritten RESTORE the .htaccess file from the backup file we created earlier!

    • This reply was modified 3 days, 22 hours ago by nlpro.
Viewing 15 replies - 1 through 15 (of 752 total)