Leaderboard

This week I've been focused primarily on keeping up with the conversation about requests for 2021 and beyond, as well as doing related research here. We are starting to narrow in on ideas and plans, but there's more to cover still. Most of the conversation is happening in the PW 3.0.170 thread and last week's update thread. If you want to see what our preliminary roadmap looks like, Teppo did an amazing job covering it in the ProcessWire Weekly #348. I don't recall where it was or who asked, but I remember someone asking whether things like "thumbs up" quantities on GitHub issue reports and feature requests are paid attention to. And the answer is, not really so far. That's because GitHub doesn't display this info anywhere other than on the actual issue report. And even then, I often don't notice it. But this week I've been looking into it more and see that we can sort GitHub reports by quantity of thumbs-up votes. (Maybe the rest of you knew about this, but I guess I'm slow when it comes to GitHub). So it turns out that these thumbs-up votes aren't just social media fluff, they are actually very useful on issue reports and feature requests. Usually I cover these things newest-to-oldest, but now I'm going to start going through in order of votes, as this seems to make a lot more sense. Sorry I didn't catch this useful feature earlier. Please use the thumbs-up votes on GitHub for issue reports and feature requests that you value the most, and going forward, that will help us to cover them in a useful order. Next week I'm booked on a client project (working in PW), so it may be quiet for another week in terms of core updates, but then will be back to wrapping up our roadmap and ProcessWire development. Thanks for reading this far and have a great weekend!

Hey, My 2 cents on the page layout / builder : about editor.js, I see it more as a nice-looking alternative to CKEditor than something genuinely different in what it offers (apart from for the structured data) and it seems a bit limited to be a page builder more than what is already available to us. And I agree with your pros & cons @ryan. But I do think that adding some improvements to the RepeaterMatrix module, which we all seem to use as a "page builder", is a good way to go. As much as I don't want my clients to have too much freedom when it comes to the layout, I think there could be a way to introduce a "layout abstraction" into RM, something simple and limited, but that could give more flexibility. In a (distant?) way, it would be like giving the user the ability we have, as admins, to define fields' width or group them in a fieldset. I drafted some screenshots to show what I had in mind, that could be "user-friendly" (close to what @Jonathan Lahijani showed in his video). The idea would be to have "layouts" which would be described just like RM items but instead contain abstract "containers". Just like you would with fields, you could change the width of said containers, and make sure they add up to 100%. Then in the page editor where your RM is, you would have the possibility to either add a "layout" or an item. A layout and its containers would reflect the way we described them in the settings, re: width. To show that the layout is something different, we could use the secondary color. And this could be how we translate that into (hopefully not with repeating parts like mine) code: <?php foreach($page->test_matrix as $item) { if($item->type == 'matrix_layout') { // reserved type name if($item->layoutType == 'two-columns') { echo '<div class="grid">'; foreach($item->subItems as $subItem) { echo '<div class="column-1-2">'; if($subItem->type == 'type_text') { echo $subItem->text; } else if($item->type == 'type_image') { echo $subItem->image->render(); } echo '</div>'; } echo '</div>'; } } else if($item->type == 'type_text') { echo $item->text; } else if($item->type == 'type_image') { echo $item->image->render(); } } A few notes : Don't be fooled by my screenshots, I just messed around with Firefox's dev tools. To keep things simpler a layout should not contain another layout. The page editor may become too dense, even unpractical, if there is too much containers. Maybe a toggle on a container to expand it along the horizontal axis could be a solution ? End of my 2 cents. (also : I like how @bernhard is removing the field's label to gain space and I think it could be nice to have such option in the core, like "☑️ Do not display the field's label". Of course it would then remove the ability to collapse the field, but it would be a conscious choice. Edit : this is especially useful in context where you use RM and have 1-field types, like I used in my example above)

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.

@adrian, how about this: By default all the config fields are displayed so you can use Ctrl+F, but when you click a quick link it hides all the config sections apart from the active one. This removes the clutter around the section the user wants to focus in on. Here is the CSS and JS if you want to play with it: #tracy-quick-links .InputfieldContent ul { list-style-type: none; padding: 0; overflow: hidden; } #tracy-quick-links .InputfieldContent ul li { float: left; padding: 0 5px 5px 0; } #tracy-quick-links .InputfieldContent ul li a { background: #e3e9ef; color: #333; display: block; padding: 1px 10px; border-radius: 3px; } #tracy-quick-links .InputfieldContent ul li a:hover { text-decoration: none; background: #d9e1ea; } #tracy-quick-links .InputfieldContent ul li a.active { background: #e83561; color: #fff; } $(document).ready(function() { var $quick_links = $('#tracy-quick-links'); var $config_fields = $quick_links.nextUntil('#wrap_uninstall'); $quick_links.on('click', 'a', function(event) { event.preventDefault(); if($(this).hasClass('active')) { $(this).removeClass('active'); $config_fields.show(); } else { $quick_links.find('a').removeClass('active'); $(this).addClass('active'); $config_fields.hide(); $($(this).attr('href')).show(); } }); });

I wonder if anyone else can weigh in on directions here? I know a lot of people like the editor.js direction, but Bernhard has also posted what seems like a good direction. They are very different directions, but seem to accomplish similar things. Ideally I'd like the community to narrow in on what's best for their needs and for ProcessWire. I don't think I'm the audience for this builder (my projects don't use this approach), but I really want ProcessWire to meet this need and compete in this space. I trust the community advice on this more than my preferences so would like to hear from you. I've spent some time looking at editor.js, and here's a benefits/drawbacks list that I came up with: Editor.js benefits Easy for users figure out, but does require experimenting with it to find where the tools are. Tools only visible contextually so everything is very clean, no real baggage until you need it. From a marketing/appearance standpoint, maybe good for PW (?). Storage is simple JSON, which is easy to work with as a PHP array on the front-end. That's assuming you need the content separated like this in the first place, which presumably the developer audience for a builder would be. Since it's a modular/plugin system, it has potential to offer more down the road than it does now in terms of capabilities. To me it also seems like kind of a cross between a full builder and something like CKEditor, so it might appeal to some as an alternative to CKEditor for certain cases. It already seems to have wide adoption and be an active open source project with a good track record. Editor.js drawbacks Moving blocks is not as simple as drag/drop or cut/paste. Instead you have to click up/down arrows to move a block. Interface that while nice in many respects, is completely different and inconsistent from anything else in PW. You are forced into using HTML elements (like <p>...</p>) as blocks, rather than being able to have something like a "rich text" block. It seems to me like a "rich text" (CKEditor) block is more useful than assuming every block-level HTML element to be a builder block. There are surprisingly few plugins, and few (or none?) seem to go much beyond what you can already do in CKEditor. Maybe the potential for creating our own new plugins is greater than CKE, but it's all JS and we mostly work in PHP. Unclear if there are any tangible benefits to the user relative to CKEditor. I'm also guessing most clients would prefer CKEditor since it's more like working in MS Word. Maybe it doesn't matter since this is a different animal and you might not swap one with the other anyway. If we are to do anything beyond the basics with it, it looks like it would be a lot of work. The plugin system looks beautifully simple at its base, but the actual implemented plugins look surprisingly verbose/complex for what they do. We couldn't use our existing Inputfield modules for new blocks (like an Image block) and so would be starting from scratch on a lot. I've also spent some time with Bernhard's editor (he sent me a demo) so will also come up with a benefits/drawbacks list for that. Interested in any other approaches you think we should look at also. Regardless of direction, my plan is to bring live preview and auto-save into the core, as I think all builder directions would benefit from that. Also, I want to mention the RepeaterMatrix stuff discussed earlier is something we'll be doing either way, I consider that just part of regular updates to the module, and so that's a separate project.

@flydev ?? Thanks for posting that, I've learned something new about editor.js. My experience with it is mostly limited to their own demo, so I'm really just looking at it from an outsider perspective. The tool is more powerful than it looks at first. I was particularly impressed with your integration of ProcessPageEditImageSelect. Nice work. It looks like you are pretty far along with this module and it also looks like it will be a great tool for PW users. When do you think you'll be releasing it? Interesting, what you mean exactly ? From what I can tell, editor.js is one big input element, kind of like a rich text editor, even if it also isn't. I think this is also compelling, and what makes one draw comparisons to CKEditor. So editor.js could be represented by a PW Inputfield, but it couldn't itself contain other PW Inputfields (as far as I understand it). Whereas something like a Repeater is an Inputfield that contains other Inputfields. If a block in a builder can be represented by a group of Inputfields, then that means that the types of blocks you can build can be very flexible and modular. The benefit being that it expands the means by which you can extend it. On the flip side, it also means that it's not something you'd ever compare to an RTE because it's just completely different. Editor.js seems to find a nice middle ground between RTE and block builder. It does appear that every block type is defined by a PHP class, but I'm not sure if that also corresponds to a template (?). Templates are a resource best limited to not use any more than necessary (since they all have to be loaded on every request), which is why RepeaterMatrix limits itself to 1. Though maybe something like block types aren't huge quantities, I don't really know. Such a solution would need to come with several predefined block types, just as editor.js does. I think this builder focus is important, otherwise it's becomes too abstract, at which point something like editor.js with plugins becomes a clearer answer. So I'm hoping that people could get up and running by selecting existing block types rather than having to always create them. Then they can create them when-and-if they need too. When it comes to code definition, it comes with its own benefits, and I think it's fine so long as the built-in defaults/types are strong enough to answer the most common needs. Getting into this level of stuff is where the RepeaterMatrix upgrades should help. But this level of complexity I think would hinder a simple builder for the larger audience. For this particular project, I think it's best if it focuses exclusively on content tools and doesn't get into layout and style aspects. This is one of the things Jonathan and I talked about. I'm investigating options for alternate storage methods of repeater items, such as the ability to save all the content JSON encoded in the 'data' column of the repeater table (rather than saving in separate pages). It would be an option you can choose in the field settings. I'm going to try and make it happen though it's possible I may hit a roadblock, so will have to get further along before I know for sure. I think editor.js is also an answer to what many people are looking for, so we have to be careful not to lose sight of what it does well. While there are things to learn from it, I agree it probably doesn't answer quite enough of what we are looking for. Good ideas. Improvements to RepeaterMatrix are part of the plan. But that's going to be a separate project. The $page->meta() method exists for this purpose, at least from the API side. Though the values are still stored in the DB, but not as field data, just as flexible unstructured data stored for each page. The Combo field might offer potential here too, as you can bundle as many inputs as you want within a single Combo field. Though it's still technically stored in field data, and still as searchable as any other field data. But without the being a separate dedicated field and having a separate DB table for each component, etc.

Thx @MrSnoozles 100% agreed. I see two possibilities: Anybody providing PRs Anybody funding/sponsoring further development of RockMigrations by me I'd love to work more on my modules, but I can't do that all in my spare time ?

bd() and d() - I've learned SO much about ProcessWire and PHP and OOP in general, can't thank you enough @adrian console - it's a dream to work with! request info panel - invaluable, especially when working with RockMigrations user switcher - handy refresh feature - modules refresh not moving away from current page That one is also great for working with RockMigrations: Usually I create a migrate() method that is triggerd on modules refresh. Then I can add a new field for example to a page and when I'm editing this page, I add the new field in code and just hit "modules refresh" via tracy and I end up on the same page edit screen just with a new field ready to be populated ? Oh and I've been using adminer for backup/restore lately quite often...

PS: I'm in gereral very interested in a solution for "non-db-fields". Meaning fields that are code-only and do not live in the database as their own tables. That's what rockmeta does and it is great for many situations where I definitely do not need to query those fields via selectors or rockfinder. For example I can add a checkbox to a "headline" field that says "capitalize headline" and if checked, well, the headline shows capitalized on the frontend. Or another checkbox that says "add more space above this headline", or another one that says "center this headline". The great thing is that those inputfields can live anywhere on the page editor - in my case they are even part of another inputfield (and not as a separate checkbox as they were if we built regular checkbox fields in PW): So I agree such a feature would be great to have. Maybe not for the whole page-builder field but maybe as an option for fields in general? So we could have a page builder field and as one content block we could have such a JSON-field where one can input an address for example (forename, surname, street, zip, city). RockMeta does not work with multi-lang fields at the moment. Just saying ?

Absolutely true and I've had a chat with @ryan about the same topic yesterday. What I forgot to say (thanks for bringing that up here @Ivan Gretsky) : I totally agree, that there should be a UI for beginners or non-coders to achieve the same things. I just didn't implement it in RockMatrix because it's a LOT more work and - of course - I don't care about that option. But what I want to say is: Please develop such modules with an API-first approach in mind. Just like ProcessWire was built in general: First comes the great API, second comes the UI (eg the PW admin that is built on top of that). I've had several requests from all over the world for better supporting RepeaterMatrix in RockMigrations. And it often felt hacky to get that working. For example matrix item names are somewhat concatenated strings like matrix{type}_whatsoever (https://github.com/BernhardBaumrock/RockMigrations/blob/16b9029c5aa46099f9a57391bfbf167229776f98/RockMigrations.module.php#L374). I think if all modules were built api-first that would have lots of benefits: Migrations would be easier, quality of code would improve and so would maintainability. I don't see any downsides. I'm not sure about this. I've built RockMeta which is basically what you are saying but a lot less complex. It stores single field values in page meta-data. For a complex field like a page builder with different types and different fields this would get a lot more complex (just a feeling). And not to forget: Data queries would be totally different from how processwire works at the moment. That could be a problem for page finding operations (either internal pw selectors or using RockFinder). Whereas if everything is just pages and fields, things are so simple, clean and beautiful. ProcessWire that is ? Just throwing in some thoughts - I'm sure ryan will help us find the best solution ?

It wouldn't be a bad thing to have a filter box too, although I don't think I'm familiar enough with the input labels to use that much myself. The Perfmon module looks good - I hadn't seen it before. Honestly these features aren't something I need on a typical project - I just thought the timeline looked cool. If I needed to focus in on performance I would try Perfmon, and I have Profiler Pro but haven't actually explored its features yet. I do have another idea/request though... What do you think about adding a Shortcuts panel? This would be for custom internal or external links that a user finds they are needing to visit regularly during development. For instance, I often need to visit the LoginRegisterPro config screen during development. And you could add links to various external API documentation pages that you want to jump to quickly. Sure, you could use your browser bookmarks but mine are already an out-of-control mess, and by having the links in a Tracy panel it would keep them nicely connected to a project. I'm imagining an interface that lets you enter a label and URL for each shortcut - a textarea would do, or you could get fancy with some kind of repeater-like interface. It would be good if absolute internal links were converted to relative links (i.e. strip out the site root from the URL) so the links keep working if the root URL changes.

I just hit [enter] at the end of the line, like in CKEditor, a new paragraph is open.

This is a great topic! I would love to learn more about the features of Tracy Debugger. I did start to read the docs a few times, but never had time to proceed)) As for me, I actually do not have a lot to share, as I only seem to use: the great bd() and the dumps recorder, and the bluescreen (you can't avoid that, but it is really helpful anyway), and the console once in a while to test selectors or something minor like that, and the donate button every time I install TracyDebugger on a site, ...but nothing more advanced, really. Would love to learn new tricks though)

There is a module that does something a bit like this already.

From an article @szabesz linked to earlier... No idea how difficult it would be to show a cool timeline like that, and probably something that would be better done in the Tracy core. But it looks nifty!

I like @bernhard's approach where every content block has it's own template (if I am getting it right). I also wrote that "Repeater Matrix should be PageTable Matrix" back in 2018 (though I never did try to fix that as @bernhard ?) This way you can easily move content-type-templates between projects. Though I am not that sure that on-code-only solution he proposes for quickly creating/duplicating/moving those templates would suit most of the users. A decent UI for that should be in admin too with the ability to be extended with hooks, but that is built-in anyway; RepeaterMatrix got it right with the ability to create types on the fly, but that at a cost of putting all the fields in the same template). There are other points not covered, like nesting, defining parent/child relations (for creating blocks with nested elements, like wrapping a header, a text and a calculator with some custom background like here), crafting a grid for column design (we can get around by creating a lot of custom sections, but would be great to do it more easy), copy-pasting content from one page to the other. I am not sure this can be done easily, @ryan but can we at least have another look at "The data storage" part of my previous post. If implemented, it could solve a lot of problems, making our builder a lot like editor.js while reusing a lot of goodness ProcessWire already has. If it is not possible at all I think that @bernhard's way is great (with UI improvements, some of which can be borrowed from RepeaterMatrix). Any way, editor.js or alike do not seem to me a solution to problems we are talking about. Let's just watch at @Jonathan Lahijani's video, the Bard field video again) Editor.js could be a one field inside of some blocks of our builder though.

If you are maintaining a module that has a reasonable amount of activity in its support topic, paired with multiple threads of questions, developments or talking points, you may request a dedicated forum so that discussion can take place in different topics. PM me if interested and we will make a decision on a case-by-case basis.

Hi @adrian, You already kindly added some quick links to the Tracy config at my request, but I still find the config interface quite overwhelming. What do you think about implementing a tabbed interface so it's easier to focus on a subset of the config fields? I've posted a demo module that might be helpful: Depending on how you think it's best to divide up the config there would probably be more tabs than could fit in one row. Currently I don't think AdminThemeUikit handles this all that well... ...but seeing as Ryan has recently been working on AdminThemeUikit it might be timely to see if improvements can be made. I'm not sure but probably it would be good if the inactive tabs had some definition of their edge, maybe a pale grey background and white border for separation between the tabs. I'll have a play around with that. Edit: the visual metaphor of tabs is always going to break down a bit when you have more than one row of tabs, but I think the below would be an improvement on the current styling. Editing on tablets and phones is going to become more and more common and the PW admin should cater to these narrower screen widths.

Wow - totally missed the discussion here!!! That's why the page-builder-part in my post in the newer news-thread was somewhat offtopic... I'll reference it here and throw it into the discussion ? Let me comment wildly on some statements first - I'll try to summarize that in the end... Yes, this makes sense. This is what I liked about that editor.js option, as it seems like (combined with its plugins) it's already a clean system for doing this. Interested to hear of others think this approach would be a good path to take. Please. No! I've done some research before starting with RockMatrix and editorjs was an option that I looked at. I decided against that approach. I can't really explain, but I had the feeling that this is some 3rd party concept and not the way ProcessWire would do content management. I had the feeling, that if we used something like editorjs we'd need to develop a totally new concept for all the content blocks. But WHY should we do that? WHY would that be better then using existing ProcessWire concepts? We have everything we need (speaking about Fieldtypes and Inputfields) and throwing that away would not be clever imho! Take a look at my matrix setup: First block is a headline - a regular PW "title" (text) field. I'm just removing the inputfield's header (we can already do such things easily via hooks!) Second block is a ckeditor field - similar, we remove the header and allow just a subset of usual ckeditor buttons. For example the image button is removed, because images are inserted via their own custom blocktype (gallery). That approach has several huge benefits that by far outweigh the drawbacks: Blocks are PW pages, this means you can do all kinds of PW magic with them. Think of hooks, think of custom page classes, think of doing listings using RockFinder (for example I'm using RockMatrix to hold invoice items having a description, an amount and a price and I can simply query all those items with a simple find call like "template=invoiceitem, year=2020") etc.; What about Multi-Language?! How would one build an editorjs field that properly reflects the internal PW multilang system?? What about file uploads? We know that files need pages and corresponding folders... We use existing, proven tools (fieldtypes/inputfields) Exactly. That's what I've built my matrix field for and that's what I need in every project. @Autofahrn has also put a lot of work into that topic! That sounds great. My matrix field does not allow nesting and showing items side-by-side or dragging dem from one block to another. But so far this has not been a problem at all! Quite the contrary. My clients love the ease of use. Even Non-Tec people can build great looking sites within no time. See these examples: https://www.kaumberg.gv.at/naturparadies-kaumberg/wanderwege/bergsiedlungsrunde/ https://www.kaumberg.gv.at/gemeindeamt-buergerservice/aerzte-therapeuten/gemeindeaerztin-dr-alexandra-hutsteiner/ https://www.kaumberg.gv.at/gemeindeamt-buergerservice/gemeinde-mitarbeiterinnen/ And using the same content blocks for a totally different topic: https://www.kaumberg.gv.at/gastlichkeit-tourismus-betriebe/betriebe-in-kaumberg/ This is SO flexible. If they needed any new content type (eg Youtube Video) I'd just add another matrix block and they could add videos everywhere on their website. I'm avoiding the PW admin more and more. I'm doing most of my work in RockMigrations nowadays, because it turns out that this often is quicker and less tedious than clicking around through the admin, replicating the changes on dev/live, rolling back changes manually etc etc.; Using migration scripts on the other hand I have my code in GIT, can just copy over parts as needed (git pull/git push), or simply use MultiCursor in my IDE to change the "columnWidth" setting of multiple fields at once (does anybody want to count the clicks necessary for changing 3 fields' columnWidth setting in the PW backend? ? ). I don't want to say that the PW backend is bad. Not at all. I've even wondered what @LostKobrakai is talking all the time when he showcased his migrations module back then, but I want to say that the PW backend might be really nice to have for simple use cases and beginners, but it is definitely a burden when dealing with advanced setups (think of automation, CI/CD, maybe multiple people working on one project at the same time, etc, etc). But I'm not voting for editorjs route here either! When I looked at editorjs and how plugins are built, that was a whole new world. I don't know much about all those modern javascript related dev tools and I don't really want to learn them, to be honest. Maybe that's the problem and I'm not being fair. But creating a new matrix block in my case is simply creating one single PHP file that extends \RockMatrix\Block, that's it... And I'd love to see such a setup in the core or a professionally supported one as pro module ? Sounds great ? This gets totally easy when using RockMigrations!! That's another reason why a solid migration system should definitely be part of the core! Everything would benefit a lot from such a core feature - module development, devs developing sites and reusing parts, etc... That would be a dream. Though I say again that I much more prefer defining things in code. Building user interfaces can be soo hard, while adding a hook can be so simple, efficient and clear. For example defining allowed blocks in RockMatrix is done like that: $wire->addHookAfter('RockMatrix::getAllowedBlocks', function($event) { $field = $event->arguments(0); $page = $event->arguments(1); if($field->name !== 'rmtest') return; $event->return->add([ '\RMDemo\Headline', '\RMDemo\Markup', ]); }); Imagine you had to build this as GUI... Sounds not too complicated, because you could use an ASMSelect field that lists all blocks and makes them selectable and sortable. But what if you'd want to show some blocks only to some special user role and hide them for others?! A simple if-statement in the hook. Nearly impossible to build as GUI... *emotional* Please, don't ? I've created a video that hopefully helps you all to get an impression: I think it would be helpful to clarify WHERE this discussion should happen upfront. In the forum? Via e-mail? Opening an issue (I think that's not the right place)...? But yeah... thinking about it I can imagine that monitoring all those channels is not easy and must take a lot of time...

Yes, thumbs up from here also to focus on bard/editorjs level of "content blocks" instead of full layout editor.

Hi everyone, Thought I'd kick off this new dedicated support forum with a feature requests thread. Feel free to post your ideas for consideration. Cheers, Adrian

Hello all, sharing my new module FieldtypeImageReference. It provides a configurable input field for choosing any type of image from selectable sources. Sources can be: a predefined folder in site/templates/ and/or a page (and optionally its children) and/or the page being edited and/or any page on the site CAUTION: this module is under development and not quite yet in a production-ready state. So please test it carefully. UPDATE: the new version v2.0.0 introduces a breaking change due to renaming the module. If you have an older version already installed, you need to uninstall it and install the latest master version. Module and full description can be found on github https://github.com/gebeer/FieldtypeImageReference Install from URL: https://github.com/gebeer/FieldtypeImageReference/archive/master.zip Read on for features and use cases. Features Images can be loaded from a folder inside site/templates/ or site/assets Images in that folder can be uploaded and deleted from within the inputfield Images can be loaded from other pages defined in the field settings Images can be organized into categories. Child pages of the main 'image source page' serve as categories mages can be loaded from any page on the site From the API side, images can be manipulated like native ProcessWire images (resizing, cropping etc.), even the images from a folder Image thumbnails are loaded into inputfield by ajax on demand Source images on other pages can be edited from within this field. Markup of SVG images can be rendered inline with `echo $image->svgcontent` Image names are fully searchable through the API $pages->find('fieldname.filename=xyz.png'); $pages->find('fieldname.filename%=xy.png'); Accidental image deletion is prevented. When you want to delete an image from one of the pages that hold your site-wide images, the module searches all pages that use that image. If any page contains a reference to the image you are trying to delete, deletion will be prevented. You will get an error message with links to help you edit those pages and remove references there before you can finally delete the image. This field type can be used with marcrura's Settings Factory module to store images on settings pages, which was not possible with other image field types When to use ? If you want to let editors choose an image from a set of images that is being used site-wide. Ideal for images that are being re-used across the site (e.g. icons, but not limited to that). Other than the native ProcessWire images field, the images here are not stored per page. Only references to images that live on other pages or inside a folder are stored. This has several advantages: one central place to organize images when images change, you only have to update them in one place. All references will be updated, too. (Provided the name of the image that has changed stays the same) Installation and setup instructions can be found on github. Here's how the input field looks like in the page editor: If you like to give it a try, I'm happy to hear your comments or suggestions for improvement. Install from URL: https://github.com/gebeer/FieldtypeImageReference/archive/master.zip Eventually this will go in the module directory, too. But it needs some more testing before I submit it. So I'd really appreciate your assistance. Thanks to all who contributed their feedback and suggestions which made this module what it is now.

Hi everyone, I have always wondered how you folks use Tracy. This will help me to focus in on future improvements and it might also highlight features to other users that they might have overlooked. In that spirit, feel free to add a second list of your favorite hidden gems - maybe you don't these very often but you still value them when the need arises. Thanks for your thoughts.

Shetland.org is a website run by Promote Shetland which inspires people to visit Shetland, encourages people to move to Shetland to live, work and study, and attracts people to invest in commercial activities in the isles. We (NB Communication) have run the Promote Shetland service on behalf of the Shetland Islands Council since 2017, and as part of the contract undertook a project to redevelop the existing Shetland.org website. In this showcase we’ll highlight a selection of modules we used and what they helped us achieve. Visit the site: www.shetland.org Pro Modules ProCache We use this on almost every site we build. Indispensable. The cache settings used are pretty simple – most templates are set to 1 week, with the entire cache being cleared on save. We use ProCache’s CDN functionality to serve assets from CloudFront via c.shetland.org. We also use the API provided by ProCache to compile (SCSS), minify and collate our styles and scripts via $procache->css() and $procache->js(). We then use the URLs returned to preload the assets, making the site even faster! ProFields: Repeater Matrix Again, we use this on almost every site we build. Another must have Pro module. This module allows us to create a really powerful page builder field (we call it ‘blocks’) that handles the majority of the content on the site. On a simple development, we just use two block types - Content and Images - the latter displaying as a gallery or a slideshow. On this site we have 13 different types, including ‘Quotes’, ‘Video’, ‘Accordion’, and ‘Links’. Additionally many of these are configurable in different ways, and some render in different ways depending on the template and context. Have a look at the links below for some examples: https://www.shetland.org/visit/do/outdoors/walk https://www.shetland.org/blog/how-shetland-inspires-me-artist-ruth-brownlee https://www.shetland.org/life/why/teach-shetland-school NB Modules We also used a number of modules we've authored: Instagram Basic Display API Used to retrieve the 6 latest images from instagram.com/promoteshetland. Markup Content Security Policy Used to implement a CSP for the site. Currently scoring a C on observatory.mozilla.org – not the best score possible but significantly better than all the other destination marketing websites I tested (all got an F but one which was a D-). Pageimage Srcset Used throughout to generate and serve images of different sizes via the srcset and sizes attributes. This module is really useful if you are looking to optimise the serving of images to improve page speed times/scores. Video markup for YouTube/Vimeo This module was developed specifically for use on this website, as we wanted more control over the rendering of the oEmbed data. In the example below, the video thumbnail is displayed with a text overlay – when clicked the video (YouTube embed) opens in a lightbox. And a big shout out to… Page Path History The previous site was also built by us in ProcessWire, but a number of years ago now. The new site has significant changes to the sitemap, but 1000+ blog posts were also migrated. Instead of an .htaccess file with thousands of 301 redirects, we were able to use the functionality provided by this module to implement redirects where required, and in the case of the blog posts which were migrated via an import script, implement the redirects via the API - $page->addUrl(). ... The above is just a fragment of the features present on this site, and the development just a part of a much larger project itself. We're really proud of what we've achieved, and we couldn't have done it without ProcessWire. Cheers, Chris (NB Communication)

We sort of have this already - take a look at the Custom Links section of the settings for the Processwire Info panel. You can add links to any page on the site, including items under Admin > Setup. Of course this doesn't allow for external links. For external links, I could add an additional settings field for storing these, or we could go with a separate Shortcuts Panel. Semantically it would be strange having external links under the PW Info panel, but maybe that's OK? Any thoughts? I use the Custom PHP code panel for such a thing ? eg.: return ' <a href="/admin/module/edit?name=ProcessPageAdd&collapse_info=1" target="_blank">Disable automatic publishing conf</a><br> <a href="/admin/module/edit?name=ProcessPageEditImageSelect&collapse_info=1" target="_blank">Image handling conf</a><br> <a href="/admin/module/edit?name=ProcessPageEditLink&collapse_info=1" target="_blank">Link generation of InputFields conf</a><br> <a href="/admin/module/edit?name=FieldtypePage&collapse_info=1" target="_blank">Orphaned page references check</a> ';

I'll have to think about it a bit more to be certain, but most likely it isn't a problem. And what's in your screenshot above definitely isn't a problem. If we get into 100s of these kinds of templates then I think that's where I might start to worry and think we have to benchmark and find alternatives... but that's also the point where someone has gone well beyond a simple builder.

This tutorial is largely to remind myself of the sequence of steps, but if this helps someone else too, that's wonderful! I've recently moved several PW sites to another host, and I've been refining the order of steps to minimize downtime. Please note, this tutorial is for those moving a site from one host to another host, NOT for local computer to live host (although certainly the same general principles apply). This is written from the point of view where both web hosts have cPanel - for convenience I only use hosts which have cPanel. The nameservers are one of the last changes you'll make, so don't do that yet! In the old host, go to phpMyAdmin and export the database to your local computer. In File Manager, export your website files as a zip and save to your local computer. Do the same for your email files (e.g. inbox and sent folder). Please note that if you get a lot of email coming through, and/or if you do not plan to complete all the following steps quickly, you might need a more sophisticated solution so as not to miss emails while switching over. Think about what you want your new db, db user, and db password to be (I like to change all this for security reasons). Even if you wished to keep these identical, you couldn't, because your new host will automatically force a different prefix for the db and db user, so you'll wind up with a new db and db user name anyway. The next steps are all done in the new host. In MySQL Databases in the new host, create a new database, db user, and user password from what you decided above. Also, still in MySQL Databases, add that user to the database (this is surprisingly easy to forget). In phpMyAdmin, import the database you exported from before into your freshly created empty database. If your domain name is NOT the main domain name of your new hosting account, create the new domain using Add-on Domains. Otherwise, move on. Go to the main directory for that domain (if your domain is the main domain of your hosting account then public_html, otherwise the folder of your new add-on domain), and upload your zipped website files there and unzip. Go to site/config.php and edit dbname, db user, and user password so that they match the new ones you set up. At this point, be sure you at least have a plan for SSL before moving forward. If your host does AutoSSL that's probably the easiest, at least to get started. If not, or if you're doing e-commerce, look into purchasing a new SSL cert that fits your requirements, either through your host or via a 3rd party if your host allows installation of 3rd party SSL certs. Just as importantly as minimizing downtime, you'll also want to minimize the time your site is without SSL. Then, and only then, change your domain's nameservers at your domain name registrar to point to the new host. Once this change is live, set up SSL right away - however you want to do that is up to you. For cPanel hosts running AutoSSL, just go to SSL/TLS Status and click on "Run AutoSSL" - wait until that domain's status turns green, it could take several minutes. Finally, set up your email on the new host and move the mailbox folders over (don't forget the "sent" folder!) Optional: If you have Softaculous (which I highly recommend for its auto backup capabilities), go into Softaculous, go to "ProcessWire" and click on "Import" and go for the local option not the remote one. Select your site in the fields and it will automatically import your PW installation. Then to set auto backup schedule, still in Softaculous, go to "all installations" at the top right menu, then on your list of installations go to "edit" (the pencil symbol) next to your new domain's installation. Leave all details the same except for "Automated backups" - select your desired backup rotation options and then click "Save installation details".

We sort of have this already - take a look at the Custom Links section of the settings for the Processwire Info panel. You can add links to any page on the site, including items under Admin > Setup. Of course this doesn't allow for external links. For external links, I could add an additional settings field for storing these, or we could go with a separate Shortcuts Panel. Semantically it would be strange having external links under the PW Info panel, but maybe that's OK? Any thoughts? Also, just to let you know, that these links are actually stored as relative paths, rather than page IDs so that you can copy/paste Tracy's settings via my ModuleSettingsImportExport module and have them work on another site. Also, the appropriate icon is also automatically used. Note I have teppo's Changlelog, MikeRocketts's Jumplinks and ryan's Upgrades linked to, in addition to the default links which are added when Tracy is installed.

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.

Just want to say that I don't like it at all. Regarding overwhelming settings: I'm usually not changing anything ? But @Robin S's solution looks great!

Yes, something like this. Thanks.

I will edit the post, but it's just to show you that is possible to move easily blocks. For the pros/cons you exposed, I have the same point of view and I still think that CKEditor should stay the default editor in ProcessWire. Look at this screencast : Enregistrement #3.mp4 CTRL/CMD + C, S, X ok ? Interesting, what you mean exactly ? That's clear this is something to deal on client basis. Example on personnal experience : - Me, as I am not a content editor, I still prefer to use CKEditor. - A colleague, writing big wall of text, is scratching his head on CKEditor and edit content on Wordpress then paste it in PW ?‍♂️

@Markus Thomas - I just tried on 3.0.170 and it worked fine. Not sure if there was a bug there for a while that was fixed, but it might be worth upgrading and trying again.

We've finally created the first dedicated forum for a module so I'm locking and pinning this topic for reference. If you need to ask questions/give feedback, please start a new topic in this forum. Thanks!

Anybody still using this? Or has any ideas for a good replacement? v6.2.2 was the last version of Handsontable that was MIT, now one developer license costs $790... Not sure how long v6.2.2 will be usable without any updates...?! What do you think? I think that for input of tabular data the interface of handsontable is still the best I've seen in the PW world...

I expect you are trying to use $files inside a function or there is some other reason for it to be out of scope. Try: wire('files')->find()

I used some .xyz and .pw domains but for real projects. Not as dev/stage domains. I dropped the .xyz because users don't click them at all. You can have a #1 spot in the SERPs but still CTR is super low. At least in non-fancy or super small niches these domains didn't work out that well for me. Same content on a .com/.net and even .org workes way better. There are some areas users seem not to care at all. Like Linux or less usual topics as crypto, privacy and security. For client projects I use my regular domain - most of the time. Something like clientname.dev.domain.com .pw domains are... well... some kind of special as well. I kept most of them for the time being.

Flexible content or page building I've mostly used RepeaterMatrix for this. I think looking at some of the examples above, something in the core would be welcome and something with maybe a simpler interface too. Thing is, in my case, I still probably need the flexibility of what I can do with RepeaterMatrix but just making it even simpler for site owners once I hand things over is welcome. I'll have a think about it. Admin theme improvements 99% of the time all I really need personally is to maybe change the colours. It sounds silly, but anything that shows clients you're paying attention to detail is good - which is why I love that you can link their logo into the masthead and they like that, but colour scheme is the obvious addition if it's something we can just set with a colour picker or by entering a hex colour value or something in the admin theme settings. Improvements to existing Fieldtypes and Inputfields Decimal is something I really need for any site with pricing, or if trying to build any basic ecommerce functionality so +1 for that as I don't think it's something that adds significantly to the core hopefully. Seems small enough anyway. External API I have had more requests in recent years as a developer along the lines of "do you do mobile apps" and for all projects I want to use PW as a backend, so if there was a JS API I guess that would help (don't really know) but I also feel like some of the REST API activity I saw a few months back by someone (sorry, don't remember much!) would help with that. File/media manager and more file sharing options I think it's great to keep the current ability to upload images/files where they're needed in a page (and I know you wouldn't remove that) but if we could use tagging to help categorise images/files and that helps build the file/media manager feature that would make sense. I still think the point of initial upload would more often than not be when you need to upload the file for a specific page, but on a few larger sites I've found myself uploading the same header image to a few different pages because it was appropriate although they weren't in the same tree, and it would have been easier to re-use with a file/media that's tied to the file/images field, so in those fields if we had "Upload" or "Choose from gallery" as options - giving the ability to set a different description, tags and cropping for a single image depending on where we need to use it, and then the file/media manager is in charge of making sure when we delete one instance it remains in the other image field. Does that make sense? It comes up for me more often on larger sites, but also giving folks one place to look to see what images are already available can prevent repeat uploads of the same image. Sure it doesn't add much overhead, but it's still overhead. Not sure I've got the right solution there but something that doesn't require breaking out of the normal workflow is more intuitive in my mind. I think my point is that you don't always want to re-use the same image in a CKEDitor field, you might want to have it in a single/multi image field on more than one page and that's currently not possible to my knowledge. EDIT: I know you could maybe use tags to achieve this, or a field that selects files somehow like ASMSeect, but there are occasions where you want to re-use and re-order and re-uploading seems to be the only way. Maybe my use case is so unique though that it's too much to bother with the more I think about it. Seems pretty unique anyway.

Exactly what I'm working on, so I'm happy to share my knowledge (code) if there is interest! It seems that interest is there since 2015... https://processwire.com/talk/topic/9494-wire shell-an-extendable-processwire-command-line-interface/ Installation and usage are simple: Installation cd /to/your/project/root/folder # clone rockshell into the "rock" folder git clone git@github.com:baumrock/RockShell.git rock cd rock composer install cd ../ Usage # in your projects root folder # this will list all available commands php rock/shell ---- RockShell will then live in a separate folder "rock" beside "site" and "wire", so everything stays clean. Also it can run without processwire, which is necessary for installation (of course) but might also be helpful in case of anything pw related does not work (500 error due to wrong config or the like). That's why I'd be very interested in using WireFileTools etc. without a running pw instance. I'd be happy to get some hints how that can be done...

I'm not sure I understand what you mean. We've got templates which define a Page's type in terms of fields, behavior and access. Then we've got custom Page classes which define a Page's type in terms of its API, which can also extend other Page classes. Then we've got Page tree/hierarchy/parents, which define their type in terms of location. I'm not sure what's left. ? Is there some other kind of page type you are talking about? I will update the AdminThemeUikit repo. Unfortunately I've run into some npm error where it wants to do some kind of updates before it will update the UIkit version, but updates it wants to do in npm fail. This seems to happen every time I want to update something that uses npm, but I always eventually find a way around it. This last one has had me stuck for awhile though. I'll revisit it here soon. I've never liked these command line package installers/managers because they always seem to have some problem without a clear answer. I guess it's the nature of the beast. In this case, you've modified the core _masthead.php. Don't do that. ? The intention is that an admin theme would provide its own _masthead.php file (or whatever you decide to name it). Actually I was thinking admin themes would replace all of the markup files. That's in part why they are all split out on their own. The updates added to AdminThemeUikit last week make it so that you no longer have to provide your own markup files if you don't want to, but for your case where you are changing method calls and include statements in those markup files, you'll no doubt want to have your own markup files. This gets into more overhead than I'd want to be involved for rendering the admin theme... at least for the core default one (AdminThemeUikit). I've even tried to actively avoid the traditional type of hooks here, so that the admin theme itself doesn't add its own overhead to the request. There's nothing faster than include() of a php file to render something, so that's the strategy AdminThemeUikit takes. Admin themes use a different kind of hooks for adding markup in parts of an admin theme, and they actually aren't really hooks at all, even though I still think of them as being a type of hook. You can call $adminTheme->addExtraMarkup($name, $value); to add extra markup to various parts of the admin theme. Any module or admin template code can do this any time during the request, up until the admin theme gets rendered (at the end of the request). The $value is the markup you want to add, and the $name is a region name where any one of the following are currently recognized: "head" - adds markup before </head> "masthead" - adds markup in the div#pw-mastheads "notices" - adds markup after the notices/notifications "content" - adds markup in div#pw-content-body "sidebar" - adds markup in #pw-sidebar, only if theme uses a sidebar "body" - adds markup before </body> "footer" - adds markup in footer#pw-footer This is the strategy that the admin themes use to support other modules in adding markup where necessary to the admin theme output. This is faster and simpler than using a traditional hook. More region names can be added easily if/when we need more. If developing your own admin theme, then you don't need hooks or the addExtraMarkup() function because you can already override anything in the AdminTheme you are extending, you can provide your markup files as needed, and add your own methods as needed. Admin themes should still support markup added with addExtraMarkup() though, but it's easy, just $adminTheme->renderExtraMarkup($name); at the appropriate spots in your admin theme template files. If there's anything I can add to make it easier for people to have a dashboard page, I'm happy to. But I don't currently think it should be built into the core. The core doesn't have anything worthwhile to communicate to admin users in a dashboard, so it would just be extraneous fluff (i.e. "numbers", "more numbers", and "numbers again"), like it seems to be in most systems. The kind of stuff that makes a simple system look complicated. Others may have something specific they want to communicate to their logged in users, and that's where I think it becomes worthwhile. If there's demand for it, I'd be more interested in hearing not about a dashboard, but about what one is wanting to communicate with it. Thank you for continuing to develop this. I agree there are benefits. This may be something we should keep talking about for the longer term. With the exception of WireMail, all the classes you mentioned are intended to be available for standalone use. Though it's been a long time since I've used any of PW's classes in that way. This I think is likely an easily attainable thing to support though. Most of the mentioned classes just extend the Wire class, making it the only dependency (and Wire doesn't require a DB connection). A DB connection would be needed for WireMail because it is a module type. Installed modules are known from the database modules table. A WireMail module also maintains its settings in the database. Now is is true that the base WireMail class can operate without a database, but WireMail is only useful because it is a module type. Take out the module aspect and WireMail is just an interface to PHP's mail(). The core datetime field is meant to store a single date/time, but that's it. I agree that sometimes a need arises for more than a single date/time. ProcessWire core is meant to focus on the basics, while supporting modules to accommodate a broader set of needs when they occur. I think this is a good example of a need that is nicely accommodated by a module that you've developed. Thanks for sharing the strategy you are using here. It's great to see the different solutions people are working with these last couple of weeks. From the screenshots I really like the approach you are using here. It looks powerful while easy to understand and client friendly. Yet also looks very PW familiar as well. Visually it might be the clearest I've seen, even relative to something like The Bard. The means of definition does also look simple, though I think for something that other developers would use, they might prefer that the front-end rendering be isolated from the back-end component. Something that makes it easier for you to provide pre-written components, while they provide the front-end markup. For instance, maybe the render() method delegates to a front-end template file somewhere in a subdirectory off /site/templates/fields/? And if there is not file, then maybe it provides a default output. The reason repeaters store their pages off in the admin structure is to solve these things. But it does come with its own challenges as well. Most likely I wouldn't be able to make any more commits to the core if I got run over by a train. I've always thought this was one of the reasons to use open source, ensuring that when someone smacks the tracks, the code doesn't. But it's not just about being open source, the code also has to be clean and well documented so that others can easily take it on board. That's one reason why I put so much effort into code quality and code documentation. My intention is that the code is always ready for others to understand and work with. As for commercial services/modules, it's the same risk inherent with any product or service you pay for. While not open source, the Pro modules do have the same code quality and documentation as the core, and are not obfuscated or encrypted. If it sets your mind at ease, I'm 46 years old (not 76), and am very healthy. I run and lift every day, eat lots of salads, don't eat red meat, and don't participate in any dangerous activities. Most likely I'll be here for at least another 46 years. But if I'm ever derailed then I know the project would still be in good hands. Seems like it might be simple to do. Can you expand on this? When/where would you use it?

Hi @ryan thanks for the great info about the future of PW from last week and thanks for the condensed list above. I agree with most of what's already been said, but want to add some points as I've been heavily working on several mentioned areas over the last year. IMPORTANT: Admin Theme As mentioned I've been working on a better admin experience for quite a long time. This is an example screenshot of RockSkinUikit (which I'm not using any more): My key goals have always been easy things: Make it easy to change ONE main color which does look good in most situations (because the secondary colors are gray) Make it easy to change the Logo Make it easy to add custom CSS/LESS -------- I am now using a custom Admin Theme module AdminThemeRock that does look similar to what I've built using RockSkinUikit: Again: Custom color, custom logo, that's it! -------------- Another one: Custom color, custom logo: ----------- Another one changing only the main color (page tree example): ------------- Learnings: If the core changes, my theme breaks!! That's a no-go. I've had to add several custom hacks to my theme that make it out of sync with the core. But important parts of the theme have not been hookable, so that was my only option meaning I have to pull all changes from the core into my admin theme module. I guess nobody else is as crazy as I am and that might be one major reason why we have not seen any other admin theme modules... My theme uses the old admin theme repo sources, because we do not have any source files in the core... https://github.com/ryancramerdesign/AdminThemeUikit/ PLEASE add the source files the core or in a separate repo that we can fork or help with PRs!! I've added you to my private repo on github so that you can see all the changes that where necessary for getting everything to work. For all others, here's an example of how my dirty core hacks look like: getNav() and getSearchform() are hookable methods that I added to my module. I've also built a frontend module that I'm using on my sites. There I use a simple but very effective technique that uses one single render() method to render several code blocks that I organize in files: // file structure foo |-- foo1.php '-- foo2.php bar |-- bar1.php '-- bar2.php // code echo $uk->render("foo/foo1"); echo $uk->render("bar/bar2"); This keeps the files organised and makes it very easy to do custom modifications before or after a file is rendered: $wire->addHookBefore("RockUikit::render(foo/foo1)", function ... ); $wire->addHookBefore("RockUikit::render(bar/bar2)", function ... ); Using a dom parser like https://github.com/paquettg/php-html-parser would even make it possible to modify/add/remove single html elements of the returned output! Of course having custom hooks would be more elegant and performant, but I wanted to mention this option nevertheless. Support for a Dashboard-Page That's another big thing for all my pages. I don't want to show the pagetree to logged in users unless they really want to see it! Take this simple example: Or this more beautiful one: The latter is taken from the Dashboard module which proves the big demand of the community for such a feature! I don't want to talk bad about this module here, I've shared my thoughts in the related thread with @d'Hinnisdaël and should maybe go for a beer with him when all this covid thing is over, but IMHO the module has two major drawbacks that would not be necessary! 1) It introduces a whole new concept to the PW admin that is already there. The PW admin is built upon inputfields and it would be very easy to build a dashboard (or to be more precise, the dashboard widgets) using these existing tools. (this is built using inputfields). 2) Making the admin show the dashboard instead of the pagetree feels hacky in several situations. We've discussed that here: One problem is, for example, that the breadcrumbs do not work as expected any more. Clicking on breadcrumb "bar" in " foo / bar / foobar " would take you to the dashboard and not to " foo / bar ". ############################################ Would be great: Migrations I think the core and all modules could benefit greatly from easy api migrations like I have built in my RockMigrations module. It's far from perfect, it's not very well documented, but it does some things right in my opinion and that's why I have it in all my installs and nowadays have it as requirement for almost all my modules that I build. Why? Because I want to have my fields under control of GIT Because I want to write an easy setup file that creates all fields/templates/pages that I add to this codeblock Because I want to push changes to my live server without exporting fields via mouseclicks, then updloading json files, then going through a migration click-marathon again, when I can simply do git pull & modules refresh Because I want to be able to create reusable components easily. I know that one can do all that using the standard PW API and creating a custom module, but take this example and see how easy and clear things get when using RockMigrations (or even better a solid core migrations API): I've recently added an example module that shows how I'm using RockMigrations now: https://github.com/BernhardBaumrock/RockMigrations/blob/master/examples/MigrationsExample.module.php ############################################ Brainstorming: ProcessWire without DB We all love ProcessWire and it's tools, but there's one drawback: The great API is only available if we have fully installed version of ProcessWire available. That has been a problem for me when I tried to work on a module that installs ProcessWire automatically (PW Kickstart and now working on RockShell). Examples of such classes that might be useful even without a DB connection could be: WireData WireFileTools WireRandom WireTextTools WireHttp Sanitizer I know that there are several cases where DB settings are absolutely necessary (for example page data or sanitzier settings), but there are other frameworks, that show, that such a concept can work and make a lot of sense: https://nette.org/ One might argue, that this might be going too far... But if we are talking about the future of PW, why not thinking of something like this: // copy files to root folder include("index.php"); $wire->install([ 'user' => 'demo', 'pw' => $wire->random->alphanumeric("8-12"), ... ]); Or take another example: https://processwire.com/api/ref/wire-mail/ There's no reason why we need a running PW instance with a DB connection for such a code example. Of course I know that it's technically required in many places in the core, but maybe these places could be identified and removed in the future?! Or maybe PW could support noSQL or something? ############################################ Would be great: A better Date/Time/Range-Field (dream: Support for recurring dates/ranges) I've started a discussion here and as you can see the post got a lot of attention: ProcessWires date field is nice, but it is a PAIN to work with date ranges, to build calender-like applications, to get the proper entries from the DB, etc... Why? Because the only option right now is to add TWO date fields to one template and there the problems begin... What if you want to make sure that one date is after the other? What if you want to show all events of one month? There's a HUGE potential for bugs like "foodate < $lastOfMonth" should have been "foodate <= $lastOfMonth" How to get the timestamp of $lastOfMonth properly? An API like https://carbon.nesbot.com/ would be great! What if events can have a range (like from 2021-01-10 to 2021-01-15), but can also be a single day event (2020-12-24). What if an event is on one day but has a start and end time (2020-12-14 from 18:00 to 22:00)? What about timezones? How to do the proper formatting? Showing a date like this "2020-12-24 18:00 to 2020-12-24 22:00" is a lot worse than "2020-12-24 18:00 - 22:00". This gets even more complicated when you want to show the days... What if you want/need to handle recurring events...? ############################################ PageBuilder I've taken several runs on that topic and finally (?) found a good solution during development of one large project last year. My approach was to make a new Fieldtype similar to Repeater and RepeaterMatrix, but with some big conceptual differences (it's more like Repeater than RepeaterMatrix): Every item is a single page in the tree and has a custom template Every repeater item can live anywhere in the pagetree Every item is defined in a single PHP file (using RockMigrations to make it reusable) This makes the setup very flexible on the one hand, makes it reusable across projects (simply copy the file and do a modules::refresh triggering the migrations) and makes it REALLY simple to use for the clients on the other hand: Setting up such a block is quite easy: class Headline extends \RockMatrix\Block { public function info() { return parent::info()->setArray([ 'icon' => 'header', 'title' => 'Überschrift', 'description' => 'Fügt eine Überschrift auf der Seite ein.', ]); } public function init() { $this->addHookAfter("Pages::saveReady", $this, "saveReady"); } // this method makes it easy to customize the item's edit-form // you can change labels, collapsed state, add notes or custom classes etc... public function buildForm($fs) { if($f = $fs->get('title')) { // dont show label for this inputfield $f->skipLabel = Inputfield::skipLabelMarkup; $f->wrapClass('rmx-pd5'); // add class to remove padding } } // the label of the repeater item public function getLabel() { return $this->title ?: $this->info()->title; } // migrations for this item public function migrate() { // the parent migrate creates the necessary template for this block parent::migrate(); // then we set the title field optional for this template $this->rm()->setFieldData("title", [ 'required' => 0, ], $this->getTpl()); } // code to use for rendering on the frontend public function render() { return "<h3 class='tm-font-marker uk-text-primary'>{$this->title}</h3>"; } // optional saveready hook public function saveReady(HookEvent $event) { $page = $event->arguments(0); if($page->template !== $this->getTpl()) return; if(!$page->id) { $page->title = "This is my initial headline"; } } } As you can see in the screenshot, I'm using CKEditor for editing fulltext. That's great, because I can remove all plugins that do usually need more education for clients (like inserting images) and build custom blocks solely for this purpose that every client can grasp a lot quicker and where I have a lot more control and freedom (since the block is a separate template). This means I've always had the freedom of custom image fields even before the image field supported them. Another example: A gallery block (headline + image field): I'm not sure about the scalability of this approach, but having all blocks as custom pages is a huge benefit in many ways. For example I could create a Matrix field having invoice items. Each item would be a page of type "invoiceitem" and then I could query all "invoiceitems" using RockFinder and build an average invoice NET or GROSS value of all invoices of 2020... Access control, page status, etc etc are still challenges though, of course. ####################### I hope that all makes sense and I'm willing to share any of my modules code if that helps. Or give you a demo/walkthrough via screenshare. One last question, as we are talking about the future of PW: One thing is what would happen to the core of PW if anything happend to you @ryan. But we could at least fork the core and do... whatever then would be necessary to keep all our businesses running and all our clients happy. But what about all the Pro modules? We could not get a copy of them and work on ProCache for example on our own (as a community). Did you think about that szenario and have a reassuring anwer for us? ? Of course, I wish you a long life and many happy years of developing PW - it's absolutely impressive what you have built here ?

In this video, I demonstrate YOOtheme Pro's Builder (WordPress) and talk about its approach and benefits. I then demonstrate 3 different builder concepts in ProcessWire using Repeater/RepeaterMatrix, two of which are modeled after YOOtheme Pro's builder and their limitations along with some suggestions. ( @ryan ) (note: there are many more considerations when it comes to a page builder, but if there were some sort of css-framework agnostic layout tool, that would solve the biggest page builder problem) Please share your thoughts.

@Robin S I've pushed an update to the dev branch that makes it simpler to extend AdminThemeUikit. As far as I can tell, the reason you got the result you got before is because your admin theme was likely missing all of the other files that go along with an admin theme (?). So the reason you can't just extend AdminThemeUikit and be done with it, is because the module file is only one part of the admin theme. I've updated it so that AdminThemeUikit is now built expending that you might extend the class, without all the other files. So now you can create an AdminThemeUikit derived module like this: File: /site/modules/AdminThemeTest/AdminThemeTest.module <?php namespace ProcessWire; class AdminThemeTest extends AdminThemeUikit { public static function getModuleInfo() { return array( 'title' => 'Test Admin', 'version' => 1, 'summary' => 'Test extending Uikit admin theme', 'autoload' => 'template=admin', 'requires' => 'AdminThemeUikit', ); } } You'll also need this file in the same directory: File: /site/modules/AdminThemeTest/controller.php <?php namespace ProcessWire; if(!defined("PROCESSWIRE")) die(); require($config->paths->core . "admin.php"); The above would just be the same thing as AdminThemeUikit. But at that point, you can easily override and extend anything from the AdminTheme, AdminThemeFramework or AdminThemeUikit class. For instance, here the same module as above, but I'm extending the renderExtraMarkup() method to add some more markup to <head> to make the primary headline <h1> smaller (not suggesting this would be the right way to apply CSS though): <?php namespace ProcessWire; class AdminThemeTest extends AdminThemeUikit { public static function getModuleInfo() { return array( 'title' => 'Test Admin', 'version' => 1, 'summary' => 'Test extending Uikit admin theme', 'autoload' => 'template=admin', 'requires' => 'AdminThemeUikit', ); } public function renderExtraMarkup($for) { $out = parent::renderExtraMarkup($for); if($for === 'head') { $out .= "<style type='text/css'>" . "#pw-content-head h1 { font-size: 24px }" . "</style>"; } return $out; } }

@ryan I can collaborate with you on improving Repeater Matrix and giving you a really deep understanding of page builders, issues that would be faced and my thoughts on a direction ProcessWire can take. I've built a module internally that demonstrates a lot of these concepts.

Happy New Year all and thanks @ryan for all of your work. There are already so many ideas and requests, but here is what my current clients asks: Central media/image manager for reusing images across pages Support for different file storages for image like Flysystem

OMG! Senior moment.

Er, @DaveP, this IS that topic .

Perfmon Debug Toolbar is a Processwire module used in performance monitoring and optimization. This module has been kicking around for some time, but I finally got around to publishing it. The user interface is heavilly influenced by django-debug-toolbar if anyone is familiar with that project. During install, $config->debug must be set to true for the toolbar to run, the module is not intended to be enabled on production. The primary goal of the module is to identify bottlenecks and help tune up code. More information is here: https://github.com/KeeneState/DebugPerfmon Please let me know if you have any difficulty installing or running it. It's intended to be run on a development instance, though it can exist in a dormant state in production. Collapsed presentation (top right of screen): Expanded Presentation:

You can get it in a PHP section of your template files like this... $ref = $_SERVER['HTTP_REFERER']; Be aware that this variable can be unreliable as it is up to the visiting browser to send it and it can also be forged. Most of the time it will be correct though. More info here.