Forum Replies Created
-
Posts
-
Hi Mike,
thanks so much for spending time on this, I really appreciate it.
I added the code to our functions.php but determined that it was never called (I added an HTML comment after the source tag).
Instead the version from the parent theme runs but I’m now pretty sure this is a red-herring for 2 reasons:1. If I modify the return from avia_html5_video_embed to return an empty string I still get HEAD requests in the log.
2. The HEAD requests come in at 45 seconds past the minute which suggest something like wp-cron (we have no Unix cron entry for this).
This may be beyond scope so feel free to close this ticket if so.Thanks again,
akrigaHi Ismael,
many thanks for your response.
I agree, “the server should not should not trigger requests for other formats”. We get 6 requests per second for these other formats from the server and that is the mystery.
I already have something in htaccess to handle these requests once they’re triggered, but thank you anyway. I would rather they not be triggered in the first place.
If you have any ideas of how to trace the source of these requests please let me know otherwise we can close this ticket.best,
AkrigaHi Mike,
thanks for your reply. I agree, yet they they are in the server logs – see my original post. This reinforces my point that these requests are not coming from the browser as it tries to load alternatives.Hi Mike,
many thanks for your response, a couple of points:1/
If it were the user’s own browser making these requests then the IP address of each request would not be that of the server. Instead it would be the user’s own IP address. However, the additional HEAD requests we get are coming from the server’s own IP address.2/
Code inenfold/framework/php/function-set-avia-frontend.phploops through an array of types where the types default is:
function avia_html5_video_embed( $video, $image = '', $types = array( 'webm' => 'type="video/webm"', 'mp4' => 'type="video/mp4"', 'ogv' => 'type="video/ogg"' ),If the filter mentioned in the post I linked to was implemented I think we could solve this.
Best regards,
akrigaHi,
for those interested I’ve done this using wp cli
### 1. Export the widgets from our theme, e.g. from dev
wp option get sidebars_widgets –format=json > /tmp/widgets.txt
wp option get widget_text –format=json –allow-root > /tmp/widget-text### 2. Import them into the target
wp option update sidebars_widgets –format=json < /tmp/widgets.txt
wp option update widget_text –format=json –allow-root < /tmp/widget-textNow menus:
### export menu
wp menu export main-menu –filename=main-menu.json –allow-root### import menu
wp menu import /root/ffc_vhost/main-menu.json –allow-rootBTW you can also export/import the theme settings:
wp option get avia_options_enfold_child –format=json –allow-root > /tmp/enfold-child
wp option update avia_options_enfold_child –format=json –allow-root < /tmp/enfold-childPlease close this ticket.
Hi Victoria,
I’ve tracked this down to Google crawling the theme folder. I’ve disallowed via robots.txt.
You can close the ticket.
Regards,
akrigaHi Victoria,
thanks for your prompt reply. I have unzipped the theme into a new directory on the server then used diff -r to compare the newly unzipped theme files with what we have already. No difference is reported so it seems the files we’re running are the same as those supplied in the theme.Regards,
akrigaThis still seems to be the case, i.e. img tags do not have the srcset attribute added to them if you use the Avia editor.
Is there a date for when this will be fixed please?Regards,
akHi Jordan,
many thanks for your reply. I realise that but the code only exists in the parent theme, are you really suggesting I copy all that code into our child theme’s functions.php? That just moves the exposure. That doesn’t seem right unless I’ve misunderstood?Best regards,
Adrian
