Leaderboard

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 ?

The Page Lister (a centerpiece of PW) is also in need of major improvement IMHO. The icons are not always in the same place due to page titles of different lengths, which is very annoying and distracts a good workflow. A tabular representation or other optimized view, would be better suited here. Here, again, everyone may have a different preference, so an option of which display type to use would be a good idea. This has been mentioned here before. I would be willing to work on a proposal for an optimized layout. Moving entries in the page lister, doesn't work very well and it's cumbersome. I found a great Tree JavaScript a while ago that implements drag and drop much better http://www.treejs.cn/v3/demo.php#_307 and was actually going to work on integrating it to PW, but unfortunately didn't have enough time. The looks of that script can be completely customized. Then I didn't know if it was worth it, since I know that many PR's just never get integrated and I also lacked the time. I had made first attempts, but noticed that the PageLister is very extensive and nested.

It seems like we gonna have a fascinating year! I am enjoying being here since 2014, but feels like the most interesting part is just starting!

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.

+1 for a solid database migration mechanism. Deploying field/template updates to production involves a lot of manual copy/pasting. Having a built-in way of describing changes in database structure would make automated deployments and rollbacks possible.

One of the things that bothers me about ProcessWire is the integration of the community into the development process. It is not clear which features or ideas will be implemented and if and how you can influence this decision at all. For example, it would be conceivable that within a period (for example a quarter) you look at which Github issues have the most thumbsup and then fix or implement them. If there are too many features, or they have the same number of thumbsups, you could also make a poll in the forum, what the community would like to have implemented faster. The pull requests sometimes are not integrated for years. Even if a control or a rewrite would be necessary for this, it would be good to have a feedback if the PR is "under consideration" or "won't merge" or "working on it" or a comment. Because the way it is now, it seems like the PRs are just decaying unseen and there is no point in working on this open source project. Ryan wrote: My preference is always that we talk about the PR before someone takes the time to code and submit one, so that we are on the same page about the goals and timeline for it, and getting all the details right. PR's that come in unsolicited are fine too, but they do take me a lot longer to get through. It would be nice if this was also listed in the Contribution Guidelines https://github.com/processwire/processwire-issues/blob/master/CONTRIBUTING.md These guidelines are also the place to say how new ideas or fixes are handled and under what conditions they are integrated. If Ryan discloses his criteria that he has as a requirement for features, enough developers might follow those guidelines when creating a PR. After all, it would be great if there were a few selected contributors and they could then merge PRs, or at least do a pre-review, so that Ryan has an easier time integrating them later.

If you think you've found a bug in WireDatabasePDO, please do open an issue for it in the processwire-issues repository.

First of all I want to say, that I am really enjoying the discussion about the flexible content builder or the WHATEVER-builder (as I accidentally named it earlier) we are having here. And now I am purposely not calling it more specifically Site / Content / Page / Layout / Theme Builder. I think that @kongondo made a really wise question asking to define the distinction between those. And to determine, what exactly do we want to build. Are we really talking about the different things? It seems to me that now we are contrasting the YOOtheme Builder from @Jonathan Lahijani‘s epic video labeling it as a layout editor or a site builder, to bard / editor.js calling them content block editor or something like that. And choosing between the two. But, as I understand, @Jonathan Lahijani never proposed a layout editor / site builder way in a sense that it should store the final html code and let the content editor to directly manipulate it. He intentionally made it clear, that he chose to show us YOOtheme builder because it “separates the builder-part from the actual content” doing it in a “ProcessWire way”. And he also stated, that he is not for tightly coupling to the CSS framework (Uikit in YOOtheme). But he would want the ability to define the layout IN SOME WAY, like being able to create a 2/3/4 column grid and place the components (I think that they are the same as content blocks from bard / editor.js) inside those columns. And to be able to move those components to desired slot in the layout. I would really want that part too) I think that the earlier mentioned “ProcessWire way” is actually the separation of content and presentation. When we use Repeater Matrix, we store the content and some meta information not directly in the html code, but in the Repeater Matrix Page’s fields. Actually, editor.js (do not know about the bard field, but probably that one too) is also storing the content separately from the presentation. Not in the separate database tables, but in one json object. So it is kind of doing it the “ProcessWire” way too))) One difference, is that in the case of editor.js we have to manually deal with json when generating actual markup, when Repeater Matrix provides us the comfortable PW API for that (making this way a little bit more ProcessWire). The other difference is that when using Repeater Matrix we have to manually create all the actual fields and assign them to content types, making this way more laborious. The coin has two sides. So, as I can tell, we all want the same kind of editor. The one that does not store the actual markup, but the one that stores data, that later we can render to actual html (or any other format really). What about the layout part? As I said earlier, I would really want to have the ability to define layout with the flexible content builder we are talking about. @Jonathan Lahijani showed 3 ways of doing it in current Repeater Matrix-based content builder, and all of them are kind of a pain. But I do not want our editor to actually store something like col-sm-6, but rather some generic layout information. Like having a grid block, that can only have col block as a child, which in it’s turn can store the actual components. In Repeater Matrix now we do not have a distinction between layout element and a component. We only have the ability to put one element inside the other (the ugly nested Repeater Matrix way or the repeater depth way which also has its flaws). But it is the developer who is responsible to make all the decisions generating markup. So the developer could choose to implement the layout part or not to do so, which is really a powerful stuff I enjoy and would like to keep. That’s why I was talking about the “WHATEVER-builder” or a “framework for constructing a content builder” before. To do so, our new flexible content builder should allow us to: define the allowed parents/children for the elements; allow to show the child elements side by side (to imitate layout); intelligently control the drag and drop, taking into account the allowed parents/children for the elements. As far as I know, editor.js does not allow the nesting of the elements. Creating custom elements from admin The other great thing about the Repeater Matrix-based content builders is that we can easily create new custom content types (elements, components…) right in the comfort of the admin. It is not really a quick thing, as we need to deal with creating the fields and assigning them, but it is rather familiar. And those custom components can use all the other ProcessWire data with Page Reference fields, Selector fields etc, which is cool. If we go with with editor.js, I am in real doubt we would be able to create the new elements in admin. The dev would probably need to develop a js plugin and install it in non-PW-standard way, making it unlikely to happen. The connection to other Processwire content from that custom element would be even harder to implement. Visual representation of the content Repeater Matrix-based flexible content builders in the mentioned video look nothing like the actual content. The left part of YOOtheme builder does neither, but it at least represent the layout in some way. Editor.js / bard do not do that too. From the other replies in this thread I see, that it is not that important and even not desirable. Repeater Matrix interface is kind of ugly, when representing content. But: at least is is familiar and in line with all the other backend; it could be improved to be more like YOOtheme builder: add icons for adding content types, remove or refactor the repeater elements “chrome”, allow showing repeater elements side by side for the layout thing; and it uses the standard admin form ui, which means it is easier for @ryan to deal with. As you see, I am for the native ProcessWire UI here) And one more thing. In the video we see the actual markup rendered to the right of the YOOtheme content editor. We can do that also, creatively reloading THE WHOLE PAGE on changes with Hotwire / Unpoly / Vue. Making the flexible content builder feel dynamic and not requiring those saves-and-reloads. And making the connections between the options in the builder part and the final markup obvious to the editor. The data storage Repeater Matrix-based flexible content builders store the data in pages and fields. This makes it laborious to create new content types (create a new field, or find an existing one to reuse it, assign it, override it…) This also makes it hard to duplicate, copy/paste content in the site or between the projects. But it also allows us to use the familiar API when generating markup. Editor.js’ data object is compact and probably easier to be reused. But it lacks connection to other PW data. And the UI is totally different. Could we combine the benefits of the two? What if we invent the json-based storage for the data gathered with regular ProcessWire inputfields? Something like Mystique field combined with JsonNativeField (so the content is even searchable). And what if we allow to create the Interface for the new flexible content builders components with “fake” fields, which have their inputfields only, and are not connected to the database? Kind of like fields for the Form Builder or the UI for the @adrian’s Admin Actions’ actions. Think about that. We could design elements with any fields we need not messing up the regular fields namespace. Those fields’ definitions would be stored in our flexible content builder’s options, as well as all the content types (elements) and the actual field data in json. The UI would be the same inputfields we already have. When working with this field from the API, the field could be accessible as a PageArray object where each Page is a corresponding element. Bringing it all together I think it is possible to build the flexible content builder (or the WHATEVER-builder) using a lot of the technology we already have in PW. It can be comparable if not better than all the other competition. It can be well integrated and totally configurable through the admin. It can be portable between templates and projects. And it can be visual and responsive. What do you think?

@ryan Now we have custom page classes that I'm really like and I use it on all of my current projects, but maybe the same approach can be applied to custom page types? And one more request is the ability to deactivate the default language for page, I know that it could be implemented by custom field and some logic in hooks, but maybe such functionality could be added to InputfieldPageName. Thanks.

Currently version 4.7.0 of Font Awesom is used in ProcessWire for icons for templates and fields. Since its release, both version 5 have come – and version 6 is in the making. I would like to see a newer version in the future in ProcessWire, @ryan 4.7.0 (in ProcessWire) has around 675 icons as far as I can tell. The current Font Awesome version has around 1600 icons. When version 6 comes, theres around 2200 icons I have read.

Hey @ryan. Just a quick heads-up that I opened an issue at the TfaTotp GitHub repository about the required code format: if the app provides a code such as "123 456", TfaTotp requires me to type it in as "123456" for it to work, i.e. the app-provided format won't let me log in and the error message just states that the code was wrong. Seems like something that should be handled by the core or the TFA module (not sure which handles taking in the input).

I just wanted to be sure that it wasn't me just trying too hard to find a bug for my problem, but I will go ahead and fill one on Github. Thanks again. Edit: we'll see how it goes

+1 ?

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

Based on the Modules class it looks like module versions are checked by Modules::checkModuleVersion(), which gets called when individual modules are initialized (Modules::initModule()). From here on I'm largely guessing, but what I'd probably try first would be iterating over all modules (assuming that you want this to occur for all of them) and then calling something along the lines of... if ($modules->isInstalled($module_name_or_class) { $modules->get($module_name_or_class); } ... for each of them — first check is just to make sure you don't accidentally install all modules, while get should trigger upgrade check (if I'm correct, that is) ? Sounds a little hacky, not sure if it'll work 100% or if there's a more straightforward way. I couldn't spot one, though.