Exavior

We don’t need the functionality of the pro version of the plugin, but we would gladly buy a copy just for the support.

We’ve been working with a team of developers to attack this from multiple angles, and our best guess is that this issue is with the plugin.

I’ve tried switching from the “template_redirect” action to the “init” action, but that does not appear to have had any impact on the number of Pretty Link redirects that have failed to be processed by the “add_filter” for “prli_target_url”

We can think of no scenario where the “add_filter” would fail to fire, and due to the infrequency of occurrence (and apparent tie to load) we have been unable to replicate or test against this issue.

As this issue is beyond pressing and it’s been multiple days with no response I’ve been looking for other ways to reach out to you, but have had no luck (the one contact form I found says not to request support so I’m doing my best to respect that).

I’ve spent the last week focused on this issue all day every day (often until after midnight) including weekends and have had little to no progress. To make matters worse we are about to head into a 3 day weekend, so we are basically in a perfect storm scenario.

Some of our campaigns are running 200,000+ clicks a day now through this plugin and nothing we have been able to do on our end has reduced the % of requests that fail to be processed by add_filter/prli_target_url

I can not stress how serious this issue is. I would love for someone from Pretty Link to help, as our best guess is that it’s a problem with the plugin when used at higher volume.

We don’t appear to have any other way to contact you for support.

Please, please help.

We have since determined that this issue is not with the new WP 4.5.3 release. But we’ve found that when the Pretty Link is executed ~70,000 per day the error rate of it not processing our “add_filter” for prli_target_url is ~1.5%

Can you think of any reason the code would not process at those volumes?

When we were only seeing ~5,000 clicks per day the error rate was significantly lower at ~0.5%

It’s interesting that the error rate dropped so much based on the volume of clicks, which would suggest server load is a factor in the “add_filter” processing.

Comments are enabled, and when the posts are viewed from within wordpress, commenting works fine.

We do not require users to register, but they do have to enter a valid email address if they are not registered.

When I view the external page while logged in, everything looks fine… it recognizes that I am logged in, etc.

But when I attempt to display the comment form using the normal comments_template() method, I get the “Comments are closed.” message.

If I manually include the contents of the comments template, and remove the check for comment status, everything looks fine… but when I attempt to post, I am redirected to an old blog post for some odd reason.

Here is a test page.

https://www.theavclub.tv/testComments.php?post=2109

On that page, the comment form is first manually included (by copying the contents of the comments template) Below that, you will see the “Comments are closed.” message, that is generated when I use the comments_template() function.

Pretty please?

Anyone?

The message I get when trying to display the “comments_template();” is “Comments are closed.”

I am having the same issue as well, and I also require the podpress plugin to be active.

Anyone have any luck resolving this issue yet?

Little help?

Please?

Still no luck with this issue.

Can anyone help?

Thanks!

/Chris

You can, you just need to open up that image in an editor, and darkening it should be quite easy.