Johannes Jülg

Thank 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

can 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.

dont 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.

The 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.