Benjamin Pick

Oh your next question will probably be: “when?” – That’s always hard to tell for non-paid work ?? But think in terms of months – subscribe the ajax thread and you’ll be notified.

The mentioned work (https://github.com/yellowtree/geoip-detect/pull/46/files#diff-f03c876c5928000ca61138c1b1b52016) is way more complete than the example you quote. If you use it, change the function names though.

I just decided to implement basic support (server-side) soon, instead of aiming for all-or-nothing and thus not doing it (implementing the shortcodes via AJAX will be tricky!).

Fixed in Github and will be released with the next version. It also deletes the options set in the Database.

Yes this is possible via conditionally showing/hiding text, either via shortcode [geoip_detect2_show_if ...]+33 43 4444...[/geoip_detect2_show_if] or via CSS.

See https://github.com/yellowtree/geoip-detect/wiki/API-Documentation#show-or-hide-content-depending-on-the-location

I have added the subnet feature to the beta version, can you try it, please?

https://github.com/yellowtree/wp-geoip-detect/archive/master.zip

It’s online already …

You were right, sorry for that … I will release a fixed version today.

Hi,

it is difficult to help you if you don’t say what you need ?? It depends. My plugin is mainly aimed at developers, so if you don’t know where to start after reading the documentation, then ultimately you will need to ask a developer about it … But sometimes there are also other friendly users ??

Sounds weird. Yes I will investigate this … Which version of CF 7 are you using?

1. Sounds like a good idea. I never thought a provider would provide so many revers proxies, but in a CDN, this makes sense …

2. The trusted proxies are set in the settings. There is also a debug panel that lists all reverse proxy relevant settings (but currently they are only shown, not changeable there).

Yes indeed, setting subscribers_only: true did the trick …
Thank you!

• This reply was modified 6 years, 3 months ago by Benjamin Pick.

This should also fix the values of [_user_login] and the like.

Yes.

I have updated the gist slightly.

Good point. Well, CSS and JS may change when WordPress, a theme or a plugin is updated – not sure if you have covered this use case yet?

Actually there is a small problem of my current approach of deleting the optimized files as well. In very rare cases the Cache delivered an old HTML, and before the CSS/JS-Files are loaded the cache is purged, and autoptimize changes the filenames if the content has changed, thus the HTML rendered with 404 for CSS/JS. Not good. So actually it would be better to defer the purging of the autoptimizer for some seconds via wp-cron.

Oh actually clearing the cache of this should not be essential, because the filename contains a hash that changes with the content, so new content -> new files. Maybe you just add my gist to your readme for the developer use case.