Johannes Jülg
Forum Replies Created
-
Forum: Plugins
In reply to: [Broken Link Checker] No new translation strings are loaded to stableThank you for your answer.
I’m a Geman Polyglots member. No new strings have been added to stable since November 2023 on translate.www.ads-software.com. About 70 strings are not available for stable and users don’t receive these translations.
List sorted by “Date added (original)” for stable (page 1) and trunk (page 7).
No, the update for the free version did not bring any improvement. My wp-admin is locked. It’s not the first untested update…
- This reply was modified 5 months, 2 weeks ago by Johannes Jülg.
Unfortunately this is not grammatically correct either. I’m sorry.
I don’t think this only affects the german language.
How about some logic, so we cover the standard WordPress post types and each individual post type will get the placeholder? That way most of your users will get a 100% correct translation.
unfortunately this is also not 100% correct.
It should be “Seiten-SEO-Einstellungen”, “Beitrags-SEO-Einstellungen” (missing letter highlighted)
Interesting. Thanks.
I didn’t know about this fact.Thanks, it works
thanks for reply and all the hard work
I have moved these phrases to aside and the table of contents to nav.
It seems like space has a higher priority than strip. If there is another tag like ul inside, nav is not ignored.a table of contents for paginated articles could be another example
i would prefer htaccess because it’s faster
if you enforce www or non www it will first enforce this and after that it will redirect to ssl. so it is safer via htaccess, too.if you want to use hsts preload you should redirect to ssl first and then to www or you cant get to the list
https://hstspreload.org/no you dont have to but if you use htaccess and disable it in plugin it will be faster
Please keep in mind that hide backend was changed in 6.3.0
changelog:
Important: The way that Hide Backend functions changes in this release. Previously, if your Hide Backend Login Slug was wplogin, going to example.com/wplogin would result in the URL remaining example.com/wplogin. The new implementation of this feature results in a redirect to a URL that looks as follows: example.com/wp-login.php?itsec-hb-token=wplogin. While this may not be desireable for some users, this change was necessary to fix longstanding compatibility issues with other plugins. Once you access the login page using the Login Slug page, a cookie is set with an expiration time of one hour. As long as the cookie remains, you can access example.com/wp-login.php without having to access the Hide Backend Login Slug first. If you wish to confirm that Hide Backend is working properly on your site, opening up a private browsing window is a quick way to test without having to log out and clear cookies.please have a look at the global settings
Forum: Plugins
In reply to: [Cachify] China user-unavailable Memcached cachecan you please try to change: memcached_pass localhost:11211;
to
memcached_pass 127.0.0.1:11211;This forces IPv4 because some servers that allow ipv4 and ipv6 are configured to bind memcached to ipv4 only.
- This reply was modified 8 years, 1 month ago by Johannes Jülg.
Forum: Plugins
In reply to: [Cachify] htaccess rules for caching on subdomainsdont know your paths on the server but i think it should be:
http only:
# BEGINN CACHIFY <IfModule mod_rewrite.c> # ENGINE ON RewriteEngine On # GZIP FILE <IfModule mod_mime.c> RewriteCond %{REQUEST_URI} /$ RewriteCond %{REQUEST_URI} !^/(wp-admin|wp-content/cache)/.* RewriteCond %{REQUEST_METHOD} !=POST RewriteCond %{QUERY_STRING} ="" RewriteCond %{HTTP_COOKIE} !(wp-postpass|wordpress_logged_in|comment_author)_ RewriteCond %{HTTP:Accept-Encoding} gzip RewriteCond home/www/static1.mydomain.de/wp-content/cache/cachify/%{HTTP_HOST}%{REQUEST_URI}index.html.gz -f RewriteRule ^(.*) /wp-content/cache/cachify/%{HTTP_HOST}%{REQUEST_URI}index.html.gz [L] AddType text/html .gz AddEncoding gzip .gz </IfModule> # HTML FILE RewriteCond %{REQUEST_URI} /$ RewriteCond %{REQUEST_URI} !^/(wp-admin|wp-content/cache)/.* RewriteCond %{REQUEST_METHOD} !=POST RewriteCond %{QUERY_STRING} ="" RewriteCond %{HTTP_COOKIE} !(wp-postpass|wordpress_logged_in|comment_author)_ RewriteCond home/www/static1.mydomain.de/wp-content/cache/cachify/%{HTTP_HOST}%{REQUEST_URI}index.html -f RewriteRule ^(.*) /wp-content/cache/cachify/%{HTTP_HOST}%{REQUEST_URI}index.html [L] </IfModule> # END CACHIFY
https only:
if the website is only accessible via SSL/TLS, you have to edit/wp-content/cache/cachify/%{HTTP_HOST}%{REQUEST_URI}index.html
to
/wp-content/cache/cachify/https-%{HTTP_HOST}%{REQUEST_URI}index.html
- This reply was modified 8 years, 1 month ago by Johannes Jülg.
- This reply was modified 8 years, 1 month ago by Johannes Jülg.
- This reply was modified 8 years, 1 month ago by Johannes Jülg.
- This reply was modified 8 years, 1 month ago by Johannes Jülg.
Forum: Plugins
In reply to: [Cachify] htaccess rules for caching on subdomainsThe URLs are not necessary for the .htaccess file.
You need the local path of your server to wp-content in the .htaccess file.
You can take a look into your wp-config.php if you don’t know the exact paths.If you need some further help please let me know
An updated version with some config hints inside the plugin is planned which will try to specify the paths directly
https://github.com/pluginkollektiv/cachify/pull/69
- This reply was modified 8 years, 1 month ago by Johannes Jülg.