Forum Replies Created
It’s not a setting you missed, but it may be that your server is not properly configured to work with it. I tried to see who your host is, but WhoIsHostingThis says ‘Yahoo’ and I don’t think they have WP hosting… Could be wrong. But that does suggest the issue is in the server.
This is a little technical, and if you’re not the server-admin kick them the link – https://github.com/Ipstenu/varnish-http-purge/wiki/varnish
The tl;dr explanation is that in order to do a ‘full’ purge, we have to send a special message (via a request method) to Varnish. But if Varnish isn’t ‘taught’ what to do when it gets that message, it cannot do a full purge.
By default, the code sends a request method of PURGE. When you want a full purge, we send that message with an extra “http.X-Purge-Method” of regex, which then kicks off the flush.
You can see a functional example of the purge calls for Varnish here – https://github.com/Ipstenu/varnish-http-purge/wiki/purge.vcl
Likely the issue is your server doesn’t have the regex part set up, since the per-page purge works.
We are allowing your final comment to stand as an example to others.
This is not how someone has a civil disagreement.
The plugin was spamming users with Pro ads on every back end admin page. My site was not hacked.
It’s not spamming. It’s a single promotion in a meta-box on posts/pages you edit.
I understand why you feel it’s spam, but at this time it is not considered a reason to remove or even warn a plugin concerning the use. If that changes, we will post on make/plugins so everyone knows.
Those two slugs are not allowed. A slug cannot contain the word wordpress or the name of another product. Both are in violation.
And, as we said, we have retroactively allowed both in as we have no way to change their permalinks without breaking the plugin for the users. If either trademark owner (WordPress or Google) rescinds the permission we have to allow those, we would be forced to close them. Thankfully they recognize the negative impact on the community and have not done so.
I am setting your account to suspended, which prohibits you from using the forums, submitting plugins/themes, or participating in conversations in trac.
Do not make a new account. It’s very clear you’ve allowed your anger to consume you and refuse to hear any explanations or opinions other than your own.
We (collectively) wish you the best of luck in your future endeavors.
PS: Your claim here:
Looks like one of your updates did not remove the wordpress-seo (illegal name) directory when you changed the plugin slug.
is due to a misunderstanding on your part. This plugin did not, and cannot, change it’s slug. So if there was a wordpress-seo folder on your site, someone installed it. If it was inside MonsterInsights, then Jan is right and you were likely hacked.
- This reply was modified 2 days, 22 hours ago by Ipstenu (Mika Epstein).
@wpissuesreports You are not shadow-banned, you are being flagged for moderation following your behavior.
If you feel you have a legitimate complaint about this plugin, please contact
However since your last reply involved you saying “Fuck wporg.ibadboy.net is pathetic. You people are useless.” your account will remain on moderation. If you cannot have a civil conversation, you will not be permitted to use our forums.
For the record, the url
wordpress-seois permitted because it literally cannot be edited. The same goes for
google-analytics-for-wordpress. If we could change them, we would. It would spare us all a lot of headaches and misundertsanding.
And while you may hate the meta-box that recommends you pay for a pro version, it is not actually a violation at this time, since it’s not persistent (meaning it’s not displayed 100% of the time, only when you’re editing posts where it might be available) nor is it intrusive (you can minimize the meta-box). Is it annoying? Yeah, and I don’t personally like it either, but it doesn’t prevent me from doing anything.
@stevejburge What you just asked the OP to do is actually extortion. Telling someone you will ONLY help them if they edit their review is not okay. Please never do that again.
@imincognito Your claim of ‘sluggish’ support is very odd. Taking 48 hours, or even a whole week, to debug something and get back to you is not uncommon. I get why you’re upset about it, but it’s a lot easier to answer pre-sales questions than it is to debug and determine what’s wrong with something. Unless they have a public SLA that says ‘we respond within 4 hours’ (they don’t), then it’s unreasonable to expect immediate service.
Both of you need to calm down, and are being flagged for forum moderation going forward. This means all your posts will need to be approved by a moderator.
WordPress doesn’t alert like that. This sounds like your Acronis security app doesn’t know how to handle a WP upgrade to a beta version which is pretty common. They don’t lock things in until closer to go-live.Forum: Plugins
In reply to: [Ban Hammer] Feature request: Contact Form 7 integration
I have not considered expanding this to handle contact forms, since each one is incredibly unique.
There are plugins like https://wporg.ibadboy.net/plugins/block-domain-email-addresses-for-contact-form-7/ (which I’ve never used) which can do it. You may be able to hook this plugin into theirs, but it would be custom.
That said… I was pretty sure CF7 actually uses the WordPress block-list natively.Forum: Plugins
In reply to: [Recently Registered] Suggestion: Run on backend only?
Sure! That’s a great idea!
Probably should also change
add_action( 'init', array( &$this, 'init' ) );to admin_init 😀
I’m afraid there’s not a whole lot I can do but guess, as it would involve having to log in to your server and understanding how your specific host handled nginx caching :/ Which is well beyond the scope of what any free plugin can offer.
So the MOST likely reasons are:
- The implementation of Nginx is NOT configured to respect the curl PURGE request – your host is the only one who can answer that
- The location of your nginx cache is not localhost, but some other server – your host can tell you that as well, and if so, you can change the IP address in the plugin settings
However, the major flaw I find with Nginx is that there’s not really a built-in way to monitor commands sent to it like Varnish has. There are add-ons but your host would have to have implemented them. If they have, then you can ask for help checking if the PURGE command is being passed on to them. And if THAT is the case, then it’s likely issue #1.
That may mean your configuration of the NGINX cache isn’t set up in a wayt that works with the plugin.
From the FAQ:
Does this work with Nginx caching?
It can, if you’ve configured Nginx caching to respect the curl PURGE request. If this doesn’t work, try setting your Varnish IP to localhost as Nginx requires a service control installed for the IP address to work.
@jeremiva So. What company/group owns ‘WordPress Pro’ then? If it’s wporg.ibadboy.net core devs, then it’s not going to happen since they don’t have access to the features/resources/servers that Automattic does. If it’s WordPress.COM then it’s Automattic, and they would (rightly) get blasted for ‘taking WordPress as a name’ which is not their place and they know it.
Which is why it’s called Jetpack 🙂
It’s an interesting idea to combine every feature in WordPress COM’s ‘Pro’ offering, but looking at https://wordpress.com/pricing/ … Pro is just the same as self-hosting.
The rest (Oauth, data building) can’t be auto-included since people have different requirements. Same as caching. We can do some basics, but since people need different things, we all choose to leave it extendable 🙂
@062785-1 I truely believe you had a bad experience, and I empathize with that. There isn’t a single host on the planet that is perfect for everyone’s use case, and sadly that may mean your unique configuration wasn’t great for DreamPress.
It’s the same as ‘not every car is perfect foreveryone’ 🙂 They all do the same general thing, right? But we all drive differently. So it’s okay that you were unable to get what you needed.
But I try to refrain from blanket statements like “Host X is bad for Y” since really it’s more complex than that.
I do wish you the best of luck.
I did. I’m telling you if you used DH (and note that the 11th is 8 days ago, not 3) it’s not listed in your account anymore. Which would be super weird weird, as we do track all of that.
Dreampress cannot run Woocommerce as fast with their system.
Without being able to see your site on DP, obviously I cannot speak for that, but generally this isn’t the case. The only time I’ve seen it be like that is if you’re putting down something to ‘bust’ cache on every page. PHP Sessions, or cookies, can do that when they’re not used properly. Generally that relates to your theme more than Woo, though (as Woo noted above — that’s why they said to test on Storefront Theme).
Varnish caches, and there should be a Proxy Cache Purge plugin to flush the pages, but that’s not related to this.
If you run
curl -I URL
you will see this:
HTTP/2 200 server: nginx date: Tue, 19 Apr 2022 15:46:25 GMT content-type: text/html; charset=UTF-8 vary: Accept-Encoding x-cache-handler: cache-enabler-engine x-cache-nxaccel: BYPASS
But if you run on any DreamPress powered site, you’ll see a lot more, including the all important
I checked your domain, as I work at DreamHost, and it’s not on DreamPress so you’re not using Varnish. In fact, your domain’s never been on DreamPress (we keep a record as people upgrade/downgrade and that helps us debug). In fact… it looks like you don’t actually host on DreamHost at all anymore. The last record we have of this domain being hosted on DH says you were on a VPS (not DreamPress) and it was closed on the 11th of April.
Checking WHOIS, your nameservers are all nexcess.net (Liquidweb) so you may need to ask them about caching.
A moment of thought… When you tried the manual curl, did you do it from your own laptop or from the server? Most servers are set up to ignore those from outside the server to prevent some jerk from DDoSing your box.
So, is your advice to contact DreamHost’s support?
In this case, yes because I think the fastest fix would be to tell DH support “I need ALL pages with “call_custom_simple_rss” in them to NEVER be cached.”
The best idea I have right now is there’s something about the amount of variables in the URL that’s somehow conflicting with an aspect of Varnish so it doesn’t understand what to do when you add the page in.
Is there a snippet that I can add to my functions.php to schedule a full site purge?
Not easily, by design. It can get really expensive (server processing wise) and slow things down if you run it too often.
If that’s really what you wanted to do, I would recommend making a real cron job instead and run
curl -X PURGE "https://22.214.171.124/*" -H "host:www.example.com"directly.
I would NOT recommend running a cron to flush the whole site more than once an hour, since then you just have a negative return on caching in the first place.
If the curl -X didn’t work, then it’s not the plugin. Seriously, that’s really all the plugin is doing.
Also it being cachable isn’t the issue, it’s the cache not clearing.
But… looking at your example of the headers, notice “age: 5”? That means the page is 5 seconds old.
So that actually looks like it DID purge, and you’re on a new version.