Leaderboard

I've done that too complicated too many times ? $wire->addHookAfter("Pages::saveReady('template=foo,id=0')", function($event) { $event->arguments(0)->status = 1; }); Now create a new "foo" page and it will automatically be published (and also the "temp" status will be removed) ? I need that all the time for backend applications...

A couple weeks ago there were a lot of ideas about page builders and different approaches in ProcessWire. Some really interesting ideas actually, and great proof of concepts as well. The conversation started moving faster than I could keep up with, and I think Teppo's summary in ProcessWire Weekly 351 is a great overview, if you haven't yet seen it. These are so great in fact, that I don't think anything I build could live up to what some of you have already built. In part because my focus is more server-side than client-side development, and I can clearly see most of these page builders are much more client-side based than I have expertise in (though would like to learn). Whereas some of you are clearly amazing client-side developers; I'm blown away by what's been built, and how quickly it happened. One struggle I have with page builders is that I don't have my own good use cases for them, with the projects that I work on. Others here (like Jonathan) already have a lot of good use cases. Clearly there are a lot of benefits. I'm fascinated and enthusiastic by all of it, but can't envision how or if I'd use such a tool in my own projects. And having experience with (and particularly close use cases for) a tool is important in hitting the right notes in building it. Likely page builder support belongs in ProcessWire in some form or another, and ProcessWire can be an excellent platform for it. But the actual page builder needs to be designed and built by the people that have expertise in the tools needed to build it, and by the people that will actually use it. I think it should be a community collaboration. For anything needed to support this on the PHP side, count me in. I don't think I've got the background to "lead" the development of the page builder, but I do think I've got plenty to contribute to it. I'd also like to continue building out existing tools like Repeater/Matrix to further support page builder type use cases. I'd like to rebuild and move the auto-save and Live Preview features from ProDrafts into the core, which should also help support some of these page builder cases. Whether these will eventually apply to the larger page-builder project, I don't know, but they'll be useful either way. What are the next steps? Who's interested in working on this? Let's keep the conversion going and move forward with it.

Just released a new version of the module — here's the full changelog: ### Added - Support for Indexer actions, the first one of which adds support for rendering FormBuilder forms as part of the search index. This feature is currently considered experimental. - Option to specify custom path for front-end themes via the Advanced settings section in module config. - EditorConfig (.editorconfig) and ESLint (.eslintrc.json) config files for defining coding style for IDEs. - Support for collapsible content blocks in Debugger. ### Changed - Indexed templates option in module config is now AsmSelect, which makes it possible to organize indexed templates by preferred priority. - Query class converts lesser than and greater than to HTML entities to allow matching said entities, as well as encoded HTML markup. - All Debugger CSS classes refactored to follow `.pwse-` format. The first part of this is now built in, i.e. the indexed templates setting uses AsmSelect and the order of indexed templates gets stored. The module doesn't yet actually do anything with this information, so there's more work to be done. That'll be the focus of next release ? I'll give this more thought once I (hopefully) figure out the initial template order thing.

Thanks @teppo - looking forward to seeing all these new features. I have another one for you ? Whenever I build a search engine I emulate Google's "search phrase" use of double quotes to effectively switch from ~= to *= Would you be willing to support something like that also?

Hi @bernhard, thats a nice and short one! ?

@Confluent Design Nothing amazing I'm afraid, you'll have to edit the included CSS file (InputfieldStreetAddress.css) - or override the selectors it uses with your own in another CSS file that gets loaded later.

v0.0.30: Working with select options fields got easier today ? $rm->migrate([ 'fields' => [ 'yourfield' => [ 'tags' => 'myTag', 'type' => 'options', 'inputfieldClass' => 'InputfieldRadios', 'optionColumns' => 1, // side by side 'options' => [ 1 => 'Eingangsrechnung', 2 => 'Ausgangsrechnung', ], 'required' => true, 'defaultValue' => 1, ], ], ]); Setting the "options" as array has not been possible until now.

Both. It causes the inputfield to be rendered via renderValue() so there's no input, and even if somebody manually added an input in their browser any processing of the inputfield is prevented.

You need a reference to the instance, so the $PageGridCSS variable in your case. That's because there can be different instances of the same class with different states and holding different data. So yes, if you create a new instance in a specific context, only that context has access to the variable. If you want to pass it around, you need to provide utility methods or pass specific instances of a class as parameters. Usually, the instances of a set of classes are linked together by properties referencing each other. For example, in my example code above, the PageGridData contains a list of PageGridItem instances, which can be accessed by key or iterated over using the utility methods provided by WireArray. Each PageGridItem then has a reference to the PageGridCSS instance belonging to it (that's the $cssRules property in my example code). For example: function doStuff(PageGridData $data) { $key = 1234; // $item will be an instance of PageGridItem $item = $data->get($key); // $cssRules will be an instance of PageGridCSS $cssRules = $item->cssRules; // ... } Does that help? The best way to pass around data depends on the application flow. For ProcessWire modules, the main module class will usually have helper methods to access specific classes of the module. For example, my module TrelloWire contains a separate class (ProcessWire\TrelloWire\TrelloWireAPI) that handles all requests to the Trello API. The main module file has a utility method to get an instance of that class with the API key and token configured in the module settings. Another example is the TrelloWireCard class, which holds all the data used to create a Trello card through the API. This one is also a module, so you can access it using $modules->get() to get an empty instance. But the main module class also has a utility method to create an instance populated with data from a regular page and the module configuration. This method is used by the module internally, but can be hooked to overwrite specific fields or used to build your own application or business logic on top of the module.

I'm using ProcessWire all the time for Backend-only applications. Sometimes I also feel like I'm using it in a "wrong" way... But sometimes it seems that there are more people using PW for database applications. I think it is a great tool for such scenarios - I have to admit though that I did not try any others. What's really missing is a way to present tabular lists. That's why I created RockGrid/RockTabulator/RockFinder. RockFinder3 is a great product, while RockGrid/RockTabulator is better than nothing but I'm working on a better solution ? I don't get your problem though... What's wrong with a list like this? id | forename | surname | address | name 1 | john | doe | exroad123 | 1 2 | john | doe | exroad234 | 2 3 | maria | müller | musterweg | 3 I tend to use the title field for a representation of the page that can be used easily on page lists etc: id | title | forename | surname | address | name 1 | john doe (exroad123) | john | doe | exroad123 | 1 2 | john doe (exroad234) | john | doe | exroad234 | 2 3 | maria müller (musterweg) | maria | müller | musterweg | 3 That's a simple saveReady hook. I'd recommend using custom page classes a lot for such setups. It keeps the code clean and a lot easier to maintain. You'll also get the benefit of code completion in your IDE and your hooks will get a lot cleaner, easier and better maintainable as well: // in site/init.php or an autoload module $contact = new Contact(); $contact->init(); // in site/classes/Contact.php <?php namespace ProcessWire; class Contact extends Page { public function init() { $this->addHookAfter("Pages::saveReady", $this, "setTitle"); } /** * Get page title based on other fields * @return string */ public function getTitle() { return $this->forename." ".$this->surname." ({$this->address})"; } public function setTitle(HookEvent $event) { $page = $event->arguments(0); if(!$page instanceof self) return; $title = $page->getTitle(); $exists = $event->pages->get([ 'template' => $page->template, 'title' => $title, 'id!=' => $page->id, ]); if($exists->id) { // page exists, show error message and do whatever is necessary } else { $page->title = $title; } } } Code completion will help you a LOT when the project grows... Combine that with RockMigrations and you feel like you got superpowers. At least I do ?

At the risk of derailing this thread, here is the simplest way I know to get sticky pages in the admin page tree. @Violet 1. Set up a checkbox field called “sticky”. 2. Add this hook at the top of /templates/admin.php (since it’s admin specific, but ready.php will work, too): $this->addHookBefore("ProcessPageList::find", function(HookEvent $event) { $selectorString = $event->arguments('selectorString'); if ($event->arguments('page')->sortfield() === 'sort') //if manual sorting is on for the children of this page, don’t do anything. return; //just add your checkbox to the start of the selector. it will sort by this first, and additionally by the usual sort field. $event->arguments('selectorString', 'sort=-sticky, ' . $selectorString); }); 3. Check the sticky box on pages you want to see at the top. It might make sense to make the field global, but the selector won’t care even if a page doesn’t have it. Or rather, Ryan probably went to great lengths to handle such cases ?

Since I'm doing a lot of detailed logging in our internal PW-based systems, that has become a bit of a bottleneck under heavy load and I was missing a centralized view with the growing number of separate PW instances. So I dug into the core a bit, namely WireLog.php and FileLog.php as well as ProcessWire.php. I managed to whip up my own WireLogDatabase and DbLog classes mimicking the behaviour of the regular logging classes, but not without a little bit of tweaking to the ProcessWire class itself to replace the regular logger. Now I'm logging to a MySQL server instead of plain files and ProcessLogger works smoothly with it without tweaking. I thought it would be shame to keep this all to myself, but a release-worthy version would need or could benefit from: a bit of polishing in regards to error handling and proper treatment of conflicting concurrent operations without too much lock overhead (drop table vs. insert especially) more source code documentation a little more abstraction so all csv operations are deprecated in favor of database columns where avaible last but not least, an approved way to configure the substitute logger and load it early on, which means touching the core ProcessWire class Before I invest too much into that, I'd love to hear all thoughts on this, especially if you think such a module may fit your requirements, and I would be especially happy to hear from @ryan - could you see such a mechanism in the core?

Another quick and easy one ? Place this in /site/templates/admin.php before the require(...) statement: $this->warning('Attention: We have planned maintenance starting 2021/02/11 from 10:00 AM - log out before that date to prevent data loss.');

One approach would be to use a hook in ready.php, adapting the method described in this post: You'd probably end up with something like this (not tested): wire()->addHookAfter('ProcessPageListRender::getPageLabel', function($event) { $page = $event->arguments('page'); $modifiedFormatted = date("j.n.Y", $page->modified); $event->return = $event->return . ' ' . $modifiedFormatted; });

I’m guessing header and footer come from prepend and append files. You’ll have to figure out a way to disable those in Ajax requests. For example, if you use $config->prependTemplateFile, just condition that with $config->ajax. //in site/config.php if (!$config->ajax) { $config->prependTemplateFile = 'head.inc'; $config->appendTemplateFile = 'foot.inc'; } You may need to set request.setRequestHeader('X-Requested-With', 'XMLHttpRequest') on your Ajax request for ProcessWire to automatically detect it as Ajax.

The most flexible version would probably be a monolog (or compatible) implementation, just because how ubiquitous it's in the php community and all it's adapters to various logging backends.