bernhard

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.

Not sure where I want to take this... At least it will be a successor of https://processwire.com/talk/topic/18166-processwire-kickstart/; Maybe more... Anybody here still using wire shell and wants to share experiences/learnings? How were you using it? What was missing? What did you like most? etc

Thx ? Here you go: https://github.com/BernhardBaumrock/RockMigrations/releases/tag/v0.0.26 I hope I'll get used to tagging and not forget about it in the future ?

Yeah, maybe I should get used to that. But for me they do not add any benefit... Maybe you could explain why they might be important for others?

I think this is a helpful post for anybody new to hooks: https://processwire.com/talk/topic/18037-2-date-fields-how-to-ensure-the-second-date-is-higher/?tab=comments#comment-158164

This is really easy either via RM or via default API: $modules->get('TracyDebugger'); // or $rm->installModule('TracyDebugger'); I'm using a GIT setup with submodules. So all I have to do is git submodule update --init --recursive That way I always have my modules under control of GIT and can efficiently commit new changes from any project that I'm currently working on ? But I went ahead and added support for rockmigrations via composer: https://packagist.org/packages/baumrock/rockmigrations Would be interested to hear if everything works!

Hi @Richard Jedlička, thx for your message ? Thx, that's a good point! I've added a new example file of how I am using RockMigrations nowadays that should be really helpful to get started with the power of RockMigrations and building easy, fast and reusable modules: https://github.com/BernhardBaumrock/RockMigrations/blob/master/examples/MigrationsExample.module.php You might not need this feature any more once you saw the new example file, but anyhow it was an easy update and I've made the getMigrationsPath() method hookable so you can use whichever folder you like ? I'd be happy to get a quick tutorial of how all that works and what the benefits would be and then I can take that into account. PRs are always welcome.

1.0.4 adds a litte new helper to add all fields of a template as columns: $rockfinder ->find("template=foo") ->addColumnsFromTemplate("foo"); 1.0.5: add getJSON() method

You should get some good inspiration here: https://github.com/processwire/processwire/blob/d8945198f4a6a60dab23bd0462e8a6285369dcb9/wire/core/ProcessWire.php#L410-L459 ?

1st: Make a backup!! I'd try setting the type of the field to FieldtypeText in the DB, then the error should be gone and you should be able to delete it. Or you delete the row in db table "fields" and then you delete the db table field_yourfieldname

Thx Robin for another great module! ? I'm always stripping down the interface of CKEditor as much as possible using your great hooks. I wonder where and why you'd be using this field? I think markdown is still too complicated for clients. I'm not using any of those nowadays. Maybe that's why I can't think of where to use this field at the moment. But I'd be happy to hear where you are using it and what you dislike with ckeditor (or why you built the module in the first place). The only thing that I really don't like is copy/paste issues with custom formatting that can get annoying. But there's also a solution for this here.

9 years later I hit the same wall ? I have a kickstart script that installs several modules. I got this error: ERROR: application encountered an error and can not continue. Error was logged. Then I found this log in /site/assets/logs/tracy/exception.log: [2020-12-14 20-17-00] ProcessWire\WirePermissionException: You do not have permission to execute this module - ProcessDatabaseBackups in \wire\core\Modules.php:1337 @ CLI (PID: 15532): site/modules/RockBuilder/kickstart.php @@ exception--2020-12-14--20-15--dd5f3e67ab.html When setting the user to the superuser everything works: <?php namespace ProcessWire; /** @var Wire $wire */ include("index.php"); $users->setCurrentUser($users->get(41));

Hi everybody, This is the php support matrix as of today: https://www.php.net/supported-versions.php @adrian has posted some findings regarding PHP8 here: I know someone who is running a ProcessWire installation on a server on PHP7.1 ?? Now I'm asking for this person: What would you recommend to do? Upgrade to PHP7.4 or PHP8 ? I'm a little afraid that PHP8 will bring in some issues and it might be a little too early to jump on that train now. Maybe the transition would be a lot smoother when upgrading to 7.4 now and jumping on 8 around mid-2022 (in 1,5 years). What do you think? Does anybody already have findings to share?

Welcome @Grigorij Schleifer, This does also look like a good tutorial and he is also working on mac ?

Maybe this module would be a better fit then?

Hm. I thought maybe I could strip the EXIF data from the image but did not have enough time to look into it. Do you know if PW has a method for that? Otherwise it seems to be 7 lines of code using php+imagick (which I'm using).

Yeah, good point. I have no idea... I have another problem in my app. I'm generating a PDF from a page with some images and one of them keeps getting rotated by 90°. Only one, all the other images work as expected. ?

Ok thx, I've refactored a little and that's totally fine, you're right ? $phc = $this->wire->modules->get('PageHitCounter'); $event->return = $phc->buildPageListHitCounter($page->phits) .$badge($type($page)) .$page->range->format() .", ".$page->title;

It will be back on the next update of ProcessWire unless Ryan fixes the issue in the core until then. So you either need to wait with that update or you apply the changes again after your upgrade.

@Robin S is a genius! ? Based on his posts in the github issue I did the following and finally got the bug fixed (it seems): For Server Side Resizing: Search for "$corrections = array(" in all your files. You should find 3 files: Replace those arrays with this one: $corrections = array( '1' => array(0, 0), '2' => array(0, 1), '3' => array(180, 0), '4' => array(0, 2), '5' => array(90, 1), '6' => array(90, 0), '7' => array(270, 1), '8' => array(270, 0) ); This did already fix my issue. Client Side: Replace PWImageResizer.js with this file created by @Robin S and delete the old minified version PWImageResizer.min.js to make sure that the new version is loaded: https://github.com/processwire/processwire-issues/files/4660217/PWImageResizer.zip Would be great to hear if that also fixed your issue @Mikael ? Thx again @Robin S for the great work!!

I have no solution yet. @Robin S seems to have found a way, but I had no time to test what he wrote in the issue. I was always hoping that Ryan will come up with a fix sooner than I have to build a quickfix on my own. I thought of adding custom buttons/checkboxes to rotate the image after saving... For now I've just added a comment that says "if the orientation is wrong please use this online editor and upload the image again" ?

Thx David, hm... reading this portion of code again, I think it would be a lot nicer to have a method on the page object for that: $event->return = $page->phcLabel() .$badge($type($page)) .$page->range->format() .", ".$page->title; What do you think? $this->addHookMethod("Page::phcLabel", function($event) { $page = $event->object; $cnt = (int)$page->get(PageHitCounter::PHCFIELDNAME); $event->return = $this->buildPageListHitCounter($cnt); });