camya

Strange. I can’t find a field to add CSS IDs or classes. The only field to add text is the “Exclude CSS from Autoptimize:” field. (A comma-separated list of “scripts”)

I first added “#syntax-highlighting-code-block-css”, and then “.hljs” to this field and hit empty cache.

The placeholder is still visible in both tests.

The unminified markup of the “Syntax-highlighting Code Block Plugin” looks like this.

<pre class="wp-block-code">
    <link
        rel="stylesheet"
        id="syntax-highlighting-code-block-css"
        href="/wp-content/plugins/syntax-highlighting-code-block/vendor/scrivo/highlight-php/styles/default.css?ver=1596185250"
        type="text/css"
        media="all"
    >
    <style>.wp-block-code {
        border: 0;
        padding: 0;
    }
    
    .wp-block-code > div {
        overflow: auto;
    }
    
    .hljs {
        box-sizing: border-box;
    }
    
    .hljs.shcb-code-table {
        display: table;
        width: 100%;
    }
    
    .hljs.shcb-code-table > .shcb-loc {
        color: inherit;
        display: table-row;
        width: 100%;
    }
    
    .hljs.shcb-code-table .shcb-loc > span {
        display: table-cell;
    }
    
    .wp-block-code code.hljs:not(.shcb-wrap-lines) {
        white-space: pre;
    }
    
    .wp-block-code code.hljs.shcb-wrap-lines {
        white-space: pre-wrap;
    }
    
    .hljs.shcb-line-numbers {
        border-spacing: 0;
        counter-reset: line;
    }
    
    .hljs.shcb-line-numbers > .shcb-loc {
        counter-increment: line;
    }
    
    .hljs.shcb-line-numbers .shcb-loc > span {
        padding-left: 0.75em;
    }
    
    .hljs.shcb-line-numbers .shcb-loc::before {
        border-right: 1px solid #ddd;
        content: counter(line);
        display: table-cell;
        padding: 0 0.75em;
        text-align: right;
        -webkit-user-select: none;
        -moz-user-select: none;
        -ms-user-select: none;
        user-select: none;
        white-space: nowrap;
        width: 1%;
    }
    </style>
    <style>.hljs > mark.shcb-loc {
        background-color: #ddf6ff;
    }</style>
    <div>
        <code class="hljs language-apache shcb-code-table shcb-line-numbers"><span class="shcb-loc"><span><span class="hljs-attribute"><span class="hljs-nomarkup">RewriteEngine</span></span> <span class="hljs-literal">On</span></span></span>
            <mark class="shcb-loc"><span><span class="hljs-attribute"><span class="hljs-nomarkup">RewriteCond</span></span> <span class="hljs-variable">%{HTTP:Custom-Access-Header}</span> !^REQUIRED_ACCESS_STRING$</span></mark>
            <span class="shcb-loc"><span><span class="hljs-attribute"><span class="hljs-nomarkup">RewriteRule</span></span> ^ -<span class="hljs-meta"> [F]</span></span></span>
        </code>
    </div>
</pre>

• This reply was modified 5 years, 9 months ago by camya.

Found an option in Autoptimize to fix this for me. I activated the following option in the “Autoptimize Settings” screen:

CSS Options -> Also aggregate inline CSS? “Yes”

I’m not sure, if this is activated by default in Autoptimize.

Maybe you can add an FAQ entry for Autoptimize.

Thank you for your great plugin.

Hi,

the warnings are still present in my debug.log. I saw, that the file() function calls are silenced by @. Strange, that I still get the warnings in the log.

Our live enviroment runs on a Linux server with a litespeed webserver.

wp litespeed-purge url …

The “litespeed-purge url” command runs just fine. The Debug url looks correct.

Debug (bootstrap): Running command: litespeed-purge url (0.968s)
Debug: url is https://www.PROJECT-DOMAIN.com/countdown/ (0.977s)
Success: Purged the url!

wp litespeed-purge all

Very strange. Instead of calling some internal function to purge all cached data, the /wp-admin/admin-ajax.php is executed as a HTTP request.

Is it not better to not use “admin-ajax.php” from the commandline in this case?

In our case, the /wp-admin/ path is special protected to avoid unallowed access from the frontend.

Debug (bootstrap): Running command: litespeed-purge all (1.841s)
Debug: URL is https://www.PROJECT-DOMAIN.com/wp-admin/admin-ajax.php (1.841s)
Error: Something went wrong! Got 404

Thank you for your time. This was indeed the problem. Awesome plugin btw. 🙂

Hi qtwrk,

I found a bug in the _htaccess_search() method which could be fixed using wp_normalize_path(). After this fix, the plugin works on Windows systems.

The _htaccess_search() function in LiteSpeed Cache tests, if the $star_path equals the $_SERVER[ ‘DOCUMENT_ROOT’ ]. Unfortunately the path separators are different for both paths on Windows systems. (Backslashes vs Slashes). The fix is to use the WordPress function wp_normalize_path(). This will normalize the paths and the condition will match.

Code on Github (_htaccess_search() – Line 194)

wp_normalize_path() modification:

// 2020-05-15 - CAMYA - Normalize start_path and DOCUMENT_ROOT (Windows fix)
if ( ! empty( $_SERVER[ 'DOCUMENT_ROOT' ] ) && wp_normalize_path($start_path) === wp_normalize_path($_SERVER[ 'DOCUMENT_ROOT' ]) ) {
    return false ;
}

Another problem is the root folder, if $_SERVER[ ‘DOCUMENT_ROOT’ ] is not set. I guess, the function is also used from the WP-CLI. (Haven’t checked this by now).
My fix is to store the previous folder into a variable and check, if we reached the root folder. (old folder === new folder)

Here the complete modification:

private function _htaccess_search( $start_path )
{
	while ( ! file_exists( $start_path . '/.htaccess' ) ) {

		if ( $start_path === '/' || ! $start_path) {
			return false ;
		}

		// 2020-05-15 - CAMYA - Normalize start_path and DOCUMENT_ROOT (Windows fix)
		if ( ! empty( $_SERVER[ 'DOCUMENT_ROOT' ] ) && wp_normalize_path($start_path) === wp_normalize_path($_SERVER[ 'DOCUMENT_ROOT' ]) ) {
			return false ;
		}

		// 2020-05-15 - CAMYA - Set filesystem root check helper variable (Windows fix)
		if (!isset($start_path_before)) {
			$start_path_before = $start_path;
		}

		$start_path = dirname( $start_path ) ;

		// 2020-05-15 - CAMYA - Is this the filesystem root folder? (Windows fix)
		if ($start_path_before === $start_path) {
			return false;
		}
		// 2020-05-15 - CAMYA - Update path (Windows fix)
		$start_path_before = $start_path;

	}

	return $start_path ;
}

I hope, it’s possible to add the wp_normalize_path() in the near future, because this will make the plugin work for many more people.

Best,
Andreas

• This reply was modified 6 years ago by camya.