DrQuincy

And here's the answer to migrating large sites! Thanks Ryan. https://processwire.com/blog/posts/webp-images-on-an-existing-site/#implementing-the-webp-strategy

If you enable webp, where the easiest way on a legacy site to get a webp version of every image in the CMS?

Apologies, everything I need is here: https://processwire.com/blog/posts/webp-images-and-more/#webp-image-strategies-in-processwire

This is a bit vague but I've always been behind the curve with regards to next-gen images. To those of you PW masters that use them I have a few questions please. 🙂 What is you preferred format? In 2024, do you still need to supply a jpg/png fallback? How to you manage this in PW given that support outside of the browser is quote poor. What I mean by that is while us devs can work with them easily, clients tend to only know what jpgs are. Thanks!

Thank you, this one worked. I couldn't see for looking that the conversion was wrong:

I'm tearing my hair out here. I have a Datetime field and whenever I use it in a selector — regardless of how I use it — no pages are returned. I've: Checked the field name is correct Checked the field type is correct Checked the selector is correct Tried multiple date formats as the selector value The field is called propertyEarliestDate. So, if I do: wire('pages')->find('template=property, propertyEarliestDate>=' . strtotime($myDate)); // $myDate definitely produces the correct Unix timestamp I get an empty array. If I change it to: wire('pages')->find('template=property, propertyEarliestDate<=' . strtotime($myDate)); I still get nothing — even though I have changed to selector to check the opposite. If I remove the selector all together it works. If I remove it, it returns some pages: wire('pages')->find('template=property'); There are definitely pages with propertyEarliestDate populated. Any ideas of anything I might be missing? Thanks.

@Jan Romero Thank you for this!

I have a template, product, that has a field, downloads. I want people to be logged in to access downloads but I also want role guest to view the page. When you choose the option to restrict access to a template's files it determines this, rightly, based on the options set in the Access tab. How can I make ProcessWire restrict access to downloads while at the same time making the actual page viewable by guests? So if you had /page/ that has a link to /site/assets/files/999/file.pdf, everyone could view the page but the file would 404 for guest - but be accessible for anyone logged in. Thanks.

This is perfect. Nice and simple and just what I wanted, thanks.

Awesome, thanks.

Is there an admin plugin to test out selectors? What I mean is, you'd have a text field where you can enter a selector and it gives your details of which pages would be affected/returned. I say “would be affected” as it would be useful to test out how live data would be affected so you can be 100% sure your selector is right. I hope that makes sense. Does such a thing exist? Thanks.

I have tried Autojoin and it is approx. 5 x faster so that's good.

I have something like this: $pages = wire('pages')->find('template=foo'); // $pages->count = int(330) foreach ($pages as $page) { // Here I get 23 properites $foo1 = $page->property1; $foo2 = $page->property2; // ... $foo22 = $page->property22; $foo23 = $page->property23; } If I only get 1 property is takes about 0.02s. But if I get all 23 it goes up to ~5s on a decent Linux server. The number of properties retreived proportionately increases the execution time so there isn't any one property that is a bottleneck. Is this to be expected? 330 pages is not exactly a lot. I know the API has a $cache variable but the above pages are linked to a search form so it could prove tricky (although I could cache the initial form where no filters are applied). Is there anything I can do to increase the speed? I guess I could store all properties as JSON in an additional field and just retreive that. It just seems unreasonably slow to deal with that kind of execution time on a few hundred records. Thanks. EDIT: Just seen that the Autojoin option might do the trick.

Thanks, I've looked at their competition and they're prhibitively expensive for the client's size. I'll keep looking!

I am doing a site for a client who has a pub and a few holiday cottages and pub rooms. Does anyone know of a single system that will inexpensively let them do both and integrate via a widget or link on the website? Failing that, can you recommend an inexpensive one for rooms and another for restaurant bookings? Thanks.

My PW install is MB4 but my legacy one (soon to be switched off so no point converting) is MB3. Running SET NAMES `utf8mb4` before reading the Mb3 database does the trick nicely. ?

Thanks everyone. I have also noticed that $page->created === 0 works too.

That is super helpful, thanks. You are absolutely right there.

Thank you!

Awesome, and thanks for the fast response!

I'm don't know if I've missed something in your link but is it possible to add a path hook that runs when a page already exists in PW? This is esssential to what I want to accomplish.

Ah, great! You learn something great and new about PW every day! I can redirect, return a page or throw a 404 exception. Perfect!

Just that…once a page is created I do not want to allow the page slug/name to ever be changed. So the name should be available no the initial page during creation but not after that. Is that easy enough to do? Thanks!

How can I write a hook that happens when PW has dtermined the page is not found? I have some pages where the page name is a unique numerical ID (also stored in a hidden field) followed by a standard slug. E.g: /folder/4545-foo-bar /folder/89897-test-page If someone enters, to use an example above, enters site.com/folder/4545 PW will send a 404. However, what I want to do in the hook it search for a page that has the unique numerical ID. If it exists, redirect to that. If it doesn't, allow the default 404 behaviour to occur. I hope that makes sense. Thanks!

I've got it working. It's really easy; before you read anything from the utf8mb3_general_ci database run this query: $database->query('SET NAMES `utf8mb4`'); This will mean any queries in the current connection will use the same charset as PW and everything will work okay.