adrian

https://web.dev/native-lazy-loading/

All I see is this: but it's almost completely hidden until you hover over it. Anyway, as I think we all agree - this is all a PITA and I think we should interrupt the user as little as possible.

I don't see it at all - using Brave Browser, but thanks for pointing out that there is actually something there when it works.

I have also built a site on Knownhost - it's fast enough, but I did come across the nginx reverse proxy errors quite a lot - I think I managed to tweak things such that they aren't a problem now, but still found it painful initially. Also, they are just so much more expensive than Digital Ocean, so it depends on budget vs time/skills to manage the server I guess.

For many years I was fortunate to host all my sites on my own dedicated University servers. These days I also use unmanaged Digital Ocean VPS servers whenever I can, but obviously these are not for everyone. The one thing I steer clear of is FastCGI / nginx as an apache reverse proxy - PW always gives me errors on these setups.

Sorry, @guenter55 - I don't see anything in that example at osana.com that looks like a way to revoke consent after they have already given it. In my mind the link to revoke after initial accepting isn't something that can really be part of the module because where it should physically appear is specific to every different website - it's not something that can be in an overlay banner like the initial accept/deny option.

I think this is probably just a side-effect of this recently introduced core bug: https://github.com/processwire/processwire-issues/issues/979

Your mileage might be different, but I found Webfaction hosting quite slow, not to mention a very strange and overly complicated control panel ?

Did you try the Smart Title in the overall defaults?

Not sure, but I think my fork/branch does take care of that: https://github.com/adrianbj/MarkupSEO/tree/various-fixes-enhancements

Thanks everyone for the recent discussion on this - the intricacies of GDPR are not my forte. Sorry, I don't really understand what you are looking for here - I don't think the module should always output a "Manage Your Cookies" - I think this needs to be something that the site developer decides where it should go and how it should be styled. Or maybe I am confused by what you want?

I agree with @teppo - I recently discovered a colleague who was using phpc extensions on a site and he'd left debug mode on. I changed a URL query string value to something invalid which threw an error in a phpc file and I could simply load that file in the browser and view its contents - turns out it contained a payment gateway API secret key. All this because of a non-standard extension that PW's default htaccess file doesn't prevent access to.

I know I am getting OT, but I almost never use target="_blank" anymore. Here are a few thoughts: https://css-tricks.com/use-target_blank/ I think the key thing for me is that it's really hard to prevent opening a new tab when it is used, but it's really easy for the user to choose to open in a new tab if they want, so my rule is that unless the user will lose unsaved form data as a result of opening a link in the same tab, I never force a new tab.

Yeah, I feel like the new core addition could show the layout of the fields like your Robin's does. I guess the issue could be with not having enough room to show the field label, name, type and width, but maybe there is a solution that would work.

Some great musing there! I don't think there will ever be a one-size-fits-all approach for creating menus that works for every site. Sometimes I match the menu exactly to the page tree. Sometimes I hard code it. Sometimes I have a checkbox field that determines if each page should be in the menu. Sometimes I let the site editors control it like this with two page reference fields for the header and footer menu respectively, and put it in a "Menus" tab on the homepage. And sometimes it's a combination of these approaches for different parts of the site. There are so many options and each has its place.

Not currently, but it could be a simple addition.

I see you are using what looks to be custom action. Do any actions work? Have you put a bd() call inside the exexute function to see if it's called at all? Have you done a hard reload in your browser to make sure you are getting the latest js files?

Make sure sure you get your PW and LP versions compatible with each other: ListerPro v1.1.3 for PW 3.0.137+ (August 2019) - Newest DEV version: ProcessPageListerPro113.zip ProcessWire 3.0.137 or newer is required for this version! ListerPro v1.1.2 for PW 3.x (January 2019) - Newest MASTER version: ProcessPageListerPro112.zip ProcessWire 3.0.98 or newer recommended.

Anyone new to this module, please be aware of this unfixed issue: https://github.com/ryancramerdesign/ServiceCurrencyConversion/issues/1

It doesn't diminish your request, but Interestingly I have an issue where AOS actually causes a horizontal scrollbar to appear on desktop on some pages - as soon as I disable AOS it goes away. I haven't narrowed down the cause, but something worth thinking about in all this.

Thanks @Macrura - that got me on the right track - should be fixed in the latest version.

Hey @Macrura - you gotta give me more than that ? Seriously though, it looks like there is something breaking output for the Server Request section, or perhaps it's actually being broken in the preceding Field List & Values section. Could you please try disabling those two sections (in the config settings there are checkboxes) and see if that fixes things? Then perhaps you could narrow down what part of the section is failing please? My gut feeling is that it is the Field List & Values section and there is some field that is breaking things. Thanks.

Based on the available methods in this module, it seems like the best approach is actually now: $map = $modules->get('MarkupGoogleMap'); echo $map->getGMapScript(); You can see here: https://github.com/ryancramerdesign/FieldtypeMapMarker/blob/917edef8efe92bf8bdbdff62b66f6eca581ca57e/MarkupGoogleMap.module#L154-L165 that this will return the entore script tag you need, along with your API included. Of course it would be nice if the module docs mentioned this ?

Just added a small feature that fixes a big pain point for me. When editing a page, there is a new button in the AdminTools panel to change the "collapsed" status of all fields to fully open and editable. This is great for those fields that you don't want available regularly (especially for non-superusers), but occasionally need to view or edit. Fields will remain like this until you click this alternate button, or the site cookies are cleared. Hope you find it useful!

@teppo - yep, you have understood exactly what I am suggesting. I agree - I don't like long click / double click. Perhaps just a dropdown from the "Edit" link that says "Edit in Admin". But of course the main top-level Edit link would edit in the overlay, so no need to wait for the dropdown to appear when wanting to edit this way. ??