MarkE

I quite agree. BUT I think ProcessWire would benefit from a larger user group. Many (professional) developers are influenced by the critical mass of an open source solution - below a certain level and they are wary of being tied into a framework that may be going nowhere. For that reason, ProcessWire is often not chosen and an inferior, but more widely used, system is selected instead. The advantages that a page builder potentially brings are, to my mind: More users are attracted to PW. Some of these might be 'non-coders'. Equally, they may be people who can code (to some extent) but who just want to implement a simple site quickly (which might be enhanced later). A developer can off-load some of the work to a 'non-coder' who can focus on design aspects (this may be the client) However, the crucial point that @pwiredmakes is that the use of a page builder should not restrict the site further. The structure of ProcessWire is such that this ought to be achievable, but only if a page builder makes use of PW components in a transparent and modifiable way. There seems to be quite a bit of activity in this area, notably @Jonathan Lahijani's above and @bernhard's RockMatrix (still under wraps, I think), and it would be good to have a bit more visibility of the approaches used and how they meet these objectives. I have done a bit of thinking myself about how a page builder should look, but it's early days yet (and I don't want to re-invent the wheel). Ideally it would make use of standard PW components, but it would be opinionated to some extent (CSS grid and Tailwind seem obvious choices). Trouble is, most of the paths I have explored so far end up using RepeaterMatrix. Don't get me wrong, RM is a great field, but I don't think it's a great idea to have a page builder, which is designed to atrract new users, being dependent on a commercial module. P.S. Also, I think a page builder should allow for multiple themes, so that developers can easily add a new theme.

That's a shame. Maybe an initial release would help ? At least some feedback might be useful.

https://processwire.com/modules/app-api/ ?

Technically, not a lot, since the generic QuickStart works well. The main reason would be for visibility. Someone installing ddev might be prompted to think about ProcessWire as a solution.

I wonder if we could contribute a cms QuickStart for ddev. It would be nice to have ProcessWire listed there!

Spot on @bernhard. Million thanks! But I'm still puzzled, because in the phpStorm data source definition, I have localhost and it works - if I change it to db, it doesn't work.

Update to the above post. I changed all the name/user details to the defaults: $config->dbName = 'db'; $config->dbUser = 'db'; $config->dbPass = 'db'; $config->dbPort = '3306'; I realised that ddev assigns a dynamic db port so I added a static host_db_port: "3306" to .ddev/config.yaml. I can access the db in phpMyAdmin - and in the phpStorm database tool (now that it has a static port). I added a var_dump of pdoConfig to check what PW is looking for, namely array(5) { ["dsn"]=> string(40) "mysql:dbname=db;host=localhost;port=3306" ["user"]=> string(2) "db" ["pass"]=> string(2) "db" ["options"]=> array(2) { [3]=> int(2) [1002]=> string(16) "SET NAMES 'utf8'" } ["reader"]=> array(4) { ["dsn"]=> string(0) "" ["user"]=> string(0) "" ["pass"]=> string(0) "" ["options"]=> string(0) "" } } This matches exactly the config data I enetered into phpStorm's database tool (host: localhost, port:3306, user:db, password:db, database:db) which connects sucessfully. But I still get this error where the last array is ["options"] in the var_dump above. Any ideas? ?

Having problems with laragon so decided to switch to ddev. Installed docker & ddev just fine. Then wanted to set it up with an existing project, rather than start from scratch. So what I did was: change to the project directory ddev config ddev start imported the database (ddev import-db ...) using a copy downloaded from the live site That all seemed to execute properly. Then I ran the url given by ddev and clearly the php was executed but the db could not be found: The dbname etc. were the details for the live site (although I was expecting it to look for the dev site details as the $config->paths->root had not changed) EDIT: under ddev it has changed, so I changed my test condition in config.php for the dev environment accordingly Unfortunately, since laragon is not working any more (not php8.0 compatible and unable to upgrade) I couldn't get into phpmyadmin and export the database there). Any ideas on how to hook everything back together, @bernhard, @heldercervantesor others? EDIT: I see ddev changes all the database details to 'db'. I changed all the name, users etc to match, but still no luck.

That explains a lot! I have LOTS of repeaters in this new app as it seemed a really neat idea from the point of view of the admin gui. Then I ran into LOTS of problems with dependent page selectors, which I think I’ve now fixed, either by contributions to the core or by the new CustomDependSelects module. I have wondered whether it would have been wiser to use plain pages. RepeaterMatrix does seem to be very popular (and I can see why), particularly for a UI for web page blocks. Other contributions on the “repeaters or no” discussion would be helpful.

Well, more of a suggestion than a recommendation in https://processwire.com/blog/posts/pw-3.0.152/#custom-page-classes-vs-hooks However, it struck me as a good idea since any custom methods for all pages can go in DefaultPage and will be available to any other custom page classes. If, for some reason, you don't want to include the method in a custom page class, you can either declare it in the subclass or (to exclude them all) extend Page. Much better than adding methods to Page via hooks, no? So my practice is always to include a DefaultPage class, even if I end up putting nothing in it. Absolutely, but it is a rather large app, so difficult to encapsulate. The context is the same as the worked example here (which I will repeat for ease of reading): There is CiderPage.php containing: class CiderPage extends DefaultPage. This contains a lot of methods, but one simple one is: /** * Get the stage sequence as it is actually stored in the page array - this may be different from the 'sort' property * * @param $stage * @return false|int|string */ public function getStageSequence($stage): bool|int|string { $sort = array_search($stage->id, $this->stage->explode('id')); return $sort; } Ideally, I would have something like RepeaterStagePage class with method: /** * Get the stage sequence as it is actually stored in the page array - this may be different from the 'sort' property * * @return false|int|string */ public function getStageSequence(): bool|int|string { $sort = array_search($this->id, $this->getForPage()->stage->explode('id')); return $sort; } Admittedly, this is not any less code, but at least it would sit in the right place. For example, the first method would be less good if the stage field was used in a two different templates (which it is in fact, but the class of one -JuicePage - extends CiderPage, so it is not a problem in my case).

That’s great @bernhard. I really think custom page hooks should be in the page class, not ready.php, which can get really messy. I have a couple of questions: why do you extend page rather than introduce an intermediate DefaultPage class as recommended by @ryan? how do you deal with pages that are repeaters (or repeaterMatrix)? Per a comment in the RepeaterMatrix forum, custom pages classes don’t work with these as they have their own classes which descend directly from Page and extending those classes is not advised. @ryansuggests using addHookMethod on RepeaterMatrixPage (or, presumably on RepeaterPage for plain repeaters), but that would place all the code in ready.php. The approach I have adopted is to put the methods in the page class of the getForPage with an argument for the repeater page object. Any suggestions?

This looks really useful. For some reason I missed it at the time, but I thought I saw a tutorial covering it within the context of custom page classes generally - which I now can't find. Is there one @bernhard?

I have used both and now just use this one on new projects. They both work fine in normal circumstances (and are easy enough to just temporarily install and play with), but @Robin S's is simpler with less to go wrong - I had a few problems with @kongondo's in a multi-instance environment (which I think are fixed). On the other hand @kongondo's has a slightly more feature-rich GUI. You could always build your own simple module rather than just use hooks if you want more than the basic RuntimeOnly and want control over the code - I forked this module to include a custom Fieldtype in my ProcessDbMigrate module. As @bernhard says, it all depends what you are trying to do.

v0.0.3 fixes a bug experienced when saving page fields

v0.0.17 released - allows use of RockCalculator in magnitude fields. You need to install RockCalculator separately to enable this. It is entirely optional, but helpful:

Hi @bernhard. Had a quick look at this. It's a bit of a puzzle to me. The problem occurs when clicking the "Get Module Info" button on the new modules tab. I tried on 3.0.200 and 3.0.203 In 3.0.203, all I get is a compile error - see the title of this thread - so it's a bit difficult to diagnose as there is no obvious cause. This happens with RockCalculator and RockMigrations, but NOT RockFrontend. (Although I have not yet proceeded to install RockFrontend I have no reason to believe it won't install). In 3.0.200 I get the "ProcessWire: ProcessModule: No page specified" error. This is generated by ProcessPageEditImageSelect::init() (line 292 or 294). I have no idea why PW is even in that class. See the trace below Again, this happens with RockCalculator and RockMigrations, but not RockFrontend. I inserted a debug_backtrace - see here (unfortunately lost indents on paste from Tracy), which explains more: 3 => array 'file' => '.../admin/wire/core/Modules.php' 'line' => 1711 'function' => 'get' 'class' => 'ProcessWire\Modules' 'object' => ProcessWire\Modules count: 131 items: array 'type' => '->' 'args' => array 0 => 'ProcessPageEditImageSelect' 4 => array 'file' => '.../admin/wire/core/WireArray.php' 'line' => 1763 'function' => 'find' 'class' => 'ProcessWire\Modules' 'object' => ProcessWire\Modules count: 131 items: array 'type' => '->' 'args' => array 0 => 'installs=' 5 => array 'file' => '.../admin/wire/core/WireArray.php' 'line' => 582 'function' => 'findOne' 'class' => 'ProcessWire\WireArray' 'object' => ProcessWire\Modules count: 131 items: array 'type' => '->' 'args' => array 0 => 'installs=' 6 => array 'file' => '.../admin/wire/core/Modules.php' 'line' => 1911 'function' => 'get' 'class' => 'ProcessWire\WireArray' 'object' => ProcessWire\Modules count: 131 items: array 'type' => '->' 'args' => array 0 => 'installs=' 7 => array 'file' => '.../admin/wire/modules/Process/ProcessModule/ProcessModule.module' 'line' => 1154 'function' => 'isInstalled' 'class' => 'ProcessWire\Modules' 'object' => ProcessWire\Modules count: 131 items: array 'type' => '->' 'args' => array 0 => 'installs=' 8 => array 'file' => '.../admin/wire/core/Wire.php' 'line' => 420 'function' => '___buildDownloadConfirmForm' 'class' => 'ProcessWire\ProcessModule' 'object' => ProcessWire\ProcessModule #359 'type' => '->' 'args' => array 0 => array 'status' => 'success' 'id' => 2236 'class_name' => 'RockMigrations' 'name' => 'rock-migrations-1' 'title' => 'RockMigrations' 'summary' => 'The Ultimate Automation and Deployment-Tool for ProcessWire' 'version' => 121 'module_version' => '1.2.1' 'created' => 1661782531 'modified' => 1662318506 'refreshed' => 1662616138 'url' => 'https://processwire.com/modules/rock-migrations-1/' 'details_url' => 'https://modules.processwire.com/export-json/rock-migrations-1' 'requires' => array 0 => '' 1 => 'installs=' 'requires_versions' => array '' => array 'installs=' => array 'installs' => array 0 => '' 'author' => 'bernhard' 'icon' => '' 'likes' => 1 'release_state' => array 'id' => 1083 'name' => 'stable' 'title' => 'Stable' 'url' => 'https://modules.processwire.com/release-states/stable/' 'pw_versions' => array 0 => array 'categories' => array 0 => array 1 => array 'authors' => array 0 => array 'authors_other' => '' 'project_url' => 'https://github.com/baumrock/RockMigrations' 'download_url' => 'https://github.com/baumrock/RockMigrations/archive/main.zip' 'forum_url' => 'https://processwire.com/talk/topic/27504-rockmigrations-' 'author_id' => 2865 1 => false

I’ll look into it when I get a moment. Manual install seems ok.

Hi @bernhard. Just tried a different module (AppAPI) which is OK. The problem appears to be with your modules. I tried RockMigrations too - on v3.0.200 - both RockMigrations and RockCalculator give this error: ProcessWire: ProcessModule: No page specified

Thanks @bernhard. That's helpful but doesn't work as $f->hasField is null because magnitude is a property of a measurement object field, not a field itself. So I tried the following code - creating a dummy field to hold the rockcalculator property: $f = $this->modules->get("InputfieldText"); if(wire()->modules->isInstalled('RockCalculator')) { $f->attr("data-rockcalculator", 6); //6 digit precision $f->notes = __("Numeric or math formula"); $dummyField = wire()->fields->makeItem(['name' => 'dummyName']); $f->hasField = $dummyField; $f->hasField->rockcalculator = true; bd($f, '$f in rockcalc'); } else { $f->notes = __("Numeric"); $f->precision = 6; $f->attr('type', "number"); $f->attr('step', "any"); } That almost works, in the sense that isEnabled() is true and loadAssets() runs. However the dev tools do not show the js as loaded and the field doesn't work. I've got round the problem by including the following in the init() of my fieldtype module: if(wire()->modules->isInstalled('RockCalculator')) { $rc = $this->wire->modules->get('RockCalculator'); $this->wire->config->scripts->add($rc->m('lib/math.min.js')); $this->wire->config->scripts->add($rc->m('lib/tooltip.js')); $this->wire->config->scripts->add($rc->m($rc->className . '.js')); $this->wire->config->styles->add($rc->m($rc->className . '.css')); } Maybe there is a better way, but at least this seems to work. And your module certainly enhances mine ☺️

This looks a handy little module. I'm hoping to add it as an enhancement to my FieldtypeMeasurement module, which it would complement very nicely. However, I'm scratching my head a bit as to the best way of incorporating it as I really need to embed it within my Inputfield::render() method - i.e. after the hook in your module has fired (?), but I think that's too late. The problem is that my field is an object. The magnitude property (which is where I'd like the calculator) is rendered as a text inputfield. So what I was hoping to do was something like this (where $f will be the inputfield for the magnitude): $f = $this->modules->get("InputfieldText"); if(wire()->modules->isInstalled('RockCalculator')) { // set the rockcalculator here // $f->attr("data-rockcalculator", 6); //6 digit precision $f->notes = __("Numeric or math formula"); } else { $f->notes = __("Numeric"); $f->precision = 6; $f->attr('type', "number"); $f->attr('step', "any"); } However, that doesn't work because the assets aren't loaded. It works OK if I remove the line if(!$this->isEnabled($inputfield)) return; from loadAssets(), but obviously if the module is used elsewhere in the site, that is not a great idea and isEnabled() is not hookable. I could just load the assets separately, I guess. Any suggestions@bernhard

On 3.0.203. No other modules of yours installed, but planning RockFrontend and maybe RockMigrations

Just tried to install a new module (RockCalculator from @bernhard) and got this message. I don't think it's anything to do with his module, so posting here as a general query. Any ideas what might be causing it? (BTW it installed OK by downloading the files manually)

Thanks @bernhard- fixed now

TLDR: Use custom selectors in page field selector: - check_access=role1|role2 ... - to control who can see results - field=[item.id] - to select on id of repeater item containing the page field. ------------ This module extends the capabilities of selectors specified in the 'input' tab of a page reference field, specifically when that field is part of a set of dependent selectors which may be inside a repeater item. The readme also attempts to bring together various existing documentation regarding the use of dependent page selectors and the enhancements that were provided by various PW versions. See https://github.com/MetaTunes/CustomDependSelects for full readme and to download. Please note that this is an initial alpha release. Please test in your own context thoroughly before using. Also note that PW3.0.200 is required and 3.0.203 is preferred.

Actually, I am building a little module to fix it, hopefully ? -Edit: You can now find it here.