Forum Replies Created

Viewing 10 replies - 1 through 10 (of 10 total)
  • Thread Starter ultradust

    (@ultradust)

    In fact, upon more testing, it looks like your plugin isn’t working at all with WPEngine.

    I am having to manually clear cache for all changes.

    Thread Starter ultradust

    (@ultradust)

    Is there any chance the plugin might be updated to accommodate Windows environments automatically, without a need to make this change manually?

    Thread Starter ultradust

    (@ultradust)

    The plugin is great. Very useful feature set.

    Thread Starter ultradust

    (@ultradust)

    Wow, thank you for the swift and precise help! Excellent.

    The fix you suggested wasn’t working as-is; I had to add ‘s as follows:

    load_plugin_textdomain( ”it-l10n-better-wp-security”, false, trailingslashit( dirname( plugin_basename( $itsec_globals[”plugin_file”]))) . ”lang” );

    Now it works great. Thank you for this help!

    Thread Starter ultradust

    (@ultradust)

    PHP is not providing any help on this issue so far. Any thoughts on how to proceed?

    Thread Starter ultradust

    (@ultradust)

    OK, I’ll try to test that.

    In the meantime, PHP is demanding a short script to demonstrate the error (see https://bugs.php.net/bug.php?id=60787). I don’t know how to isolate this issue to a simple script as they ask. Do you have any recommendations?

    Thread Starter ultradust

    (@ultradust)

    OK – I filed a bug report here:

    https://bugs.php.net/bug.php?id=60787

    However:

    * In all of my WordPress installations with various plugins, only your plugin is failing in this manner. Are you certain there isn’t something about how the plugin is written that is causing the issue? (It looks like maybe the plugin is asking to run under a different account context than the rest.)

    * The plugin never really quite worked perfectly with Windows Authentication to begin with (the test files never match). Do you think there may be a fundamental problem, going even farther back, that needs to be addressed to make this plugin conform to the requirements needed for use with Windows Authentication? Again, other plugins manage to work fine with WA.

    Thanks for a really cool plugin and for your help in the community; I hope I can get it working.

    Thread Starter ultradust

    (@ultradust)

    OK, I spent quite a bit of time attempting to locate the cause of the errors. The server configuration has no known issues. It is set up properly for use with Windows Authentication and all other plugins and platforms (including Magento) work with no problems. In general, I am not seeing these 500 errors except when using the WP Super Cache plugin.

    I did a comprehensive test on various versions of PHP. Given the server configuration, here are the results:

    PHP 5.3.6 and older – WP Super Cache works as expected (except that the test results don’t match) while using Windows Authentication.

    PHP 5.3.7 and newer – WP Super Cache fails with 500 errors while using Windows Authentication.

    It looks like something changed from underneath WP Super Cache in PHP to cause this major problem.

    Thread Starter ultradust

    (@ultradust)

    To be specific: The plugin was throwing 500 errors when attempting to view/change settings, etc. It wasn’t usable at all. I briefly turned off Windows Authentication and hit the pages again, and they worked (I assume that the various changes/files required were performed while authentication was off). However, when I turn authentication back on, I get 500 errors. For example, when trying to use the “Test Cache” feature, I get this:

    ————————————————————–
    HTTP Error 500.0 – Internal Server Error
    C:\PHP\php-cgi.exe – The FastCGI process exited unexpectedly
    Detailed Error Information
    Module FastCgiModule
    Notification ExecuteRequestHandler
    Handler PHP via FastCGI
    Error Code 0xc0000005
    Requested URL http://domain.com:80/wp-admin/options-general.php?page=wpsupercache&tab=easy
    Physical Path C:\inetpub\wwwroot\sites\domain\staging\wp-admin\options-general.php
    Logon Method Negotiate
    Logon User BC1\adminuser
    Most likely causes:
    IIS received the request; however, an internal error occurred during the processing of the request. The root cause of this error depends on which module handles the request and what was happening in the worker process when this error occurred.
    IIS was not able to access the web.config file for the Web site or application. This can occur if the NTFS permissions are set incorrectly.
    IIS was not able to process configuration for the Web site or application.
    The authenticated user does not have permission to use this DLL.
    The request is mapped to a managed handler but the .NET Extensibility Feature is not installed.
    Things you can try:
    Ensure that the NTFS permissions for the web.config file are correct and allow access to the Web server’s machine account.
    Check the event logs to see if any additional information was logged.
    Verify the permissions for the DLL.
    Install the .NET Extensibility feature if the request is mapped to a managed handler.
    Create a tracing rule to track failed requests for this HTTP status code. For more information about creating a tracing rule for failed requests, click here.
    Links and More Information
    This error means that there was a problem while processing the request. The request was received by the Web server, but during processing a fatal error occurred, causing the 500 error.
    View more information »

    Microsoft Knowledge Base Articles:

    294807
    ————————————————————–

    When I turn on error logging and PHP errors, nothing specific is provided via the error. I only get generic 500 errors.

    Thread Starter ultradust

    (@ultradust)

    Hi donncha – thanks for your reply.

    Manually testing, the timestamps are the same.

    However, when I run the test, the two .html files generated in the cache folder themselves basically contain an error report instead of pages.

    Are you suggesting that the process that WP SC runs to do actual caching is fundamentally different than the one used to generate the test files, such that the caching works fine even when the test fails due to failing authorization? How can I test this to be sure?

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