bernhard

That's exactly how things already work ? At least the first part of your message. https://processwire.com/blog/posts/processwire-2.5-changelog/#adding-pages

How does the output look like? Are you sure that the image exists? Well, it should, if it is a static image and in other areas it works as expected... Not sure if $pdf->save() using a relative path for the pdf is a good idea ? Are you sure that the hook is executed?

Yeah - every block is a separate template (all having a prefix here): No idea how I could measure or tell about the performance impact of such a setup compared to other strategies, but it's nothing noticeable and I thought if that really became a problem I'd simply do some caching...

While reading my other post of the 5 most used features I thought: A one-click download of a DB dump would be nice! That could then be restored on local dev easily (maybe also as one-click). Using Adminer is not a problem at all. But it would be handy to have that in the tracy bar. But on the other hand I'm not sure if that should really be a tracy feature or a separate module. I'd love to have a better CI/CD workflow. Also coupled with RockMigrations. But in the meantime it would be nice to have a good workaround. If you guys have any other good suggestions I'd also be happy to use those so that adrian does not waste his time ?

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