bernhard

That's a good idea ? RockMigrations was built so that it can be used easily by other modules. Why not as well by another migration module ?

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

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

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

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

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

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

Thx, i've corrected that in case your wording is more clear ? Exactly. Sounds good to me in your wording as well ? Not sure how the image reference field works, though. I've never found time to give it a try...

100% agreed ? Just thinking out loud... If we were building a website with a blog. And every blog post had fields "title, coverpic, body". And if the "coverpic" field was set to that all uploaded coverpics lived in /site/assets/files/coverpic. And if we then created some new blog posts... First, we'd create PostA and upload coverpic "foo.jpg". That would live in /site/assets/files/coverpic/foo.jpg; Then, one week later, we'd create PostB and wanted to use the same image (because it was some stock image that is used for every blog post that showcases any event)... We could have the option to upload a new image or choose an existing one from /site/assets/files/coverpic which would mean that no additional storage would be used, because it was just a reference to /coverpic/foo.jpg If PostB was deleted, the image would need to stay available as long as no other field references the image (here PostA). Or maybe even better, if the storage path would be totally free to choose, eg /site/assets/files/blog/[...].jpg ?! --- For some of my clients that would for sure be great. They do now have a shared folder (dropbox), where they save images that they need on a regular basis for their website and then upload those files again if they need it. OK, but not the best solution. My described solution would change quite a lot in terms of PageImages I guess, so maybe as a quick win it would be better to just extend the file/image field with a file chooser, so that one can browse existing files of the same field (or of a definable set of sources) and when clicked, the image got uploaded/copied to the current page destination (eg /site/assets/files/1234/foo.jpg) meaning there'd be an additional copy (little overhead) but using existing concepts and having no complex changes behind the scenes ?

Well. Solid as rock might not be exactly true ? There are some parts that do not always work as expected (install other languages, do modules->refresh(), ...). But most of it works great and I think it's the best tool that we have at the moment. ?

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?

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'd suggest to continue discussion about the content-builder over in the older thread: I totally missed all the posts there and I think some over there might have missed my statements here ?

That's simply bootstrapping PW in a command, then loading rockmigrations and doing $rm->createField(...);

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

Just used $page->meta() for a simple maillog that shows when (date/time) a mail was sent for the currently edited page (invoice) and to whom (mail address) ?

Yeah, maybe not necessary ?

Latest Tracy + PW master --> saving tracy settings worked - maybe a warning could be thrown to make that more obvious? if(!is_array($this->data['styleAdminType'])) $this->warn('Please save tracy settings');

I don't think it's a bug. I think it is the way it is and ryan is aware of that. I think he has explained that somewhere but I could not find where... Reporting this as an issue would not hurt though ? Maybe we get at least the reason why it is like it is, if not a better solution.

sorry and thx - missed that one ?

Have you tried teppos suggestion? I'd be curious if that works...

Unfortunately a $modules->refresh() call from the API is a little unpredictable (at least it has been for me) when using RockMigrations. As you already found out, sometimes a GET request is necessary to trigger a proper refresh. Maybe @teppo's hack works - please let me know! In RockShell this is how I'm triggering the reload after installation of processwire: /** * Reload backend to trigger systemupdater */ public function reload($maxCycles = 15, $current = 1) { if($current > $maxCycles) return; if($current === 1) $this->rs->write("Reloading..."); $guzzle = $this->guzzle(10); $response = $guzzle->get($this->adminUrl()); $dom = new Dom(); $html = $response->getBody(); $dom->loadStr($html); if(count($dom->find("#notices > li"))) { $this->warn(" Found notices - reloading again..."); $this->reload($maxCycles, ++$current); } else $this->info(" Done"); } As you can see that takes several reloads to properly refresh all modules ?

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 ?

Nope. Both are quite experimental at the moment. Not in the sense that things don't work, but experimental so that things might change, there are no proper docs etc...

RockMatrix --> thats a modules similar to RepeaterMatrix. When a matrix item is created, a meta entry stores the reference to the page, where the matrix item lives on. That's similar to the TrelloWire example ? RockMeta --> that are fields for the PW backend that do not store their value in their own DB table but in page meta-data. This is great, because I can add Inputfields to existing Inputfields to make them more flexible without having to create many fields in the system.