Title: Recent plugin update blocks file include?
Last modified: August 30, 2016

---

# Recent plugin update blocks file include?

 *  Resolved [rjspiteri](https://wordpress.org/support/users/rjspiteri/)
 * (@rjspiteri)
 * [10 years, 9 months ago](https://wordpress.org/support/topic/recent-plugin-update-blocks-file-include/)
 * Hi there,
 * I’ve just updated the iThemes security plugin to the latest version on an internal
   wordpress instance. Doing so a couple of pages on the site have stopped working–
   those pages just load a text file from disk and display the contents on screen.
 * Disabling the plugin allows the file(s) to be displayed just fine. And before
   the update the files displayed fine too. Can someone tell me if they’ve come 
   across something similar? Any suggestions perhaps in resolving it?
 * I can’t pass on a link (the site’s internal) – but I think the only relevant 
   bit is the file import and prep for display:
 *     ```
       $dom = new DOMDocument();
       @$dom->loadHTMLFile(get_bloginfo('url').'/data/whatever.txt');
       $xpath = new DOMXPath($dom);
       ```
   
 * The code hasn’t changed (and as far as I’m told the system hasn’t either), the
   line that would load the HTML is generating the correct URL Path, and when I 
   browse to that path I can view the file to be processed.
    The file that it’s 
   trying to import is owned by apache and has a+r privileges. SELinux is not blocking
   access.
 * [https://wordpress.org/plugins/better-wp-security/](https://wordpress.org/plugins/better-wp-security/)

Viewing 8 replies - 1 through 8 (of 8 total)

 *  Thread Starter [rjspiteri](https://wordpress.org/support/users/rjspiteri/)
 * (@rjspiteri)
 * [10 years, 9 months ago](https://wordpress.org/support/topic/recent-plugin-update-blocks-file-include/#post-6400202)
 * One other thing I’ve noticed is that the modsec_audit.log populates with request
   information regarding that file when the plugin is activated – and I’m seeing
   something like this:
 *     ```
       --ff21ba30-F--
       HTTP/1.1 403 Forbidden
       X-Frame-Options: SAMEORIGIN
       Content-Length: 236
       Connection: close
       Content-Type: text/html; charset=iso-8859-1
       ```
   
 * So I’m guessing something needs to be whitelisted on the iThemes Security management
   page? (assuming that’s even relevant) The iThemes Security logs themselves do
   not display anything useful about this error.
 *  [dwinden](https://wordpress.org/support/users/dwinden/)
 * (@dwinden)
 * [10 years, 9 months ago](https://wordpress.org/support/topic/recent-plugin-update-blocks-file-include/#post-6400289)
 * If you have the HackRepair.com blacklist setting enabled in the Banned Users 
   section of the iTSec plugin Settings page try and disable it.
    Then see whether
   that makes any difference.
 * dwinden
 *  Thread Starter [rjspiteri](https://wordpress.org/support/users/rjspiteri/)
 * (@rjspiteri)
 * [10 years, 9 months ago](https://wordpress.org/support/topic/recent-plugin-update-blocks-file-include/#post-6400297)
 * Hi Dwinden!
    thanks very much for taking the time to reply.
 * I’ve unchecked that item – and sure enough contents are displayed perfectly now
   😀
    Do you think the update set that option as a default – or should I enable
   it again, and in some place/config try to add our server IP as some sort of exception?
 * Any advice would be very much appreciated – I’m hoping to keep things at least
   as secure as it once was.
    Robin.
 *  [dwinden](https://wordpress.org/support/users/dwinden/)
 * (@dwinden)
 * [10 years, 9 months ago](https://wordpress.org/support/topic/recent-plugin-update-blocks-file-include/#post-6400361)
 * No, I don’t believe the HackRepair.com blacklist setting is enabled by default.
   
   So updating the plugin did not enable the blacklist setting. However the blacklist
   included with the latest plugin updates did change…
 * It’s probably this (new) line in the blacklist that is causing trouble:
 * > RewriteCond %{HTTP_USER_AGENT} “^$” [NC,OR]
 * It makes sure any requests with no User Agent are forbidden (403).
 * Temporarily enable the HackRepair.com blacklist setting and then manually remove
   the mentioned no User Agent line from your .htaccess file and do a quick test.
 * If the test result shows it now works you can make the change more permanent.
 * Assuming your Web Server is Apache create a backup copy of the wp-content/plugins/
   better-wp-security/core/modules/ban-users/lists/hackrepair-apache.inc file.
    
   Then edit the file and remove the aforementioned line. Then disable (save) and
   reenable (save) the HackRepair.com blacklist setting. This will ensure your mod
   to the HackRepair.com .inc template file will get propagated to your .htaccess
   file EVERY time you save settings. Verify the mod is indeed now included in the.
   htaccess file.
 * Keep in mind this change will be undone when updating the plugin in the future.
   Then again iThemes may decide to alter the HackRepair.com .inc template files
   any moment … perhaps with the next update.
 * If the above info answered your question please mark it as ‘resolved’.
 * dwinden
 *  Thread Starter [rjspiteri](https://wordpress.org/support/users/rjspiteri/)
 * (@rjspiteri)
 * [10 years, 9 months ago](https://wordpress.org/support/topic/recent-plugin-update-blocks-file-include/#post-6400397)
 * Hi Dwinden,
    thanks very much again – that solves my problem, I’ll mark this 
   as resolved. Have a great weekend over there 🙂 Robin.
 *  [dwinden](https://wordpress.org/support/users/dwinden/)
 * (@dwinden)
 * [10 years, 9 months ago](https://wordpress.org/support/topic/recent-plugin-update-blocks-file-include/#post-6400398)
 * [@robin](https://wordpress.org/support/users/robin/)
    Ah nice to hear it is now
   resolved. Don’t forget to mark this topic as ‘resolved’…
 * dwinden
 *  Thread Starter [rjspiteri](https://wordpress.org/support/users/rjspiteri/)
 * (@rjspiteri)
 * [10 years, 9 months ago](https://wordpress.org/support/topic/recent-plugin-update-blocks-file-include/#post-6400401)
 * Thanks again Dwinden, doing so now!
 *  [Phinos](https://wordpress.org/support/users/phinos/)
 * (@phinos)
 * [10 years, 8 months ago](https://wordpress.org/support/topic/recent-plugin-update-blocks-file-include/#post-6400524)
 * Hi,
 * I have a similar problem and when I disable blackhatrepair.com the error is gone.
   Thank you for instructions.
 * Error when blackhatrepair activated is like this:
 * Warning: getimagesize([https://www.xxxxxxx.com/wp-content/uploads/2015/08/pretty-flow-logo1.png](https://www.xxxxxxx.com/wp-content/uploads/2015/08/pretty-flow-logo1.png)):
   failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden in /home/prettyflo/
   public_html/wp-content/themes/goodstore/templates/header/header-small-444.php
   on line 39
 * Is this problem will be solved in the next updated?
 * Thank You.

Viewing 8 replies - 1 through 8 (of 8 total)

The topic ‘Recent plugin update blocks file include?’ is closed to new replies.

 * ![](https://ps.w.org/better-wp-security/assets/icon.svg?rev=3529351)
 * [Kadence Security – Password, Two Factor Authentication, and Brute Force Protection](https://wordpress.org/plugins/better-wp-security/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/better-wp-security/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/better-wp-security/)
 * [Active Topics](https://wordpress.org/support/plugin/better-wp-security/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/better-wp-security/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/better-wp-security/reviews/)

## Tags

 * [file import](https://wordpress.org/support/topic-tag/file-import/)

 * 8 replies
 * 3 participants
 * Last reply from: [Phinos](https://wordpress.org/support/users/phinos/)
 * Last activity: [10 years, 8 months ago](https://wordpress.org/support/topic/recent-plugin-update-blocks-file-include/#post-6400524)
 * Status: resolved