Milan Dini?

@draganela I have reviewed and looks like fix was already in a latest build, it’s strange that you get this error. Can you please reinstall WP 5.9.3 and let me know what happens? That’s Поново постави изда?е 5.9.3-sr_RS button.

Of course, don’t forget to make a backup!

There was a bug in translation of a string. It was fixed but translation files aren’t build. I’ll see when I can rebuild them.

Both WooCommerce Subscriptions and WooCommerce Blocks got new versions. When both are at latest version, there is this error. I can also reproduce it. So problem is definitely with your plugins, I cannot investigate what change caused this.

If it helps, WooCommerce 5.6.0 is active where I reproduced it. In another thread, it was reported that error is gone when WooCommerce is updated to the latest version. I cannot try that at the moment, but in any case you should fix this bug.

I don’t know about plugin in topic, but just to note since it might help you, I made this plugin to solve searching for any type of query against any type of script used: https://www.ads-software.com/plugins/better-serbian-search/

That theme is on GitHub, not on www.ads-software.com Theme Repository. By default, commonWP will not try to use /gh path unless theme/plugin mentions its GitHub repository details by supporting GitHub Updater.

However, there are various filters in place that should help. In this case, this snippet looks like it should be most helpful:

add_filter( 'commonwp_theme_from_slug', function( $data, $slug ) {
	if ( 'Genesis Sample' == $data['data']->get( 'Name' ) ) {
		// Get headers property of WP_Theme instance.
		$headers = ( new ReflectionClass( get_class( $data['data'] ) ) )->getProperty( 'headers' );

		// Set that property as accessible to be able to read it.
		$headers->setAccessible( true );

		// Get property value by passing WP_Theme instance again.
		$value = $headers->getValue( $data['data'] );

		$value['GitHub Theme URI'] = 'https://github.com/studiopress/genesis-sample';

		$headers->setValue( $data['data'], $value );
	}

	return $data;
}, 10, 2 );

What this snippet does is it adds GitHub repository details to the theme as if the theme supported GitHub Updater.

Note that you should clean your commonWP cache before it starts to work.

This is not supported because of the way both jsDelivr and commonWP work.

First, that second URL is for development version in master/trunk. It may be different even with latest stable version, not to mention older.

Next, it is not permanent, meaning we can’t use comparison, and Subresource Integrity (SRI). jsDelivr advises to not use SRI with such URLs.

If you are concerned that URL may expose version that you are using and that isn’t stable, there. are filters that prevent that and section with more explanation.

There is probably conflict with something here. Can you tell me version of MainWP Child you are using?

Hi @benz1, I am very sorry for late reply, I wanted to write detailed answer but didn’t find time for it.

What you are saying shouldn’t happen. I don’t say that all sites will always be faster, but even when they are slower, other metrics should increase (Time to Start Render, Time to Interactive, Time to Visually Complete, Fully Loaded…), not Time to First Byte.

Reason for this is how commonWP works and what it can affect. On regular requests, it just loads its cache, which is single option field (on single site installation this is already loaded with wp_load_alloptions(), on multisite this does makes new database query but that query is very simple; this is assuming that no object cache is enabled, in that case there will be no database queries at all), then for each script and style does simple assigning in case that script/style is in cache. All other stuff that requires more PHP resources is happening in background processes and won’t be seen by visitors. So, generating page on the server is almost the same, it has minor differences.

When commonWP offloads local files to jsDelivr, it should only affect the way browser loads HTML content and those files. There are a lot of variables that can affect: where is visitor located related to site server and to jsDelivr POP, what is connectivity to either, what protocol is either using, what compression is either using, how fast is site server, how many files page is using, what is distribution of used files (head, footer, above the fold…), in case jsDelivr is used, is any file already cached by browser, etc.

Another thing to consider is if site uses page cache. There is possibility that you are hitting site’s page just in time when it has empty page cache that’s needed to be regenerated, and depending on number of files your site uses it may take even longer to have fully active commonWP because both commonWP’s cache must be full and generated page cache must be with full commonWP’s cache.

Hey guys, I committed changes for this in separate branch on GitHub and you are welcome to test and report any issues. If you don’t use git or Composer versions, just replace content of /inc/Process.php file with one from here (you can do this via built-in plugin editor).

Then, no matter how you start to use this, you must enable this optional feature. It follows approach I already used in commonWP, which is using WordPress hooks, not constants. You need one liner whenever you save custom code:

add_filter( 'commonwp_use_dynamically_minified', '__return_true' );

You can make custom callback that accepts second parameter, object of Process class so you can fine-tune it per file.

So, how this works:

• At begging, everything works as usual, so original file must be exists and must be equal both locally and remotely, and standard logic and hooks is used.
• Then, after standard processing is completed, method that tries to use minified file is used:
• It checks if SCRIPT_DEBUG constant is true, skip in that case.
• It checks if true is passed to commonwp_use_dynamically_minified filter, because this is optional.
• It checks if file already doesn’t end with .min.js for scripts or .min.css for styles.
• It checks if dynamically minified remote file exists (returns 200 status header).
• It checks that bytes size of remote file is lower that bytes size of original, local file. (Without any compression taken into account.)
• It checks if jsDelivr says that it skipped minification for file.

Word of caution here: even though bytes size of dynamically minified file is lower, for small files (1-2KB or less) it is possible that after compression is applied (brotli, gzip), original unminified file is actually smaller than minified one. You should test and see what are actual results with files you use. (This is simple: in a new browser tab, open Networks tab in Developer Tools, open minified and unminified file, do force refresh, and look at Transferred and Size columns.)

Hi all, thanks for your suggestion and sorry for late reply, I needed some time to write detailed explanation, and to think about pros and cons and possible implementation.

First, note that this feature wasn’t there during development of commonWP, it was enabled just last week.

There are some things to consider. Like I wrote when explaining how plugin works in its READMEs, it compares local file and remote file (file on jsDelivr) if they are identical. When there is minified file only on jsDelivr, there can’t be comparison because there is no local minified file.

Because of the way automatic minification on jsDelivr works, minified file can be larger than original in some cases. For example, files might not show in their name that they are already minified. jsDelivr will insert its header and that will make new file bigger. Example: original, automatically minified. Or, for JavaScript files, jsDelivr will insert both header and sourcemaps information, and if original file is already small, minified might be larger. Example: original, automatically minified. Or, when applying compression, for small files difference might be minor, just tens of bytes. Example with brotli: original, automatically minified.

Also, it is recommended by jsDelivr to not use subresource integrity when doing minification.

I can’t enable this by default, because I can’t be 100% sure that automatic minification was successful, I can’t bring users to situations where commonWP causes their sites to stop working correctly even though I know I use technique that might cause this, I advertised and promised that commonWP is as secure as possible (and I really believe that this should be the case).

Personally, I strongly believe that this is kind of things that developers of plugins/themes should already enable. I know that maintaining two copies of files was painful but there are now build tools for help. (Core does this: they only have development copies but they have build tool that does minification for release.)
Developers should be more responsible with things they put on WP.org repositories, things should be optimized for that environment and general, production usage.

All being said, I’ll add experimental feature for this that is optional and disabled by default, and I will ask you to test it for any issues, but note that it might take a while before I finish it.

First reason why I choose jsDelivr is that everything we need (core, plugins, themes files) is automatically there, no need to manually do something, they simply proxy repositories we need. With cdnjs, there are only manually selected JavaScript libraries, it would work with some popular libraries (like jQuery, for example), but not with all other JavaScript/CSS files that can be used by WordPress site, especially those coming from plugins and themes. So there are no really options right now what CDN to use.

Second reason is that it has multi CDN infrastructure (including using Cloudflare, that cdnjs uses), it doesn’t rely on single CDN service, and it has better coverage in some parts of the world (such as China).

I actually tried cdnjs in the past, I wrote about all of this in my blog post.

If things change in the future, I might reconsider my options, but I doubt that it will be in this plugin, I do not want to add settings/options, maybe release a new plugin.

@slllobodan Looks like you aren’t using new version of that plugin (you are using version prior to 1.2 since line 122 is different there). We already fixed incompatibilities with PHP 7 and above last year.

I don’t know where did you get old version, I just checked link you posted and proper plugin version is included.

@1jealeksa You can export any translation (and make POT file from it) from GlotPress. Just export it in PO format, change extension to pot and you can use it elsewhere. You can use any PO file this way.

Само означите да ?е ово пита?е решено (resolved).

Посто?и водич за то: https://sr.www.ads-software.com/latinisation/