morcth
Forum Replies Created
-
I do see that enabling the floating settings button creates a tab accessible way to reach the pop up.. as would creating a link on any page to enable the popup.
You did hit the nail on the head in your last response though… “The “settings” link is not an anchor, it’s a “<span>” with the link style.”
Is it possible to make the banner “settings” link an anchor instead of span so that it can be reached with tab? Is there a reason that it has to be a span tag?
Thanks so much.
Josh
Correct on the settings link not being an anchor and span links are not keyboard accessible without a tab-index value I believe.
I have not updated the plugin on my site but will try to do so today. I did see that the settings link was not accessible on your site though.
Thanks!
Hi @mooveagency
I just tried on your website and also could not do what we are asking. Yes, the settings popup is tab accessible and before the settings popup shows, we can tab to the accept button… but we can not tab to the settings link in the banner.. so we can never get the settings popup to show with just keyboard.
Does this make sense?
“This website uses cookies to provide you with the best browsing experience. Find out more or adjust your settings.”
I can’t get to the “settings” link… it doesn’t seem to be tab accessible. This basically causes the banner to not be ADA compliant.
Thanks!
@mooveagency – following up here.
Thanks!
Hello,
I am experiencing this issue is well.
The settings screen is tab accessible which is awesome… but you can’t get to the banner itself using tab.
So, if I remove all site cookies and refresh my homepage, the banner shows up on the bottom of my screen.
I can’t tab to a [settings]settings[/settings] link at all and it seems that I can tab to the Accept button but there is nothing that tells me I am on it and then hitting space or enter will accept. Someone using a screen reader can not reach any links in the banner other than the buttons.. so they can not reach a settings pop up… and, there is no visual change to know that one of the buttons are in focus.
Basically, the banner itself is not compliant and a keyboard user can not reach a settings page from it.
Does this make sense?
Thanks!
Josh- This reply was modified 5 years, 2 months ago by morcth.
Also, I got the remove cookies button working (Would still much rather not having to have them hit 2 toggles) and I realize it just removes the current cookies. On page reload, the cookies come back.
I’d like to do it similar to your banner and all other banner plugins… if they turn off tracking, it adds a cookie which stops the other cookies from loading on refreshes or future visits.
OR, being able to add head, boddy and footer code to your banners that can be turned off and on?
Thanks,
JoshAll seems to be working well!
Thanks again!
Ok great… so I don’t have to check if the folder exists… just if the cron does.
Every hour it will run and 99% of the time have nothing to convert and once in a while, due to a new deploy, it will not find the uploads-webpc folder at all and will convert all.
Love it.
Will implement tomorrow and report back.
Thanks!
- This reply was modified 5 years, 8 months ago by morcth.
Sadly, I am the admin.
I just saw this:
add_action(‘init’, function()
{
do_action(‘webpc_regenerate_all’);
});I’m thinking of running a cronjob to check for the uploads-webpc folder every 15 minutes or so. If there, do nothing. If not there, then run the regenerate all action.
So at max, 15 minutes after a new deploy, it will check and see no webp folder and regenerate all.
Can you think of any issues this might cause?
Thanks!
New but connected issue that you can hopefully help with.
So I realized that everytime I deploy a new version, the uploads-webpc folder disappears because the “current” folder is another alias to a new release folder: /srv/www/site.com/releases/20200730120153/web/
So I tried creating the uploads-webpc folder in the shared folder where the uploads folder actually lives. This works fine… all images are correctly converted.
The issue now though is that the uploads folder does not have the long path anymore because no alias’s are being used and the themes and plugins folders do.
New folder structure:
From /srv/www/site.com├── current -> /srv/www/site.com/releases/20200730120153 ├──web ├── app ├── mu-plugins ├── plugins ├── themes ├── uploads -> /srv/www/site.com/shared/uploads ├──shared ├── uploads ├── uploads-webpc ├── uploads ├── srv ├── www ├── site.com ├── releases ├── 20200730120153 --This will always change but maybe can use "current" alias in nginx? ├── web ├── app ├── plugins ├── themes ├── logs ├── releasesSO, we need the server to check /srv/www/site.com/shared for the uploads-webpc folder which is outside the web/app folder and we need to be able to use “current” alias instead of release location as this will change with every new deployment.
Can we use alias path in nginx conf? Am I able to have the try_files statement in nginx check folders outside of the site root? I also did see that there is an “alias” command for nginx conf.
Any help is appreciated.
Thanks!
Done!
Thanks again
I had tried some if statements in the same location block. I was hoping it would be a simple nginx config addition but I am unfamiliar with the format.
I had to change around what you sent a bit but got it working!
Thanks so much for being a freakin genius! Bought you a few cups of coffee.Awesome plugin and easy setup!
Working code below in case it helps anyone!
location ~ /app/(?<dir>plugins|themes)/(?<path>.+)\.(?<ext>jpe?g|png|gif)$ { if ($http_accept !~* "image/webp") { break; } add_header Vary Accept; expires 365d; try_files /app/uploads-webpc/$dir/$path.$ext.webp $uri =404; } location ~ /app/(?<dir>uploads)/(?<path>.+)\.(?<ext>jpe?g|png|gif)$ { if ($http_accept !~* "image/webp") { break; } add_header Vary Accept; expires 365d; try_files /app/uploads-webpc/srv/www/site.com/shared/uploads/$path.$ext.webp $uri =404; }Yes, everything is converted flawlessly. If I have plugins, themes and uploads checked, a themes and plugins folder is correctly in the uploads-webpc folder but there is also an srv folder which should be the uploads folder and that srv folder then goes to www then site.com -> shared and finally uploads. Below, the “current” folder is also an alias to the current release.. the server holds the most recent 4 or 5.
Folder structure after conversion:
from /srv/www/site.com/current/web/
├── app ├── mu-plugins ├── plugins ├── themes ├── uploads -> /srv/www/site.com/shared/uploads ├── uploads-webpc ├── plugins ├── themes ├── srv ├── www ├── site.com ├── shared ├── uploadsAll webp images are correctly in uploads.
So, if I leave your nginx settings from your faq as is, all plugin and theme images work but uploads do not. If I change the try statement and put in /app/uploads-webpc/srv/www/site.com/shared/$path.$ext.webp $uri =404; Uploads work but plugins and themes do not.Thank you for looking into it!
Hello,
I just wanted to check in to see if this was still on track for q1 or will it be delayed?
Thanks!
This does help very much.
Thanks!