Forum Replies Created

Viewing 10 replies - 1 through 10 (of 10 total)
  • Thread Starter Joshua Reynolds

    (@technisolutions)

    Actually, after further research (and despite inconsistent documentation) it looks like with the transition to GA4 you’re now making everything go through the GTM global tag (with 40k of JS overhead) instead of just calling https://www.google-analytics.com/analytics.js directly like we used to with UA so we’re stuck with the extra code for Site Kit’s snippet since you’re being forward compatible.

    It would be appreciated if we aren’t using GA4 or connected to GTM with Site Kit where the old UA snippet would be automatically used. Then we wouldn’t have to use the new gtag just to pull the old UA script (with negative effects) or manually replace the snippet.

    Also, having an alert or something show up in Tag Manager for the same Google account when the global tag is being used to relay UA/GA4 or other things not tied to a GTM account that has containers and all that would help avoid times like my initial confusion.

    Joshua Reynolds

    (@technisolutions)

    #3 & #4 seem to be related since I can’t delete either with a completely different infrastructure. Here’s my errors:
    [STDERR] PHP Warning: Use of undefined constant SERVEBOLT_PATH - assumed 'SERVEBOLT_PATH' (this will throw an Error in a future version of PHP) in /secret/lair/wp-content/plugins/servebolt-optimizer/functions.php on line 959

    [STDERR] PHP Warning: require_once(SERVEBOLT_PATHclasses/nginx-fpc/sb-nginx-fpc-auth-handling.php): failed to open stream: No such file or directory in /secret/lair/wp-content/plugins/servebolt-optimizer/functions.php on line 959

    [STDERR] PHP Fatal error: require_once(): Failed opening required 'SERVEBOLT_PATHclasses/nginx-fpc/sb-nginx-fpc-auth-handling.php' (include_path='.:/usr/share/pear:/usr/share/php') in /secret/lair/wp-content/plugins/servebolt-optimizer/functions.php on line 959

    Yep, I just tested the latest commit out and 99% of the affected settings while network activated are both displaying & working properly. The main Enable Cache setting now always complains about being “overwritten by the primary site setting” but even for the primary site then it can’t be changed and only uses the network admin setting.

    If you had some settings stuck from before this then just toggle them & save then it’ll clear up and work normal afterwards.

    No, you’re not. I’ve had the same issues and more. I reported them to the dev team also and they are looking into it currently.

    Some tips in the meantime:

    • Sometimes it’ll say that its overwritten but then you click away or refresh the page & it actually isn’t so go with whatever it shows you after reloading.
    • Until resolved, make sure to have Cache Wp-Admin OFF under Object Cache Settings since that could potentially make it worse.

    Yeah, I’m also having issues with it hijacking the WooCommerce dashboard as well as certain other WooCommerce pages. No redirects, just loads the same URL but with Bing settings. Same versions as OP.

    To fix:
    Go to WebAdmin Console: Server -> Tuning -> Compressible Types: delete the pre-configured content and leave it empty. The server built-in default will take care of all common compressible types.
    Or directly edit the config file at lsws/conf/httpd_config.xml, search for compressibleTypes, and remove that element.
    Then restart LSWS, it should work.

    For new installs, default values will be handled better in next LSWS release.

    The buffer modification hooks have been added to the API documentation.

    Also, there are lots of settings to customize & limit how the crawler runs.

    Thread Starter Joshua Reynolds

    (@technisolutions)

    Well its about to be production since were in a soft launch for a few more days now.

    Now nowhere in the crawler documentation does it say that is only available for Apache for Linux although the example directory paths imply it a bit. Whether its documented or not, the plugin should be smart enough to check if on Windows & not allow the crawler to be enabled (manually or by cron job) until it is compatible. At first I only noticed the crashes/errors when I got “Your Site is Experiencing a Technical Issue” e-mails from WordPress each time I manually ran the crawler but come to find out when looking at the server logs that the cron job has been running and erroring out a lot. This issue could and should be avoided until ready for WAMP support.

    Thread Starter Joshua Reynolds

    (@technisolutions)

    Well I’ve since moved on to other similar plugins so don’t have it handy for an exact copy of the staging .htaccess file to make sure the top sections were unmodified but I’m certain about this section that was outright removed (except for possibly www at one point or other instead of staging):

    <IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType image/jpg "access 1 year"
    ExpiresByType image/jpeg "access 1 year"
    ExpiresByType image/gif "access 1 year"
    ExpiresByType image/png "access 1 year"
    ExpiresByType text/css "access 1 month"
    ExpiresByType text/html "access 1 month"
    ExpiresByType application/pdf "access 1 month"
    ExpiresByType text/x-javascript "access 1 month"
    ExpiresByType application/x-shockwave-flash "access 1 month"
    ExpiresByType image/x-icon "access 1 year"
    ExpiresDefault "access 1 month"
    </IfModule>
    Options -Indexes
    
    #### Manual additions by J_Rey
    DefaultLanguage en
    
    ### Force HTTPS://WWW and remove trailing / from files ####
    ## Turn on rewrite engine
    RewriteEngine on
    
    # Remove trailing slash from non-filepath urls
    RewriteCond %{REQUEST_URI} /(.+)/$
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^ https://staging.plcsource.com/%1 [R=301,L]
    
    # Include trailing slash on directory 
    RewriteCond %{REQUEST_URI} !(.+)/$
    RewriteCond %{REQUEST_FILENAME} -d
    RewriteRule ^(.+)$ https://staging.plcsource.com/$1/ [R=301,L]
    
    # Force HTTPS and WWW 
    RewriteCond %{HTTP_HOST} !^staging\.(.*)$ [OR,NC]
    RewriteCond %{https} off  
    RewriteRule ^(.*)$ https://staging.plcsource.com/$1 [R=301,L]

    this was immediately after
    # END WordPress

    Its now obvious that another caching plugin didn’t cleanup after itself for the first part so was fine to remove that but with the last part that I (J_Rey) added missing then it caused 502 gateway errors till I added it back as shown above. There were other plugins installed but deactivated at the time (W3TC & possibly others) so wouldn’t change anything while testing your plugin although their section(s) were still there & your plugin added below them but above the WordPress markers.

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