Leaderboard

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.

If your module has a lot of config fields you might want to divide them into groups inside a tabbed interface. Here is a demonstration module showing how this can be done. https://github.com/Toutouwai/ModuleConfigTabs Thanks to @kixe for providing my starting point in this forum topic.

Drag and drop is only easy as long as the target is in the visible viewport. As soon as one needs to scroll while dragging, it becomes a really challenging thing to do, even in native applications running in modern operating systems, not to mention JavaScript based GUI apps. Providing both means of reordering should be the "solution", if possible. At first sight, my clients think they can deal with it as it does look familiar indeed. However, it has rather quirky behaviors when adding/removing list items, adding/removing line-breaks, and last but not least the horrid feature of injecting styles when pasting (which can be partially dealt with but never properly). So in the end my clients are always confused by the quirky way of using CKEditor. And we should go beyond the basics, so currently personally I prefer Berhard's approach, simply beause it looks like that it is a more realistic project in the long run.

As @Robin S noted in the post that @3fingers linked to - that example is a Page reference field. I just recreated that here and it works as expected: A little OT, but creating Page Reference fields is really quick and easy with: https://processwire.com/modules/process-page-field-select-creator/

Great - thanks. One thing to note here is that it is of course possible for one of these superusers to go to Tracy's settings and uncheck that "Restrict superusers" checkbox, or even give themselves the "tracy-debugger" setting. I am guessing you don't really mind that because it's not that they aren't trusted, but rather you just don't want to confuse them with Tracy. Anyway, just something to be aware of in case you hadn't thought about it. That "tracy-debugger" permission has been around forever and already allows you to give non-superusers access to Tracy. The only restrictions by default are that they don't have access to these panels: Console, FileEditor, Adminer, Terminal, AdminTools. You can also restrict them further with the "Disabled panels for restricted users" setting.

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...

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.

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 ?‍♂️

Hi @Robin S and @szabesz - thanks for your input on this. This is going to be an interesting one because I actually don't like AOS's jumplinks for the reason that I can't use CTRL/CMD +F to find the setting I am looking for - I often have to enable/disable several sections before I find the one where the setting I am looking for is hiding. A tabbed interface would have the same issue. I feel like Tracy's approach to having everything open and displayed with those quick links (that are at the top of the settings) together with CTRL/CMD +F is actually pretty effective. There are also of course the direct settings links at the bottom of each debug bar panel which further helps to get you where you want to go. Of course this might be my bias because I already know the names of the settings so I know what to search for. With my thoughts out of the way, I have had enough comments over the years about how overwhelming the settings are that obviously I need to listen to you guys and improve things ? Robin - I have used tabs in module settings with AdminActions - I think it can be a nice interface, but in addition to my noted concerns above and your noted point about the tabs ending up over more than one line, some of the fieldset names (labels) are quite long - I can probably shorten many of these, but it is another issue to consider when using tabs. Stepping back a little - I wonder if we can solve some of the confusion by eliminating some settings - I have probably overdone things with settings that no-one will ever change. To be honest, I almost never change any settings beyond those in the first couple of fieldsets and the email address for error notifications on live sites. Maybe it would be best to have all the settings that are likely to be used by most people, open and up top and everything else in a collapsed "Advanced settings" fieldset. Maybe we need to do a bit of a survey to figure out what most users find themselves regularly changing and use that as a guide. On a side note, I often make use of https://processwire.com/modules/module-settings-import-export/ for copying settings between sites - maybe promoting that approach would also help? Any other approaches we should be thinking about? OT, but I am thinking that maybe this settings improvement feature request deserves to be split into its own thread. PS - Robin - I completely agree about the need to improve the styling of inactive tabs in th Uikit theme.

Thanks, that worked perfectly. This could also be a way to open it up to non-superusers? I don't have a use case for that, but maybe there are big projects out there like intranets where you might want to show the debug panel to a tester who checks through the workflow or something but might not have full superuser access to the backend. Probably best left to superusers though maybe and this works for me - thanks!

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.

Hi @Pete It was actually a bit fiddlier than I expected so I am going to hold off on committing the changes just yet, but can you please test the attached version for me? There is a new "Restrict superusers" checkbox in the settings. Check this and it will mean that you need to set up a new role with the "tracy-debugger" permission and add that role to your admin superuser account. All other superusers without this won't have access to Tracy. Please let me know how it goes. TracyDebugger.zip

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!

great ? Also reasonable and clever ? I'm sure the interface can be improved a lot more. Just did not have the time for that and had to get things done and work with what I have... Yeah, that's true. With one difference that I can define WHERE the created pages live. Usually they live under the page /rockmatrixblocks, but that can be totally up to the user. Not sure if I'm using that "feature" anywhere or really need that. But thought this might be good to have one day... For example one could create a site of team members of a football club using RockMatrix and all the players would still be a regular PW page that can be visited on the frontend, but can be sorted and quickly edited via RockMatrix GUI. One can think of it as an extended page reference field (like ASMSelect). Regarding the overhead: I have thought of that, and I don't know how my setup would perform on large scale. But my feeling was that PW is built for handling millions of pages, so why should it not also be capable of handling millions of matrix blocks?

I don't have any strong opinions here, just a few observations. I like the editor.js strategy, but I also like Bernhard's strategy. For example, I like the "something new and interesting" aspect of editor.js, and I like the "something clear and familiar" aspect of Bernhard's. His screenshot is immediately clear how it all works. I don't speak the language of the headers, content and buttons, but it's all still obvious how it works and what it does. That says a lot. To my eye it's more clear than editor.js at first glance, though I've used a lot of ProcessWire and very little editor.js, so I would trust others' judgement more. One major difference is clearly that Bernhard's approach uses pages in the same way that RepeaterMatrix does (I think?) whereas editor.js uses a block of JSON. There are benefits and drawbacks to each approach in terms of storage and overhead, but from a familiar API side, the pages approach is a good and known factor, even if it is likely a bit overkill for this type of storage (as it can be with many repeater cases). This already appears to be built in ProcessWire and already in use (?), that's quite a head start too.

@LostKobrakai In addition to what I've mentioned above, I openly admit I'm not great at PRs, if that's what you are looking for an admission of. I try and make up for it in other areas. Nobody is perfect and one area I have work to do is getting better with PRs. I stated earlier that this is a priority for 2021. I will revisit the PRs that you mentioned. Maybe some think it looks bad to have open PRs, but to me it looks like enthusiasm, ideas and potential. I consider it an honor anytime someone would want to contribute in this way. I actually think the majority of PRs have a lot of merit and like what I see. I almost never would say "no" and close a PR in the way you are suggesting, because I almost never would feel that way. Instead, I look for the same crossover of priorities and timing that I do when it comes to adding new features. I like having a solid repo of PRs because it's stuff that is available for when the time is right and stuff I can refer back to and know someone else is also interested. All open PRs are a "yes" in my mind and just a matter of timing. Though going forward my hope is to find more time to cover open PRs even before the timing is right, since the community has indicated this would be helpful in appearances. PRs only don't age well if taken as literal code, which is not the way I work with PRs. It doesn't matter to me if the literal code has not aged well or not because it's the ideas that matter much more. Whether PRs or not, and whether my own code or not, I go through code additions line by line multiple times, often writing and re-writing, both for QA and to fully understand the logic... so I do not care about age of any particular code. I just care about the idea, getting it right and being able to support it for the long term.

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

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.

Happy New Year! Today I’ve bumped the version on the dev branch to 3.0.170, and it’s quite a lot of updates. This post covers most of them. In this post, there’s also a question for you: what would you like to see in ProcessWire in 2021? https://processwire.com/blog/posts/pw-3.0.170/

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.

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)

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!

@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(); } }); });

@szabesz your Tampermonkey script should looks like this: // ==UserScript== // @name New Userscript // @namespace http://tampermonkey.net/ // @version 0.1 // @description try to take over the world! // @author You // @match http://domain.test/pw/module/edit?name=TracyDebugger // @icon https://www.google.com/s2/favicons?domain=domain.test // @require https://cdnjs.cloudflare.com/ajax/libs/jets/0.14.1/jets.min.js // @grant none // ==/UserScript== (function() { 'use strict'; $("#ModuleEditForm").prepend('<input type="search" id="jetsSearch">'); var jets = new Jets({ searchTag: '#jetsSearch', contentTag: '.Inputfields' }); })(); the @match parameter is the URL where the script will run each time your browser visit it.. then you will see a small form input before the Module Information Fieldset

Interesting read about "Golang vs PHP (Symfony4)". https://dannyvankooten.com/from-go-back-to-php-again/

Another, somewhat similar story: https://medium.com/vimeo-engineering-blog/its-not-legacy-code-it-s-php-1f0ee0462580

I do not want to pollute this thread with my silly issues with Tampermonkey. Enough to say, I got stuck again.... I will read its docs and watch its tutos when I have time to do so. Certianly looks powerful...

Yes, you should use the pin icon to keep the extension visible

Chances are you already have too many browser extensions installed to fit - the last one on the right will let you access the hidden ones.

@Zeka Currently you can create a class like BlogPostPage and it automatically be used as the class for all pages using template "blog-post". You mentioned the PagesType class, which is used by things like Users ($users), Roles ($roles), Languages ($languages), etc. as an alternative to the $pages API var. To make sure I understand what you mean, are you saying that you'd like to be able to create a class like this: class BlogPostPages extends PagesType {} And then you'd get this API var ($blogPostPages) that limits itself to pages using template "blog-post": $posts = $blogPostPages->find("date>last year, sort=date"); Is that what you mean, or something different?

From the blog post you've linked: Radio input (like the "License" one shown in the image) looks like is not mentioned there, so yes, to me it looks like a misleading example. I read somewhere in the forum that ryan has the intention to make some polish on custom image field, but honestly I don't remember where.

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.

+1 Maybe @tpr's solution in AOS can be implemented? I like his "jump links section" a lot.

@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.

Your timing is excellent - I have a couple of projects where for one reason or another (sometimes it's on purpose) I have customers that are superusers and I'd like a way to exclude specific superusers from seeing Tracy if possible?

This gets an A for awesome! And big thanks for the modules. They look pretty neat as well.

Fantastic site all-round and a great write-up here. Well done on the project, and thanks! ?

Hi @3fingers, Both a and c are part of an internal (proprietary) GraphQL API implementation. The short explanation is: A GraphQL query is generated from the filters when the form is 'submitted' The GraphQL endpoint is queried and returns results The result is rendered b would take an age to explain properly, but basically the query string ends up in sessionStorage (JS) and the filter strip JS checks this to set the active option(s). When the filter options are changed the sessionStorage values change too so that the state is essentially retained throughout the user session. I can't give you any indication on budget unfortunately. We run the Promote Shetland contract, which is much more than just the website, so the redevelopment project is effectively 'in-house'. Timespan was just short of 6 months (design/development) I think, I wasn't involved in the early stages so can't say exactly when it began, but my involvement as developer started in August and we launched mid-November. Cheers, Chris

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.

@ryan Sorry for being not clear enough. I was talking about the ability to specify custom Page classes and especially the ease of use when you only have to change some lines in the config and all classes and files have their place and get autoloaded. I was thinking that it would be great to expand such behaviour to classes that extend the PagesType class. Take a look at this tutorial https://processwire.com/docs/tutorials/using-custom-page-types-in-processwire/ While it still actual, there is an easier way to deal with custom Page classes. That what I meant. Thanks

@bernhard That looks awesome! @Kiwi Chris I'm sorry to hear about what you've had to go through there, and I'm glad that you made it through all that and are doing well. I didn't say never. We're all doomed. Every day is a gift. But if people are going to ask me to entertain doom and death, then after I do that, I think it's also honest and appropriate to state there's no known present danger, odds are good that it'll remain that way for the life of ProcessWire, and the reasons why. If I were battling some condition that changed the odds then I would also want to state that. @AndZyk Kirby is a commercial product so not really a direct competitor. In our case, we are talking about what can be built without a company paying for it, and without any budget for that matter. So while I think it's good to look at, I also would say to everyone that we have to be careful about setting core builder expectations from other projects, especially commercial and highly funded ones.

Just adding my voice from a user perspective. I am not a coder but a very happy user of processwire. For some of my sites I use the repeater matrix apporach which was done for me by someone from the forum, great work. End of last year I decided to buy access for one year to thrivethemes.com a builder for wp, simply because my business model needs landing pages, email squeeze pages, courses, etc. etc. I get sick already with the trouble of learning how to do stuff in thrivethemes environment. Everything I built so far is far slower than what I have in pw, but for pw I need developers everytime I need something new. The guy behind thirvethemes now has 70 people working, so there is a market for this type of stuff. I much prefer what I have in the repeatermatrix pw way of doing things, and would therefore be SOOOOOOO happy if this gets taken further and I beleive if a few of you coding ninjas would build the pw version of thrivethemes, there is a market waiting to be tapped into. Just my 2 cents! Love the discussion and the talent gathered here.

Your points about this are all completely fair. It's up to you to integrate or reject the changes a PR does. Currently the latter however does not happen in a manner visible to the creator of the PR or anyone else looking at the PR. So they just stack up looking like they were never looked at. If you consider something not possible to be added (or even not possible in the near future) everyone is better off if the PR would be closed with a short note of the reasoning. PRs do not age well and it's better to close them than letting them sit until no longer mergeable. The closed PRs (and issues) are still searchable, so if people to their due diligence they'll see that things were rejected before, find related discussion if attached, …. If you're not happy with the code for a given change you can also help people come to a version you're happy with maintaining without needing to go code it yourself. This does even work for issues. One of the most encouraging responses to issues I know from other OSS projects is "Sounds good. PR welcome.". I rarely see that as a response to bigger feature requests, but on smaller incremental things making parts of the project better it's a good way to move the burden of actually fixing something off of the maintainer themself. If a PR is not of that kind it's totally fair to close it with something like "This is to big a change and needs upfront discussion before consideration.". You don't need to take the time of reviewing PRs in depth, when you already know you'll not merge from just the title/description/amount of changes/…. So in conclusion: Without a response from your side a open PR is dead weight in the context of the community helping you improve processwire. Someone did some work and now it's stuck. Even if the response is negative it'll give anyone involved context either to adjust and be fine with things not being added or next steps to get things integrated either by starting a needed discussion, changing the code or implementation or whatever else needs to be done before it could be merged. Given the fact PRs don't age well I also feel response should be reasonably timely – even if the merge actually happens at a later time. Take a year and the PR creator might have moved on or worked around it, the underlying code changed in the meantime so the PR is no longer easily mergeable, but the issue fixed by the PR might still be present. I know this well given I have two open PRs for processwire from 2017 – one small fix, one not as small feature. I hardly use processwire anymore by now.

Yes, this is also what I was liking about it. I think the only thing that gave me pause is the development side of it. The plugins don't look as simple to develop as I thought they would be. At least, the learning curve there looks a bit high, and the amount of code to develop something simple seems more than I would have expected. But the same is true of developing CKEditor plugins, and none of those are deal breakers. This seems to be the nature of JS based plugin systems. I do feel like I need to find all the editor.js type options, as I'm guessing there are similar projects we should explore before picking one to build from; even if editor.js seems the most likely at the moment. Sounds awesome. I'd encourage you to release it as a module if you can. The reason I'm looking at two strategies is because I agree that the editor.js approach is great, and probably a good fit for many (or most). But there's also users like Jonathan Lahijani, where the editor.js/bard approach is not nearly powerful enough. The repeater approach does have the power, even if it's not as immediately intuitive. That's why my plan is to further develop RepeaterMatrix to better support those that want to use it as a builder, while also pursing a simpler strategy along the lines of editor.js. Does this mean that either approach is going to answer every need and interest for everybody? That's unlikely, but hopefully it'll be a good start and get the momentum going. If we were to use editor.js, then I wouldn't expect one's template code to consume JSON. We'd map the JSON to an object (or array) so that it could be used just as easily as page fields. Right, same kind in terms of what it stores. In terms of implementation, I think we are talking about 1 core direction, but 2 different directions overall. Neither direction at the expense of the other. A reasonable one that the core provides (editor.js approach or similar). And then upgrades to RepeaterMatrix for those that want to use it as a more powerful builder. So the 2nd option would simply be ProFields RepeaterMatrix, and it wouldn't even be a builder per se, but it would be ready to be used as a builder a lot more than it is now. Not flaws per se, but features that would make it better support use as a builder. That's what I'm looking to add. For a repeater matrix based builder, this would be at the discretion of the developer as to how and what they wanted to store. So in your case you might want to store something more abstract, whereas someone else might want something directly tied to their output framework. For the simpler/editor.js type builder, I don't think it would get into this type of layout thing at all. This is all true, I don't think you would be able to on the editor.js side. The elements are defined by editor.js plugins, static code. Just like CKEditor plugins. Though we'd probably bundle a lot of plugins and build some of our own. Ultimately the editor.js route will never be as powerful as the repeater route in this regard. But it will be very easy to setup and very accessible. This is something Jonathan and I discussed on our call last week. The storage behind Repeater/Matrix is overkill for the needs of a builder, so what would be ideal is if repeaters had an option to merge some of the storage needs. It's something I'm going to be looking into, though I'm not yet sure what's possible. This is basically what the new Combo field does. Though they are connected to the database, but a repeatable Combo field wouldn't require pages for storage the way Repeaters do. Nevertheless, for a builder, it seems that the underlying pages do bring a lot of benefits, even if they are overkill for the need. This is already true. But I still think the two-tier route offers the most benefits. On one side something simple like editor.js, and on the other side, something ready for more complex needs based off an existing Fieldtype like RepeaterMatrix. Also, Bernhard's solution in the other thread looked pretty great too; he said it was similar to repeaters in some fashion, also using pages from what I understand. Will do. That's true. Use ProcessWire (or any other tool) for what it has right now. You are right there are no guarantees about which features or ideas will be implemented, even for me. There have been cases where someone needed something and decided to sponsor it for the community, by hiring me or someone else in the community to build it. Outside of that, I have to find a crossover between feature requests and the needs of the projects that I work on with my clients, or with Pro modules. I can't afford to build features just for the sake of building them; I still have to find a way to fund them and then support them afterwards. The way I do that is by developing stuff that finds a balance between client needs and project needs. That way I don't have to bear all the development costs myself. The Pro modules also help to fund the core, though they also are significant projects in their own right, so I try to put much of Pro module budgets back into Pro modules themselves too. Though I put the question out there because I thought this year I could get into a couple of things that go beyond the usual development path. I'm admittedly cautious about what gets pulled in, and there's no guarantee that a PR submitted without prior discussion will ever be added. I'm also serious about supporting this project for 10, 20 years or more, so anything that gets pulled in also becomes responsibility to support it for life. The person that submits the PR does not have that responsibility. I need to make sure I fully understand and can support anything that gets pulled in. I also have to make sure it's worthwhile for the majority of users. So my preference is for PRs to be preceded by a discussion before someone creates it, so that we can evaluate needs and timing, etc. Sometimes something can be added very easily and without a lot of investment to review and understand it all, and I try to cover those once a year, or more if possible. The guidelines are here (https://github.com/processwire/processwire/blob/master/CONTRIBUTING.md) and while they do touch on this, they could go further. I will work on that. Thanks.

@flydev ??, Spot on, everything you've said! I've been thinking along similar lines! I wish I could give you more likes! ?. I agree and I don't think it should be limited to this group. Lowering the entry barrier to any software, especially in the modern age is incredibly useful. Look at all the rage about coding for kids, etc. Python is great in this regard. So are tools like Flutter. For a while I was of the notion that things like page builders are somehow anti-pattern with respect to ProcessWire. Lately, I have had to discard that opinion. Don't get me wrong, I am not saying that the core should provide this capability. No, such things can be built by the community. For me, when we say that ProcessWire is simple, powerful, enjoyable, scalable, familiar, friendly, etc...., that encapsulates the absolute freedom the tool provides me. I can do almost anything with it. It doesn't take away from the tool. It is a testament to how versatile the tool is. Behind the scenes, it is still ProcessWire. The output, what I can do with it, well, that is the magic that is ProcessWire. And for this, I have to give Ryan credit. I doubt there are many CMSs out there that will allow you to extend it as much as ProcessWire does, yet remain stable and secure. I don't see this as a problem at all, but rather an opportunity. I am not talking about the more the merrier. Rather, making a powerful, enjoyable tool accessible to people with different skill sets and different approaches to building things. That is a good thing, maybe even a great thing. In the end, we all want the same thing. To build secure, reliable, fast, stable websites/portals for our clients. If you can achieve that via pure coding, more power to you. On the other hand if you can achieve that (at least partly) via drag and drop, nice one mate! More power to you too. In addition, a builder doesn't mean the builder will just output code arbitrarily. On the contrary, the dev still has full control over the output, access controls, etc. This is crucial! In the same manner we lock 'fields' , 'templates', 'modules', etc., we can and should lock the builder down, both at the visual and processing data level. Exactly! That's how I've designed the builder I worked on this weekend ?. Looking forward to this! Hopefully, in the next few days you will also have a preview of the page and content builder I developed over my weekend hackathon ?.

You are all right and everyone have good arguments. A page builder should be built IMO. As a recent example, I needed to build a cool invoice, like the one you receive in your inbox sent by big companies names. Their email look so fun/cool/responsive that YOU WANT TO DO THE DAMN CLICK on their call-to-action button. Then I found a cool software called "Nicepage", where you move blocks, edit styles and content, and tada, a cool page done in a minutes, with clean code, really - after a copy-pasta moment, I had my invoice in my template sent by PadLoper. I think it's @Jonathan Lahijani that was saying something in this, users which build marketing pages, landing pages and other things like that, it's just incredibly useful. Another example, I don't build website everyday anymore, but backends (based on ProcessWire) with public/restricted API and desktop/mobile apps connected. I can imagine how easy it could be to extract/manipulate data from an external apps (What's happened with EditorJS). Plus, and even if it's not the primary goal, given the tool we already have in our hand, it will make a bump on new users/devs which will use ProcessWire. The right ones ? not sure, maybe the forum will be spammed by "unexperienced user" which will try to build a website with the builder but doesn't understand in first instance how to apprehend ProcessWire. But it should be developped keeping in mind what all the devs say in their different horizon. I mean, a system of permission should be built-in, every blocks or type of blocks should have a permission, restricting some functionalities that could be used in an editor, or the page builder it-self. Eg. all blocks are available to superuser, but other users will have only access to the defined blocks for their role combined to the restrictions of the page being edited. "I don't want to give so much freedom to my client because he will ruin the front-end" Absolutely, but is your job to lock everything. Building pre-defined blocks (speaking styles, not content (even if you should limit content)). - Give them possibility to write their article, and to add a block with three columns for 3 featured products of their webshop. So cool. - Give them possibility to write their article, and to add a banner/call-to-action newsletter. Here you limit the number of words/paragraph, whatever, then again, So cool. And IMO, it doesn't change anything at this time of writing: with or without a page builder, clients are often asking more and more. Where I see a benefit to give the user the ability to add / remove blocks from a page builder is the ease and feel when editing content - productivity in addition. It depend also on how large is the project, the client's technical background, if there is a team or not, a frontend dev on the team or not. Given this factor, you have to "educate" your client in consequence. This imple to explain to the client, how/why it can and howtonot/whynot it can. To each one his field of work and I think this particular argument should not stop any idea because it is valable for whatever special you make for a client purpose. You will have on the next weeks a preview of EditorJS which maybe will give you more idea/insight on how to work/render/restrict theses data blocks.

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 ?

@arjen forked it because, quote: "We needed an option to determine whether 0 or empty should be regarded as equivalent. I copied the method + config from FieldTypeFloat. In my testing it seems to work fine." Others wanted to convert Float fields to Decimal but I guess your "combo" solution would solve that out of the box. Last but not least there was interest in "number spinner" which would be nice to have for all number fields, provided that the "values of increments" are configurable. BTW, I forgot about all this,but @apeisa joined in the discussion at some point, quote: "As a @sforsman's coworker I'll let him know about this. We do use namespaced version of this module ourselves." So maybe you and Apeisa could also discuss what their current extra needs are, if any.

Hi @ThomasH In file PagePDF.php on lines 32,33,34 change to: use ProcessWire\Pagefile; use ProcessWire\Pageimage; use ProcessWire\Pageimages; and in file PagePDFs.php add ProcessWire\ namespace for Pagefiles as well (on line 29) BTW @Richard Jedlička very useful module for me now ? Thanks a lot! Working on PW 3.0.133, PHP 7.3.8 FPM (FieldtypePDF v. 1.1.5)

Merry Christmas to everybody. (Missing Christmas Emoticon) The JavaScript File: $(document).ready(function() { // instantiate WireTabs if defined $('body.hasWireTabs #ModuleEditForm').WireTabs({ items: $("#ModuleEditForm > .Inputfields > .InputfieldWrapper"), }); }); The Module: <?php class ModuleSettingsTab extends Process implements ConfigurableModule { /** * * @return array * */ public static function getModuleInfo() { return array( 'title' => 'Module Settings Tabs', 'version' => 000, 'summary' => 'Provide Tabs for module settings screen' ); } public function __construct() { $this->wire('config')->scripts->add(wire('config')->urls->ModuleSettingsTab.'ModuleSettingsTab.js'); } /** * Initialize the module * */ public function init() { } /** * Module configuration * */ public function getModuleConfigInputfields(array $data) { wire('modules')->get('JqueryWireTabs'); $inputfields = new InputfieldWrapper(); $tab = new InputfieldWrapper(); $tab->attr('title', 'Settings'); $tab->attr('class', 'WireTab'); $markup = $this->modules->get('InputfieldMarkup'); $markup->label = 'Settings'; $markup->value = '<p>Just a placeholder for some inputfields.</p>'; $tab->add($markup); $inputfields->add($tab); $tab = new InputfieldWrapper(); // $tab->attr('id', 'ext_settings'); $tab->attr('title', 'Extended Settings'); $tab->attr('class', 'WireTab'); $markup = $this->modules->get('InputfieldMarkup'); $markup->label = 'Extended Settings'; $markup->value = '<p>For very experienced developers only.</p>'; $tab->add($markup); $inputfields->add($tab); return $inputfields; } }