Leaderboard

Just a quick update this week. I’ve got a good post in the works that I thought I’d have ready for today, but didn’t have quite enough time to finish it, so going to save it for next week. Though there's a module that's part of the post, and since it is ready, I've posted it below. We’ll look at ProcessWire 3.0.138 next week as well. I do have a couple of non-core updates to mention this week though. First is that I’ve released a new Textformatter module that converts any image references in your CKEditor/textarea fields to WEBP images on-the-fly as pages are rendered. If you are implementing WEBP on your site, you’ll find that the images placed in rich text fields are the most tricky ones to serve as WEBP, so this module takes care of that task for you. It's in the modules directory or at GitHub: https://github.com/ryancramerdesign/TextformatterWebpImages I’ve also released new development versions of the ListerPro and Export CSV modules, both of which are available to subscribers in the ListerPro support board. Some of the new features are actually built into the core, but currently only utilized by ListerPro. There’s quite a bit of new stuff, so there’s also an ~18 minute screencast that walks you through them, which can also be found in the ListerPro board.

Yeah - I've too often had to build complicated RockFinder queries and came up with this quick&easy solution one day and couldn't believe I didn't think of it earlier ? Don't tell anybody, but I've just started developing RockFinder2 with a new syntax that will be even easier to use and more intuitive and powerful ?

Hi @kixe, additionally to what @jploch said above, and when you are already at it ;-), it would be very helpful to have the option for auto-backup on login! The real life usage of auto backup on logout is not consistent because some users simply leave the backend without logout process. So I would prefer to switch to auto backup on login process. :-) (Login process can not be skipped like Logout process!)

Hi Jeevanish, For the most point some of these are just buzz words. Headless CMS is basically the CMS exists away from the website and talks via an API such as JSON / XML / GraphQL (This allows you to use the data anywhere on the web or an internet connected drive, lets say for an APP) Hybrid CMS is something that seems relatively new, and it seems to be that Headless CMS doesn't have great editor functionality, hybrid seems to be a buzz word around it's a great easy to use CMS with Headless functionality, I guess if you installed GraphQL to ProcessWire it would be considered hybrid. Digital Experience Platform seems to be a platform that all talks to each other using different mediums. Lets say you have a train station, that system lets you book a ticket, that then updates a message board letting them know how many tickets are left, which updates their website and also sends to the ticket attendents which shows that the ticket is for that train. This is just an example. This system can be accomplished with Headless or Hybrid.

Thx, fixed in 1.1.5 True, but I won't fix this as it's not critical and I want to focus on RockFinder2 + RockTabulator ?

So it sounded great. ? Yes... indeed.

@neophron (1) Are you just wanting to output your own player on a page, or use the Textformatter? The Textformatter is for putting in shortcodes into Textarea fields, like Body. (2) The code you posted would only work if you are doing delayed output using a $content var, otherwise if your templates are direct output, you have to echo the content, something like: <?php $options = [ 'type' => 'bar-ui', 'skin' => 'gradient-fat', ]; foreach($page->audio_file as $track) { echo $sm2->player($track, $options); } (3) if you want to use the text field to output an audio player based on a shortcode, then you have to echo the textfield, with the Textformatter applied, like: echo $page->myTextField;

What does autojoin do? Using the 'autojoin' optimization can increase performance on fields that get used a lot. Not using it can reduce the page's memory footprint. What is more desirable in each instance depends on your situation. What sites should use autojoin? Autojoin is most applicable with larger sites. On smaller sites, there may be no benefit to using it or not using it. But it's good to know what it's for regardless. Where do you control autojoin? Autojoin is controlled per-field. You can turn it on by editing each field under Setup > Fields > [your field], and you'll see it under the 'Advanced' heading. When should you use autojoin? Autojoin causes the field's data to be loaded automatically with the page, whether you use it or not. This is an optimization for fields that you know will be used most of the time. Fields having their data loaded with the page can increase performance because ProcessWire grabs that data in the same query that it grabs the Page. Autojoin is a benefit for fields that are always used with the Page. This is best explained by an example. Lets say that you have a template for individual news stories called news_story. The news_story template has these fields: title date summary body sidebar We'll assume that when you view a page using the news_story template, all of the fields above are displayed. Fields that should have autojoin ON: Now consider a separate news_index template that displays ALL of the news stories together and links to them. But it only displays these fields from each news story: title* date summary In this case, the 3 fields above would be good to autojoin since they are used on both the news_index and news_story templates. If your title, date and summary fields didn't have autojoin turned on, then ProcessWire wouldn't go retrieve the value from the database until you asked for it it (via $page->summary, for example). Because the news_index template displays all the stories at once, and always uses the title, date and summary fields, it will perform better with title, date and summary having autojoin ON than with it OFF. In this case, it reduces the query load of the news_index template by 3 for each news story. To take that further, if it were displaying 20 news stories, that would mean 60 fewer queries, which could be significant. Fields that should have autojoin OFF: Now lets consider the body and sidebar fields, which are only used on the news_story template: body sidebar It would be desirable to leave autojoin OFF on those fields because there is no reason for the body and sidebar to be taking up space in memory when they are never used on the news_index template. While it might mean 2 fewer queries to view a news story, that is not significant and certainly not a worthwhile tradeoff for the increased memory footprint on the news_index template. Keeping autojoin OFF reduces a page's memory footprint. Conclusion Using the 'autojoin' optimization can increase performance on fields that get used a lot. Not using it can reduce the page's memory footprint. What is more desirable in each instance depends on your situation. But if your situation doesn't involve lots of pages or data, then you don't need to consider autojoin at all (and can generally just leave it off). Additional Notes Not all fields have autojoin capability. You won't see the option listed on fields that don't have the capability. *The title field has autojoin on by default, so you don't need to consider that one. It was included in the examples above because I thought it's omission might cause more confusion than it's inclusion. Be careful with multi-value fields that offer autojoin capability (page references and images, for example). Because MySQL limits the combined length of multiple values returned from a group in 1 query, autojoin will fail on multi-value fields that contain lots of values (combined length exceeding 1024 characters). If you experience strange behavior from a multi-value field that has autojoin ON, turn it OFF. If you want to play it safe, then don't use autojoin on multi-value fields like page references and images.

--- Please use RockFinder3 ---

Thanks, (2) is the solution for me ? I'm using the markup regions output strategy.

Yep, that's certainly worth a try. See this announcement from @ryan https://processwire.com/blog/posts/using-innodb-with-processwire/ tl;dr: Row locking versus table locking (Inno vs. ISAM)

I won't ??? I just realized the "view" link in the RF Tester (zooming glass icon) seems to be hard-coded: it's assuming my PW backend is "admin". This should probably be defined dynamically instead (or at least configurable). Also, I noticed the div.paginationPageSize is always showing "undefined" o_O

Ah, nope. They are fully supported. I use them all the time in most of my modules. Maybe show us some code?

You are right, it's a single process. Hooking into any method will still be in the same process and the visitor will need to consume the request time. I'll need to "launch" a new (background) process which will do the heavy lifting.

https://modules.processwire.com/modules/video-or-social-post-embed/ this works very well in my website : http://wingsrobotics.com/videos/

To my best knowledge it is still same request and visitor has to wait before actual content is ready to be served. Lazycron is (in my opinion) usable for very quick cleanup type of things only. Much better to use actual cron or other background process to do that kind of stuff. SnipWire looks fantastic! Great that PW will have multiple e-commerce options available!

Maybe I need glasses now but... what on that site and the editor looks awesome? I can't see anything special. Not even the real input and/or block type selection dialogues. I'm confused... ?

I think it's a bug and I've opened an issue here: https://github.com/processwire/processwire-issues/issues/956 Regarding different CKEditor configs per Repeater Matrix type, Ryan has suggested some code in a recent topic in the ProFields forum:

Thank your for the kind words! ? I don't know if this will make it into the first release version but it seems to be a necessary step. LazyCron, on the other hand, does not seem to be well suited. This would cause delays for website visitors. I was thinking more of a separate worker process, or multiple parallel processes, running asynchronously and externally triggered by a cron job or by Javascript runner. I have already implemented something like this for a newsletter module for MODX.

Very nice — I'm really impressed about how this is coming along. I particularly like how you manage to pack as many features into it while successfully staying within ProcessWire's visual language. I wish I had a little more time on my hands to try it out in depth and give useful feedback. That sounds like a logical next step to me: using LazyCron to auto-fetch certain data. While it will increase complexity in the short term, it will probably make your job a lot easier in the long run and make for a better experience using the module.

Check this out people, Kirby also just launched their new editor in a similar fashion: https://github.com/getkirby/editor

I kind of like that also, although requires extra step on template code.

Hey Kixe! Thank you for this great module! I use it quite often. For most projects I need the backup to get triggered when the client logout. I don't want to give the client the backup permission, to prevent them to mess things up. From your comment above it seems the permission is not needed. But when I logout without the backup permission, the backup is not working. It would be nice if the backup gets triggered by any user on logout, or at least an option for this.

Hi Mitlesh, this is the clone of a thread you've opened yesterday, asking more or less the same. That being said if you want another image, wherever you want, you just have to output it inside your code, like you've done with the one you've referenced. Don't forget: 1) you have docs at your disposal. 2) it's august and many of us are away for vacation, so if none replies at your first thread be patient and search the forum for an answer.

Not sure why this means URL segments can't be a solution. You hook Pages::added and put the title through $sanitizer->pageName and save it to a hidden field (full_page_name). Then in the parent page template you check the URL segment against full_page_name and render any matching page (and throw a 404 if none found). For URLs to the pages you hook Page::path as per Ryan's case study and concatenate full_page_name to the parent URL.

There are several places that 128 is forced: https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/core/Sanitizer.php#L415 https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/core/Pages.php#L85 https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/core/PagesNames.php#L49 https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/core/PagesNames.php#L314 https://github.com/processwire/processwire/blob/341342dc5b1c58012ae7cb26cffe2c57cd915552/wire/modules/Inputfield/InputfieldPageName/InputfieldPageName.js#L60 https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/modules/Inputfield/InputfieldText.module#L258 When creating a new page, it's the JS file that kicks in first and truncates it as the title is typed. You could override the JS one pretty easily (look at my PageRenameOptions for hints on how to do this), and also deal with the sanitizer by setting the name in a hook and resaving, and you could hook into InputfildText::processInput to deal with the dirty length truncation. I think the hardest but might be dealing with nameMaxLength constants that get used in PagesNames.php in the pageNameFromFormat() method. Definitely much easier to see if Ryan might relax the limit, or make it configurable ?

I've used template prefix syntax for my fields in one project and it is really annoying now ? You might find some inspiration here: https://processwire.com/blog/posts/making-efficient-use-of-fields-in-processwire/