Weekly update – 29 January 2021

[ryan]

This week we have a couple of useful new $pages API methods. They are methods I've been meaning to add for awhile but hadn't found the right time. The need coincided with client work this week, so it seemed like a good time to go ahead and add them. I'm doing a lot of import-related work and needed some simple methods that let me work with more page data than I could usually fit in memory, and these methods make that possible. These won't be useful to everyone all the time, but they will be useful in specific cases. 

The first is $pages->findRaw() which works just like the $pages->find() method except that it returns the raw data from the matching pages, and lets you specify which specific fields you want to get from them. For more details see the findRaw() documentation page.

There's also getRaw() method which is identical to findRaw() except that it returns the raw data for just 1 page, and like get(), it has no default exclusions.

The next method is $pages->getFresh(). This works just like $pages->get() except that it gets a fresh copy of the page from the database, bypassing all caches, and likewise never itself getting cached. ProcessWire is pretty aggressive about not having to reload the same page more than once, so this method effectively enables you to bypass that for cases where it might be needed. Again, probably not something you need every day, but really useful for when you do. More details on the getFresh() documentation page. 

I'm going to likely cover these new $pages API methods in more detail in a future blog post, along with some better examples, so stay tuned for that. I noticed there's some pretty great conversion and examples happening in the posts on page builders here, but have been so busy this week I haven't had a chance to dive in, but I'm really looking forward to doing so. Thanks and I hope you all have a great weekend!

[adrian]

Absolutely love this Ryan!

I know this is a very simple example, but take a look at the difference in the execution time and memory usage 🙂

[bernhard]

Hi Ryan,

thx for the update! Is there any reason why the label field is required? I find that really annoying - I'm leaving that blank most of the time while developing, because I see the name of the field instantly and change/fill the label only if the setup turns out to be working properly. Otherwise removing fields, renaming fields etc. is more work than necessary, because one always has to fill/rename one additional field that does not add any benefit. Would be great to revert this back to optional.

I like the new interface, though. But it would be better IMHO to show    name | type | label (optional)

PS: I saw that the page name fills automatically based on the label - that might be nice for all english speakers, but most of the others I guess will usually have different labels and field names, because the label is in their language while the field name is english...

[szabesz]

6 hours ago, bernhard said:

Would be great to revert this back to optional.

+1 – please

6 hours ago, bernhard said:

have different labels and field names, because the label is in their language while the field name is english...

+1 – This should also be optional.

[Rudy]

@ryan, did you bump the latest `dev` version to `3.0.172` on Github? I noticed that the Upgrades module did not pick it up.

[sebr]

@ryan Since upgrade to 3.0.172, I have this notification alert :

Quote

Modules: Configurable module check failed for LazyCron. If this error persists, please do a Modules > Refresh.

And if use "Publish" button to publish a page I have this notification alert :

Quote

ProcessPageEdit: Saved Page: /testy/ - Cannot be published until errors are corrected

But if I uncheck "Unpublish" or if I publish from page list, the page is published.

Any idea ? How can I look for something to resolve it ?

[bernhard]

21 hours ago, sebr said:

Modules: Configurable module check failed for LazyCron. If this error persists, please do a Modules > Refresh.

Same here!

[apeisa]

22 hours ago, sebr said:

Modules: Configurable module check failed for LazyCron. If this error persists, please do a Modules > Refresh.

Same here. This is probably windows specific problem - at least in our company it is.

[Zeka]

23 hours ago, sebr said:

Modules: Configurable module check failed for LazyCron. If this error persists, please do a Modules > Refresh.

Same here on linux. 

[snobjorn]

On 2/16/2021 at 11:40 AM, sebr said:

Modules: Configurable module check failed for LazyCron. If this error persists, please do a Modules > Refresh

Same here.

[bernhard]

Thx @snobjorn for creating the issue https://github.com/processwire/processwire-issues/issues/1339

Everybody having this problem please give it a thumbs up! I'm locked to v171 due to this issue 😞 

[Jan Romero]

Uninstalling and reinstalling LazyCron fixed it for me.

[snobjorn]

I got an answer to the issue. It was already fixed: https://github.com/processwire/processwire/commit/4d04aac2a646d6c387d1afff28253225dace8474 – and I can confirm that it works for me now as well.