Leaderboard

I often need to explain my clients that they need to be more precice with their bug reports and explain step by step what they did and what happened. Today a friend of mine shared a link of an austrian startup that wants to help in such situations with easy on-the-go screen/audio/video recording. https://recorder.calipio.com/home What do you guys think? I could think of a "support" button in the PW backend that opens that tool and sends the link directly to me via mail as a support request...

This module lets you restrict users to a certain branch of the page tree - it can limit editing permissions, as well as the page list view to this branch. http://modules.processwire.com/modules/admin-restrict-branch/ https://github.com/adrianbj/AdminRestrictBranch Restricted View Non-restricted View Note that this module does not add permissions (unlike how PageEditPerUser and PageEditPerRole work), so the user must have template level permissions to edit the pages in the restricted branch. What this does allow though is giving all users/roles editing access for the home template and allowing that to inherit all the way through the page tree and let this module restrict to specific branches. As you can see from the screenshots you can specify how to determine the branch to restrict the user to - either via a matched role name, or via a dedicated page select field on the user's profile. The match role name works like this - if you have a series of branches called: Branch One, Branch Two, etc, users with a role named: branch-one will only have access to Branch One. You can also decide whether to restrict page tree viewing as well and editing privileges (default) or just editing privileges. The Branch Exclusions option is important for things like external PageTable parent branches etc. Main module config settings User specific branch setting on user profile page This module came out of my personal needs as well as this discussion: https://processwire.com/talk/topic/11428-project-design-main-shop-hundreds-of-affiliates/ As always, feedback is very welcome.

Last week I asked you what you'd like to see in ProcessWire in the next year (and years ahead), and we got a lot of feedback. Thank you for all the feedback, we've had a lot of great and productive discussion, and of course feel free to keep suggesting things too. Below is a summary of things based on what I thought was feasible from the feedback so far. I'm not suggesting we'll be able to do all of this in 2021, but do think it makes a good preliminary roadmap of things to look closer at and start working on some very quickly. I'll keep working to narrow this into a real roadmap, but wanted to share where we're at so far (consider it preliminary/unofficial): Flexible content or page building One of the most common themes has been that people want more content building options as an alternative to using a rich text editor at one end, and page builder at another. This is a direction that some other CMSs have been going in (like WordPress), and one that many would like to see ProcessWire provide an option for as well. But the needs seem to come from two different angles, and it points to us pursuing 2 directions simultaneously: First would be a flexible content block style editor in the core as an alternative to rich text editor that supports pluggable block types while maintaining best content management practices. If possible, we'd use an existing tool/library like editor.js or another as a base to build from, or potentially build a new one if necessary. To be clear, it would not be a replacement for CKEditor but an alternative approach supported by the core. Second would involve improvements to Repeater/RepeaterMatrix that enhance its abilities in supporting those using it for building more complex content page builders. Since many are already using it for this purpose, the goal would be primarily to better and further support this use case, rather than make Repeater/RepeaterMatrix a dedicated builder. Jonathan Lahijani and others have pointed out some specific things that would help achieve this and I plan to implement them. Admin theme improvements We would like to add additional flexibility to the AdminThemeUikit theme so that people can further customize it how they would like it. What directions this will take aren't nailed down quite yet, other than to say that it's going to be getting some focus (and this has already started). At the very least, we know people want more sidebar options and the ability to tweak specific CSS, perhaps in a preset fashion. Improvements to existing Fieldtypes and Inputfields Things like support for a decimal column type, more date searching options and additional input level settings on other types. Though these are specific feature requests and our focus is more broad, so we'll be going through many of the core modules and adding improvements like these and more, where it makes sense. Pull requests and feature requests People would like to see us expand our code contributor base by merging more pull requests in cases where we safely do it. We will also be narrowing in on the specific feature requests repo to see which would be possible to implement this year. External API There are requests for an external/front-end API that would also be accessible from JS. I support the idea, but have security concerns so am not yet sure if or in what direction we might take here, other than that I would like us to continue looking at it and talking about it. File/media manager and more file sharing options There is interest in an option for a central media/file manager so that assets can be shared from a central manager rather than just shared page to page. There is also interest in the ability for file/image fields to reference files on other file/image fields. External file storage Some would like to be able to have PW store its /site/assets/ and/or /site/assets/files/ on alternate file systems like S3. That's something we'd like to use for this site too. To an extent, work already started on this last year with some updates that were made, but there's still a long way to go. But it will be great for sure. Live preview and auto-save There are requests for live preview and auto-save features to be in the core. Currently they are just in ProDrafts, but there are now more options and libraries that would facilitate their implementation in the core, so I'd like to see what we can do with this. More multi-site features There is interest in ProcessWire natively supporting more multi-site features, potentially with the option of working with our multi-language support.

@Brian Scramlin, to use WireArray::sort I think the items in the WireArray need to be Wire-derived objects, e.g. WireData. Relevant API documentation: https://processwire.com/api/ref/functions/wire-data/ https://processwire.com/api/ref/functions/wire-array/ Demo:

I have been able to accomplish the task natively with: usort($meevo_response_array, function ($a, $b) { return $b['transactionDateTime'] <=> $a['transactionDateTime']; }); But if I can do it the ProcessWire way, I try to.

In template files I use the page-id to get the page or, where I have set a specific template name, I use this to get the page, and then uses the $p->url. There are different ways and concepts people uses. I prefer to give own template names to specific pages, limited to one page only, so that I securely can get them from everywhere, regardless what name a editor gives them, or if a site owner deletes a page and creates a new one (what changes the page id). In the templates settings I use the property for mapping a different template (render) file. So, for an unlimited number of basic-pages, 1 imprint page and 1 contact page I use 3 template names and one template file: template file is: site/templates/basic-page.php template names are: basic-page, can be used for (unlimited) new pages imprint, can be used only for one page and is mapped to basic-page (template file) contact, can be used only for one page and is mapped to basic-page (template file) But as already said, that's only my preferred way. ?

For rapid development it is really great to trigger migrations on Modules::refresh(); As I'm using this technique all the time I've added a new method "fireOnRefresh" to v0.0.27 public function init() { $this->rm()->fireOnRefresh($this, "migrate"); } public function migrate() { $this->rm()->createField(...); } Another handy update is the trigger() method that I use in combination with custom pageclasses. Custom pageclasses are awesome, but they do not trigger init() and ready() methods by default. That is a pity, because I usually want several hooks to live in the pageclass and not in the module (for example auto-publishing pages or creating random pagenames etc). Now that can simply be done in an autoload module: // in init() $rm->trigger("\MyNamespace\MyPageClass", "init"); // in ready() $rm->trigger("\MyNamespace\MyPageClass", "ready"); I've also updated the example module that uses this technique ?

Yeah exactly - it may not be an issue for you, but if someone was setting things up, it could be confusing - not saying it's not a possibility to get things right, but I know that Ryan had concerns when we've talked through this issue.

I guess you mean that pages can be visible in the admin, but if they lived under a parent that is not listable than they'd become "invisible"? That would not be a problem at all for me, because I'm creating custom listings pages all the time anyway (the page tree is simply not good for listing tabular data!).

Hi HI David, in PW any function in a module that has ___ at the start, like ___handleApiRequest() in the AppAPI module you can use as a hook in your own code. See https://processwire.com/docs/modules/hooks/

My bad, I figured it out. In order to work the class only needs to extend WireData. So the following example works. <?php class MyClass extends WireData { public function ___someFunction() { // Do something } } // ready.php $this->addHookBefore('MyClass::someFunction', function($event) { // some customization });

Unfortunately we don't have a view-in-backend permission in ProcessWire. I've hit that wall several times, but it seems that nobody else is seeing that... https://processwire.com/talk/topic/15854-how-to-hide-menu-item-in-the-backend/ https://processwire.com/talk/topic/22369-hide-uneditable-pages-in-admin-treeprocesspagelist/ https://processwire.com/talk/topic/10195-hide-pages-from-admin-tree/ Would be great to open an issue in the requests repo so we could upvote that feature! I think PW would GREATLY benefit of such a permission level. For example @adrian 's "hacky" module should be obsolete then, I guess. Or am I wrong here @adrian?

You could remove it directly from the database, but in this case I would recommend another route that is likely easier: Comment out or remove the ___uninstall() method from NewsletterSubscription.module. Uninstall the module — this should now work as expected. If you no longer need the "newsletter" role, go to Admin > Access > Roles and remove it manually.

I think you're talking exactly about the Migrations module from @LostKobrakai and I believe you can use RockMigrations within it without problems. It says it's deprecated but works just fine, I'm using it on latest PW master. I do this exactly with that migrations module having the migrations in version control.

Perhaps I'm missing something, but couldn't you do something like this in a saveReady hook? $pages->addHookAfter('saveReady', function(HookEvent $event) { $page = $event->arguments(0); if($page->template == 'book') { $page->my_sort_field = implode(' ', array_filter([ $page->subject, $page->cleanauthor, $page->cleantitle, ])); } }); ... and now that your sort field (which could be a hidden text field, or a textarea if there's a lot of data, which I assume is not the case) contains a single value, you can sort results by that. As far as I can tell the only issue here is that you'll basically have the same data stored multiple times ?‍♂️ (Unless I've misunderstood you, and you actually want to keep all books that have a subject before any of those that don't, etc. But in that case a simple sort by multiple field seems enough.)

Sometime ago I encountered a similar problem with datetime fields not saving in local language. I think the issue was on Date/Time Output Format Code (field's tab Details). While for default language it was ok to use PHP date format, for locale languages I had to change to PHP strftime format. Example: - default (English): F j, Y H:i T - locale (Italian): %e %B %G %H:%M I got the hint combining this old post with the note above Date/Time Output Format Code: "The date/time will be output according to the format below. This is automatically built from the date/time selections above, but you may change it as needed to suit your needs. See the PHP date function reference for more information on how to customize this format. Alternatively, you may use a PHP strftime format if desired for localization." Yes... a bit weird! ? I hope you can find it useful.