Forum Replies Created

Viewing 11 replies - 1 through 11 (of 11 total)
  • Hey Jesse,

    Thanks for letting me know, much appreciated. I will sure give it a try.

    Hi

    How is your sshd configured? Do you use ChrootDirectory option? If you do, how does your FTP_BASE variable in wp-config.php looks like? Also did you set all other variables required for this to work, like:

    FS_METHOD
    FTP_PUBKEY
    FTP_PRIKEY
    FTP_USER
    FTP_HOST

    If you have FTP_CONTENT_DIR and FTP_PLUGIN_DIR variables in wp-config.php, they are not required if both content and plugin directories are under FTP_BASE. They are only required if you move them out of FTP_BASE to some other location. Can you please check all that.

    How did you set your FTP_BASE variable in wp-config.php? I’m asking because you have “ChrootDirectory %h” defined in your sshd_config. So the actual “root” for your user is whatever you defined that user home directory (%h) is. For instance /home/$USER.

    So in your case /home/%USER is actually “/” for your user. So if you defined your FTP_BASE as something like “/home/$USER/sitename/public_html” that is false, and it should only be “/sitename/public_html”.

    Ok, this has nothing to do with persmissions nor anything similar. I have a ChrootDirectory defined in my sshd config for each user which makes /home/user directory their (that user) actual root.

    Setting FTP_BASE to /sitename/htdocs in wp-config.php solves the problem:
    define( ‘FTP_BASE’, ‘/example.com/htdocs/’ );

    And it actually makes sense, system wise.

    OK, let me clarify. My WordPress instances are not “using” webserver/php user like www-data, nobody and similar, but they are running under a dedicated user per instance. So for this example let’s call that user a “user”.

    So, as you can see from my initial post, permissions and ownership are set for “user” and I have configured my WP instances to use ssh2 method where I defined all the required variables for this to work in each instance wp-config.php file. And again as I mentioned, this was working for the past two years and still is working for everything else (plugins/themes/uploads) but not for WP core updates. Issue appeared with the version 5.2.3.

    And to answer your question, yes, permissions and ownership on that file matches to all other WP core files.

    Then yes; neither Apache, nor WordPress are not “aware” Nginx is off-loading SSL traffic, so you need to tell the this is the case. Put the following at the bottom of the wp-config.php file and I think it should solve your issue:

    define(‘FORCE_SSL_ADMIN’, true);
    define(‘FORCE_SSL_LOGIN’, true);
    if ($_SERVER[‘HTTP_X_FORWARDED_PROTO’] == ‘https’)
    $_SERVER[‘HTTPS’]=’on’;

    Hi,

    I see you are using Nginx. Do you use Apache (or any other web server) also behind Nginx? Your issue is looking like you are off-loading your SSL traffic on Nginx and WordPress has no idea about that and is trying to server plain HTTP traffic. Check how you configured your Home and SiteURL values and additionally try to add this to your wp-config.php file:

    if ($_SERVER[‘HTTP_X_FORWARDED_PROTO’] == ‘https’) $_SERVER[‘HTTPS’]=’on’;

    Setting “Failed login Captcha” to 1 and Score to 0.1 for new sites that didn’t receive any traffic yet (ever) along with reCaptcha v3 will work 100% and no errors will happen.

    @shamim51 can you please write this down under “Installation” or “Support” section as it turn out to be very important for new sites (domains).

    You can also write down that users with “old” sites (domains) which received traffic in past will have your plugin work with much more strict settings.

    Hello Marko,

    I found the cause of issue. I have browser caching handled by Nginx and I had these two definitions that were causing files not being reachable:

    try_files /wp-content/cache/page_enhanced/${host}${cache_uri}_index.html $uri $uri/ /index.php?$args;

    and

    # Cache static files for as long as possible
    location ~* .(ogg|ogv|svg|svgz|eot|otf|css|woff|mp4|ttf|js|rss|atom|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {
    expires max; log_not_found off; access_log off;
    }

    I commented out the first line and removed css and js from the second one, and now all is working.

    Hello Marko,

    Here is my master .htaccess file in main docroot:
    ###
    # BEGIN W3TC Page Cache core
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^(.*\/)?w3tc_rewrite_test([0-9]+)/?$ $1?w3tc_rewrite_test=1 [L]
    RewriteCond %{HTTPS} =on
    RewriteRule .* – [E=W3TC_SSL:_ssl]
    RewriteCond %{SERVER_PORT} =443
    RewriteRule .* – [E=W3TC_SSL:_ssl]
    RewriteCond %{HTTP:X-Forwarded-Proto} =https [NC]
    RewriteRule .* – [E=W3TC_SSL:_ssl]
    RewriteCond %{HTTP_COOKIE} w3tc_preview [NC]
    RewriteRule .* – [E=W3TC_PREVIEW:_preview]
    RewriteCond %{REQUEST_METHOD} !=POST
    RewriteCond %{QUERY_STRING} =””
    RewriteCond %{REQUEST_URI} \/$
    RewriteCond %{HTTP_COOKIE} !(comment_author|wp\-postpass|w3tc_logged_out|wordpress_logged_in|wptouch_switch_toggle) [NC]
    RewriteCond “%{DOCUMENT_ROOT}/wp-content/cache/page_enhanced/%{HTTP_HOST}/%{REQUEST_URI}/_index%{ENV:W3TC_SSL}%{ENV:W3TC_PREVIEW}.html” -f
    RewriteRule .* “/wp-content/cache/page_enhanced/%{HTTP_HOST}/%{REQUEST_URI}/_index%{ENV:W3TC_SSL}%{ENV:W3TC_PREVIEW}.html” [L]
    </IfModule>
    # END W3TC Page Cache core
    # BEGIN W3TC CDN
    <FilesMatch “\.(asf|asx|wax|wmv|wmx|avi|bmp|class|divx|doc|docx|eot|exe|gif|gz|gzip|ico|jpg|jpeg|jpe|webp|json|mdb|mid|midi|mov|qt|mp3|m4a|mp4|m4v|mpeg|mpg|mpe|webm|mpp|otf|_otf|odb|odc|odf|odg|odp|ods|odt|ogg|pdf|png|pot|pps|ppt|pptx|ra|ram|svg|svgz|swf|tar|tif|tiff|ttf|ttc|_ttf|wav|wma|wri|woff|woff2|xla|xls|xlsx|xlt|xlw|zip|ASF|ASX|WAX|WMV|WMX|AVI|BMP|CLASS|DIVX|DOC|DOCX|EOT|EXE|GIF|GZ|GZIP|ICO|JPG|JPEG|JPE|WEBP|JSON|MDB|MID|MIDI|MOV|QT|MP3|M4A|MP4|M4V|MPEG|MPG|MPE|WEBM|MPP|OTF|_OTF|ODB|ODC|ODF|ODG|ODP|ODS|ODT|OGG|PDF|PNG|POT|PPS|PPT|PPTX|RA|RAM|SVG|SVGZ|SWF|TAR|TIF|TIFF|TTF|TTC|_TTF|WAV|WMA|WRI|WOFF|WOFF2|XLA|XLS|XLSX|XLT|XLW|ZIP)$”>
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteRule .* – [E=CANONICAL:http://%{HTTP_HOST}%{REQUEST_URI},NE]
    RewriteCond %{HTTPS} =on
    RewriteRule .* – [E=CANONICAL:https://%{HTTP_HOST}%{REQUEST_URI},NE]
    </IfModule>
    <IfModule mod_headers.c>
    Header set Link “<%{CANONICAL}e>; rel=\”canonical\””
    </IfModule>
    </FilesMatch>
    # END W3TC CDN
    # BEGIN Block the include-only files
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^wp-admin/includes/ – [F,L]
    RewriteRule !^wp-includes/ – [S=3]
    RewriteRule ^wp-includes/[^/]+\.php$ – [F,L]
    RewriteRule ^wp-includes/js/tinymce/langs/.+\.php – [F,L]
    RewriteRule ^wp-includes/theme-compat/ – [F,L]
    </IfModule>
    # END Block the include-only files
    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ – [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    </IfModule>

    # END WordPress
    ###

    This is the one in wp-content/cache/minify folder:
    ###
    # BEGIN W3TC Minify cache
    # END W3TC Minify cache
    # BEGIN W3TC Minify core
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /wp-content/cache/minify/
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^(.+\.(css|js))$ /index.php [L]
    </IfModule>
    # END W3TC Minify core
    ###

    I tested the the rewrite rules and they seem to be OK, you can check it here:
    https://htaccess.madewithlove.be?share=fb4d8057-97df-5ca2-ad92-e84ca9808e22

    Also I thought since I have .htaccess files in place, that option +MultiViews is the issue since mod_negotiate gets control before mor_rewrite and matches strict string, but changing option to -MultiViews didn’t help.

    Both .htaccess files are accessible by user running the webserver (Apache 2). If you need more info, please do tell.

    I figured the issue. I’ve set up my custom domain in US region, while I configured my Mailgun plugin to use EU region. As soon as I set the correct region in WP plugin, it started to work. I apologize for raising this issue.

Viewing 11 replies - 1 through 11 (of 11 total)