extremecarver

The solution is in wp-admin to go to Appearance –> Menu and create a menu there for your site. That needs to be applied (tick) as menu1 at the bottom of the page.

Atahualpa theme options cannot be used anymore except for styling when it comes to Menu 1.

But yeah I stopped using the plugin because the website would load superslow if the webp/avif image isn’t created yet with nginx. A filescanner and instant conversion of all images would be much better and yeah in general the nginx rules will not work with how this plugin works.

The problem is a wrong error notice. The plugin complains about htaccess not being acessible. And maybe that bug also affects apache installations. Because the plugin only seems to be able to create that file from scratch but not to edit it (if it exists already – e.g. because you changed some options in the plugin or because another plugin created it)

Well after reading through the plugin sourcecode I think this plugin simply cannot search for full name (as in first name / last name). Everything else I can search anyhow – so this pluign has no function. I think maybe some other plugin already makes all database fields of the user searchable. With 20.000 users however I would really need a full name seach – as searching by first name or last name for popular names usually returns 20-30 hits.

For me this plugin doesn’t seem to do anything either – I can anyhow search for first name or for last name – but I cannot search for full name – PHP 8.2 and Wodpress 6.2.2. – searches for full name simply do not return any results.

I didn’t look how this plugin works – but basically it would need to do a sql search on first name, then on last name – then show all results based on user_id that matched both queries – as full name doesn’t exist in wordpress database as a field (plus you would want both first name last name as well as last name first name to work.

yeah I guess I don’t need the rss statistics anyhow. So I will try without any redirect. What I mean is that I wrote a new post on my website – so it should have appeared on follow.it as message to be published – but it didn’t get published. I think that is because my redirect made it impossible for follow.it to access the rss. With the example of the feedburner nginx redirect it is clear that feedburner was excepted – so the feed would be accessible for feedburner without being redirected while anyone else is redirected.

When I reactviated the pluign and applied the redirect – the feed appeared in the messages section on follow.it quite soon. So I just know that the redirect that I used before didn’t work ( I had posted the news post already 30 hours before ). So I’m not sure what was going wrong or not.

I had the redirect active as above but the feed would not be published. So I guess feedburner could not access it. Now I reactivated the plugin so the feed will get published. I guess I would need to know the name of the follow.it user agent to exclude it from being redirected. If that one is redirected on server level – then follow.it will be redirected to it’s own site when trying to access it.

Actually the rewrite didn’t work – waht is the useraged from follow.it? I guess it cannot access it because it’s redirected too.

With feedburner the nginx redirect was as follows:

if ($http_user_agent !~ FeedBurner) { rewrite ^/feed/ https://feeds.feedburner.com/FEEDNAME last;
 }

i will contact you there later, but no I’m not a premium user. Something simply goes wrong there and even fully deleting the settings from wp options and then re configuring via GUI didn’t help.

Newest update still not fixed!

@media screen and (min-width:782px){
#mobmenu-footer li:hover{background-color:;}
#mobmenu-footer li:hover i{color:;}

Version 3.7.28 will fix some further small bugs – e.g. making it 100% W3CSS compatible and removing further CSS problems so 100/100/100/100 in google pagespeed is achievable.

As usually PHP will announce things that break one version ahead – it should even be PHP 9.0 compatible.

Of course – it’s still not compatible with Customizer and likely never will be. But it’s still a great theme – though one that needs a lot of CSS inserts to make it modern/beautiful.

Okay – finally got it working. No I don’t know why putting a dot in front of $ext mattered – and removing the dot from the extension. But now it works. So remove any kind of map craziness, any kind of redirect – and this simple code will work perfectly in all browsers and fall back to original image if it cannot find the newly created one.

It still would save some resources to not copy the original file – and to not do this .pref stuff – it just creates way more data and useless tries on the try_files. As most browsers support avif – and soon likely edge too – and avif in general being the smalles/best compression efficiency first call should go to avif, second to webp and third simply fallback to original image.

yeah maybe create .skipped so it doesnt try again – or handle that via database instead (not sure what is easier/more efficient).

## Add support for "WebP + AVIF converter" WordPress plugin - full fallback in case plugin has error!
	set $ext_avif "avif";
	if ($http_accept !~* "image/avif") {
    set $ext_avif "";
	}
 
	set $ext_webp "webp";
	if ($http_accept !~* "image/webp") {
    set $ext_webp "";
	}
	
	
	location ~ /wp-content/(?<path>.+)\.(?<ext>jpe?g|png|gif|webp)$ {
    add_header Vary Accept;
	add_header Access-Control-Allow-Origin *;
    expires 365d;
    try_files 
	/wp-content/cache/fastware-webpavif/$path.$ext.pref.$ext_avif
	/wp-content/cache/fastware-webpavif/$path.$ext.pref.$ext_webp
	/wp-content/cache/fastware-webpavif/$path.$ext.$ext_avif
	/wp-content/cache/fastware-webpavif/$path.$ext.$ext_webp
	$uri
	=406;
}

I don’t understand why webp is not served in edge on frontend (it is served for images on dashboard). All other browsers are fine and showing avif or webp (if avif not available)

Thinking about performance – this plugin should work a bit differently. First create webp file – if it is bigger than original – delete.

Then create avif file. If bigger than original or eventual webp delete. skip the pref naming stuff. Yeah it’s nice for debugging if something goes wrong – but it simply creates more try_files calls (and each try that does not hit costs performance) and it needs less space on disk.

The curent is really using unneeded resources. Based on the above the easiest is then the following nginx code (and skip all that map stuff, what is that needed for??)

Then a much easier code would be:

   set $ext_webp "";
	if ($http_accept ~* "image/webp") {
    set $ext_webp ".webp"; }
	if ($http_accept ~* "image/avif") {
	set $ext_avif ".avif"; }

	location ~ /wp-content/(?<path>.+)\.(?<ext>jpe?g|png|gif|webp)$ {
    add_header Vary Accept;
    expires 365d;
    try_files 
	/wp-content/cache/fastware-webpavif/$path.$ext$ext_avif
	/wp-content/cache/fastware-webpavif/$path.$ext$ext_webp
	$uri
	=404;
	}

Alternatively this again works fine in Chrome but not in Edge…. It’s even simpler:

	set $ext_avif ".avif";
	if ($http_accept !~* "image/avif") {
    set $ext_avif "";
	}
 
	set $ext_webp ".webp";
	if ($http_accept !~* "image/webp") {
    set $ext_webp "";
	}
	
	
	location ~ /wp-content/(?<path>.+)\.(?<ext>jpe?g|png|gif|webp)$ {
    add_header Vary Accept;
    expires 365d;
    try_files 
	/wp-content/cache/fastware-webpavif/$path.$ext.pref$ext_avif
	/wp-content/cache/fastware-webpavif/$path.$ext.pref$ext_webp
	/wp-content/cache/fastware-webpavif/$path.$ext$ext_avif
	/wp-content/cache/fastware-webpavif/$path.$ext$ext_webp
	/wp-content/cache/fastware-webpavif/$path.$ext
	$uri
	/?fw-webp-avif-ondemand=all;
}

• This reply was modified 1 year, 8 months ago by extremecarver.