hki429

The issue was solved, I suspect it occurred because I also included the [your-name] and [your-email] in the message body. That might have confused HelpScout.

It all works fine now. ??

Those two little files are still loaded on every page for me on WP 4.1.1 with Rublon 2.1.20. Do I perhaps need to change a setting or dequeue these files manually? In the latter case, how to enqueue them conditionally on the wp-login.php page?

Thanks,

Ah, the cookies for rublon.com (and code.rublon.com) were auto-blocked by Firefox. Now that I’ve allowed them, I’m not redirected anymore (although I did need to authenticate again).

Sorry, should have checked my browser settings much sooner.

Thanks for responding.

When I click on the ‘Log in’ button on wp-login.php, I’m redirected to https://wordpress.rublon.com/.

What exactly happens is this:
https://dl.dropboxusercontent.com/u/78986515/rublon_redirect_scr.14-04-2015%2013.46.11.png

As the image shows, wp-login.php calls code.rublon.com for authentication, which however issues a redirect (302) to rublon.com, which redirects me to the wordpress.rublon.com webpage.

Thanks,

Now that the website is up again, I still cannot login to my WordPress: after submitting the correct username/password, the plugin redirects me to https://wordpress.rublon.com/ instead of /wp-admin/.

Yesterday, before the downtime, everything went okay and I had no trouble logging in (I didn’t change things on my end). What can I do to be able to access /wp-admin/ again?

After a few hours Rublon is still down, for me, the pingtests, and isitdownrightnow.com. Why haven’t this been fixed?

Same here with WP 4.1.1. and plugin version 2.2.

If I set my custom login URL to something like ‘abc’, accessing mysite.com/login will redirect the visitor to mysite.com/abc, defeating the purpose of “hiding” the wp-login.php form.

More info:

* There are no errors in the PHP error_log file.

* The error is triggered by WordPress executing its cron job, which as I understand happens every so often when a new page view is registered (so not on a schedule).

* My permalinks are: /%category%/%postname%/

* The error in the debug log seems to be triggered by this line (on GitHub). But commenting out that line does not let the operation succeed (which makes sense; otherwise it would be an empty error check).

* As mentioned, my webhost couldn’t find errors on their side, suggesting that it is caused by the plugin.

Do you might have CloudFlare’s minify HTML option enabled? That option strips comments from the HTML source, and so WP Super Cache timestamps cannot be found then.

Have you tried other settings, such as enabling ‘Compress pages so they’re served more quickly to visitors’ (for the gzip), enabling the preloader, and unchecking the ‘late init’ option?

Your load time did increase with 1.2 seconds, so the plugin does help somewhat for your. A large page size is probably due to a lot of images or javascript, and that’s not something that WP Super Cache improves (as I understand it).

It does not work on multisite as is,

Ah I have a single site, so that might explain it. Definitely something to look into then by the developer.

Good that you have it working.

It doesn’t work for me on WP 4.1: the prime cache option doesn’t generate (often enough) new pages, and I end up with only .old files. So each time a visitor requests a page, a new version needs to be created on the spot.

(I didn’t vote that W3TC doesn’t work, btw).

Not for me on WP 4.1 and WP Super Cache 1.4.2.

Does it still not work for you?

The ‘Preload’ function will automatically generate pages to serve to your visitors based on your set time interval. This feature is already based on a WordPress cron job.

Or do you mean another way to automatically generate pages?

With the ‘number of requests’, do you mean the number of HTTP request as reported in a PageSpeed test? Those are not expected to change with WP Super Cache, as I understand it.

And if you already had enabled gzip compression before enabling WP Super Cache (for example through your htaccess file), then the PageSpeed page size would also not change, as far as I’m aware of.