Forum Replies Created

Viewing 4 replies - 1 through 4 (of 4 total)
  • I am having the exact same problem. Site went down with 500 Internal Server Error due to a truncated entry from iThemes in the .htaccess file (last line just says “Require not i” instead of “Require not ip 000.00.000.00”. iThemes has made our .htaccess file over 400kb in size. Renaming the file and replacing with a blank .htaccess fixed the 500 error, but I share the frustration of the OP about iThemes not having any feature to cull the IPs in .htaccess and prevent the site from crashing like this.

    Thread Starter iburzynski

    (@iburzynski)

    I found the earlier thread by another user who was having the same problem and followed the solution there (setting sharing settings to anyone with the link can view). This fixed the problem and made the files display.

    However this isn’t a satisfactory solution because it means my documents can potentially be accessed by unauthorized people, and some of them contain sensitive information. I am displaying the embedded folders within a password protected intranet site, which authorized users log into using your Google Login plugin.

    I would like for these files to only be accessible to users who they are shared with, but it seems I will have to instruct my users to only use Chrome browser since the plugin is not fully compatible with Firefox. Downgrading file security is a workaround, not an actual solution.

    Thread Starter iburzynski

    (@iburzynski)

    Very strange: when I tried the same in an incognito window and a different browser I did not face this problem. I think it was caused by browser caching.

    Hi gtvracer,

    I think I am dealing with a similar bug in Woocommerce subscriptions.

    At one point renewal was working properly – when the next payment date was reached, a sequence of events would trigger (renewal order created, invoice sent to customer, etc.). For some reason this is no longer happening: instead the next payment date/time for the subscription passes without firing the trigger and then the next payment date shows as a backdate (i.e. “3 hours ago”).

    Is this similar to what you were experiencing? It seems like it is a cron-related bug and possibly it was created by adding another plugin, since it was working fine initially. I’ve been trying to deactivate recently added plugins one by one with no luck so far. I don’t know enough to venture any other solution.

    I urgently need to get this fixed as I’m under a tight deadline and starting to panic! Any help would be much appreciated.

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