Leaderboard

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

You probably have "dev" in your hosts file pointing to localhost.

10.5 and 10.50 in terms of calculation is exactly the same. If you need this for output on the frontend side, then you could do a simple PHP number_format.

You could try using the FieldTypeDecimal module for this. If I remember correctly, there is a setting to specify number of decimal places in there.

https://github.com/processwire/processwire-requests/issues/126

And here we go again… 0.6.1 is out now: Everyone is going green, only AdminThemeBoss was somehow missing the trend… So this new version fixes this glaring oversight ? New «Smooth Green» color scheme ? Fixed: Small issues with asmSelect entries Fixed: Mobile view with AOS ? Get Release Notifications ProcessWire Modules Repository Gitlab & Issues

But again, I wouldn't disturb my visitors with yet another popup once they are happy that the original one has disappeared and they can finally get to their business. It's a legal necessity, I get it but most users I talk to hate them, myself included. So I stick to the very minimum that must be done and don't overdo it. I have a link in the footer that brings up the banner (as per instructions) but I won't invite the visitor to change their minds. ?

The VS Code live server and live sass is a good choice for smaller projects. Just keep the amount of .scss includes to a minimum. In regards to Koala... latest version is from 2017. At least the website is telling so.

Think that would be a job for @Gadgetto ?

If you have proper auditing tools in place then any modifications should be recorded. The other part is authentication/authorization. If you can verify that nobody can modify a certain record you're fine. Those things get tricky though for the people, who are responsible for setting up those systems, because they often also have the ability to circumvent them. That's the place where you want to keep access very restricted to a small set of people, still enable logs where possible and start using policies, which "tell" those people what they're allowed to do and what they're not allowed to do. As soon as you cannot (tech.) prove something wasn't modified you should at least be able to prove that you had other measures, which disallowed modification and to know exactly who had the ability to change things in a non-trackable fashion. There's no fool prove way to this, unless you give up control completely to a third party, and there are always going to be parts in your setup, which are best effort instead of watertight. From my understanding a good part of an evaluation by authorities will include not just technical checks, but also softer targets like proper training for personnel, written evaluations and documentation.

You're doing a needless check, because your query already returned only pages with `in_evidenza=1` $in_evidenza = $page->in_evidenza; if($in_evidenza == 1) { Your code could be simplified (untested): wire()->addHookAfter('Pages::saveReady(template=articolo)', function($event) { $pages = $event->object; // this should also be not needed foreach($pages->findMany("in_evidenza=1") as $new) { $new->setAndSave('in_evidenza',0); } });

Hallo everyone ? I have just release AdminThemeBoss 0.6.0: Introducing, a refined, more colorfull and streamlined expirience: Added: more colors ? Added: improved notifications ? Added: improved dropdows ⬇️ Added: improved integration with third party modules like ProDrafts, AOS and ASM… ? Under the hood improvements on how settings are saved and applied Fixed: Some minor bugs ??

@cosmo @wbmnfktr I updated module, i tested it with fresh pw 140 dev installation and i see there is problem on https://github.com/trk/Mystique/commit/b16fdba23f508c4901aeed56e71041ad34cf8c8b and removed this function. Let me know if you still have problem ?

I think it's great! I've already incorporated it into my current project, and it has a sizable performance impact on Chrome without any real work on my part. I always thought removing the src attribute and setting it with JavaScript was an antipattern, as anyone with JavaScript disabled wouldn't see any images at all, so it's good to see native support for lazy loading. It's progressive enhancement, so you don't need to have support from all browsers. Support doesn't look half bad though, even though only Chrome supports it at the moment (see caniuse), that's already a sizable chunk of the population. Also, caniuse currently lists Chrome on Android, which is huge (36 %) as not supporting it, I'm not sure that's correct. According to the Chrome Platform Status page, native lazyload is already supported in Chrome on Android. That would get the feature to >50 % browser support already. On current Android versions, all WebViews are provided by Chrome, so it will work in all in-app browsers on Android as well. Also, you can very easily polyfill the native lazyload with JavaScript (see article above), so everyone will profit from this without much of a downside!

Not "easier", but fun to dive into: if you have MySQL >= 5.7.8, you could convert the page data into JSON and store that string in the database in an InnoDB table with a JSON column when you save the page. Then use MySQL's JSON_SEARCH function to get the hits and fields (paths). This only works with exact or LIKE queries, though, and you will have a little additional work to convert the returned paths to field names. Of course, you will probably still have to write the nested loops to get the data into the database. Not sure how much FieldtypeRepeater->exportValue() can help you avoid that. Table create statement example: CREATE TABLE jsonsearch ( pages_id INT NOT NULL, pagedata JSON, PRIMARY KEY(pages_id) ) Engine=InnoDB; Hypothetical page data for equally hypothetical page 1013 as stored in JSON: { "name": "vehicles", "title": "Our Vehicles", "data": [ { "type": "motorbike", "color": "blue" }, { "type": "car", "specs": { "colors": [ "red", "green" ], "subtype": "motorbike" } }, { "type": "bike", "color": "black" } ] } Query example: /* Get page id and fields where any field's value equals "motorbike" */ select id, json_search(jsondata, 'all', 'motorbike') as paths from testjson where json_search(jsondata, 'all', 'motorbike') is not null; /* Output: id paths 1013 ["$.data[0].type", "$.data[1].specs.subtype"] */ /* Get page id and fields where field's value contains "bike" */ select id, json_search(jsondata, 'all', '%bike%') as paths from testjson where json_search(jsondata, 'all', '%bike%') is not null; /* Output: id paths 1013 ["$.data[0].type", "$.data[1].specs.subtype", "$.data[2].type"] */ It also allows searching by a field name and by full and partial paths. /** * Search all "type" fields in the page's "data" array (repeater) for the string "bike". * This would find results with bike contained in a field data.type but not in * data.relatedvehicles.type */ select id, json_search(jsondata, 'all', '%bike%', NULL, "$.data[*].type") as paths from testjson where json_search(jsondata, 'all', '%bike%', NULL, "$.data[*].type") is not null; /* Output: id paths 1013 ["$.data[0].type", "$.data[2].type"] */ /** * Search all "type" fields at any level for the string "bike". * This would find results with bike contained both in data.type AND in * data.relatedvehicles.type */ select id, json_search(jsondata, 'all', '%bike%', NULL, "$**.type") as paths from testjson where json_search(jsondata, 'all', '%bike%', NULL, "$**.type") is not null; /* Output: id paths 1013 ["$.data[0].type", "$.data[2].type"] */ Converting the JSON path syntax back to something that makes sense for PW would just mean to json_decode() the paths value, cut off the first two chars and remove the digits within curly braces (though the numeric value are of course the index number for calling eq() on a Repeater/PageArray to get the individual item).

You are correct sir. Thanks for pointing that out!

Hi Folks, this is a bit older project but i thought that I will share it with you - https://icapturemylife.pl/ About 2 years ago one of my friends and clients asked me to build a personal photography blog for himslef. In a day life Mariusz is a professional volleyball player, but in his spare time as an amateur photographer he loves taking pictures and learning about photography. Technically, the site was built from scratch with core PW functionalities, the only module used here is Ryan's "login - register" module - to avoid time-consuming comment moderation, we decided to allow comments only for registered users. In general, the blog is quite simple, but it was real fun to build it with PW! I hope you like it ?

Thanks all. I'll be working with a long time PW community member on this. Case closed.

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.

Brave might block the whole script actually - and I like it. This "Sorry, changed my mind" thing appears top/left or bottom/right after clicking "Ok... got it!". You have to look for it actually. I almost always miss it.

https://scout-app.io http://livejs.com https://www.sassmeister.com https://www.npmjs.com/package/livereload (?) https://compass.kkbox.com (?) (I didn't include some that are only free, and not open source.)

Well... I guess we just have to push @OrganizedFellow back to his Linux roots. ? Just kidding...

The demo at https://cookieconsent.osano.com/ gets actually blocked from most (of my installed) adblockers in their default settings. Which is quite interesting. Maybe that's the reason why I don't see those banners that often anymore. But back to your question... you already found the link to trigger the cookie management tab/banner. You can place it whereever you want and whenever you feel the need for it. So your idea of a slide button already exists - somehow. You have to style it anyway for each project. It's just another link - or whatever you want it to be. I personally place it on my privacy page at a some places with various labels (disable Google, disable cookies, revoke cookie decision, and so on...). <a href="#cookies" class="js-pwcmb-notice-toggle">Change cookie settings / revoke decision</a> Your Silktide example shows it's "Sorry, changed my mind" banner only once, right after accepting or denying cookies. At least in all demos I found. You or a developer you work with could check if the cookie is either set or has a defined value to enable the above mentioned link - there are a few ways to do so. Another option would be a fork of the module and changing the lifetime of your cookies to day or a week.

https://github.com/oklai/koala "The project has been stopped!! The development method has changed a lot be from the project start time to now, and there are many better alternatives in the open source community. So I think the projet is outdated, and decided to stop maintenance. Sorry about for this. If someone is still willing to continue maintenance, welcome to create a new project, it will be the best way." Too bad!

Ok, I thought this was a newer version of the previous one. So you are absolutely right... there was no .webp support or anything similar. ? Still a great job!

I'd support @bernhard's recommendation.

wire()->addHookAfter('Pages::saveReady(template=articolo,in_evidenza=1)', function($event) { $reset = $this->pages->find("in_evidenza=1"); foreach($reset as $p) $p->setAndSave('in_evidenza', 0); });

@3fingers edit your original post title with [solved] at the start ?

Thanks @psy! Right now my Hook looks like this (I've changed something more from my previous post): /* -- Changed: from Pages:saved to Pages::saveReady. Doing that I can avoid to setAndSave the "in_evidenza" checkbox on the current page. -- Changed: from "find" to "findMany". Even though I actually got few pages to search into, they could grow in the future. I didn't noticed speed improvements, but seems ok. */ wire()->addHookAfter('Pages::saveReady(template=articolo)', function($event) { $pages = $event->object; $page = $event->arguments[0]; $news = $pages->findMany("in_evidenza=1"); $in_evidenza = $page->in_evidenza; if($in_evidenza == 1) { foreach($news as $new) { $new->setAndSave('in_evidenza',0); } } }); I'm still open for suggestions!

There’s a PW directory and also contact @psy

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.

You don't need to mess around gulp etc anymore if you don't wanna. Give https://prepros.io/ a try. After I switched from Mac to Windows, I missed Codekit and Prepros is a good alternative. :) Also runs on Linux (as it's an Electron app).

I'm no expert either but there seems to be a consensus that GDPR does not require a one-fits-all approach for everything but quite the contrary. For example on a simple PW site where cookies are only used for their default purposes by the system and only editors and superusers login, I usually just state some "required for security purposes" blah-blah on the Imprint page linked form the footer or even form the main menu, and that is all there is to it. What you should do depends on lots of factors, including the local law. That's the "beauty" of regulations like this...

I don't want to dismiss this issue, but I also think that people sometimes overthink the whole field naming thing a bit. When you're creating a new field ... Decide if this field is something you can reuse elsewhere. Things like "images" or "summary" are obvious candidates, and then there are the likes of "color", "width", and "background_color" that are likely to fit into this category as well. If you can see further use for the field (or rather the data it represents), go with a generic name. If the field is very specific to the use case (based on it's purpose, context, or settings / formatting rules etc.) don't try to get too creative with the "always reuse" idea. If it's a field that's specifically designed to hold google_analytics_id, just name it accordingly. Reusing fields is the best practice, but reusing fields for something they're not meant to do (and/or where they'll make no sense at all) will just mess up your information architecture – not to mention the issues it'll cause once you realise that in a particular use case you actually need to tweak some field setting that cannot be changed in template context. (Note: I'm aware that you can nowadays make a lot of stuff changeable in template context. In my experience it doesn't necessarily mean that they work as expected, and even then it can result in a whole new layer of complexity. Personally I try to avoid that.) 50+ fields is plenty, but especially if it's a moderately big project, in my opinion it's nothing to be worried about. ... oh, and one more thing: sometimes I see folks create loads of "duplicate" fields such as email_1, email_2, email_3, etc. That's one one easy place to optimise: use one of the repeatable fiield types, ProFields table, etc. Table is particularly great because it can handle large amounts of data in an efficient manner ?