Leaderboard

The ProcessPageList module now has a configuration setting where you can select pages that should not be shown in the page list. For example, maybe once you've set up your 404 page, you don't really need it to display there anymore, except maybe in debug mode. Or maybe you don't ever need the "Admin" page to display in the page list. This new feature lets you do that, and for any page that you decide. Next, a "Usage" fields has been added to the "Basics" tab in the Field editor, just like the one in the Template editor (requested feature #445). This shows you what fields are using the template. It's essentially the same information that you'll find in the "Actions > Add or remove from templates" feature, but easier to find, especially for people newer to PW. That's all for this week, I hope you have a great weekend!

Great! Is there a chance to add hiding pages (and their children) by template or by custom selector. That would make the new feature more complete and useful IMHO.

You send you request to /scan without the ending slash. ProcessWire by default redirects to a url with an ending slash. And all parameters get lost during the redirect.

An old topic but I just hit this problem too, where I want to give an example of Markdown format in the field description without that actually being converted into HTML. I solved it by setting the Inputfield textFormat property in a hook: // Avoid Markdown in description/notes being converted into HTML // Adjust as needed for your Inputfield type and field name $wire->addHookAfter('InputfieldTextarea::renderReadyHook', function(HookEvent $event) { /** @var InputfieldTextarea $inputfield */ $inputfield = $event->object; if($inputfield->name === 'my_field_name') { $inputfield->textFormat = Inputfield::textFormatNone; } });

Thx for the quick and detailed answer ? Have you seen the new version? https://github.com/baumrock/rockmigrations#running-migrations What you describe is possible with a single file called /site/migrate.php (similar to /site/ready.php for hooks): https://github.com/baumrock/rockmigrations#quickstart No need for another module, no need for creating separate php files with php class notation for simple migration changes, no need for a CLI. Unless I'm missing something ?

@MrSnoozles You could take a look at using Migrations + RockMigrations (which work great hand by hand!) which satisfies exactly this. So you only substitute the "migration files" system, but use the invaluable abstractions from RockMigration. @bernhard interesting idea the tracking within the fields!

DDEV ?

The easiest and best way to setup this stack in my opinion is ddev. DDEV is an open source tool that makes it dead simple to get local PHP development environments up and running within minutes. It's powerful and flexible as a result of its per-project environment configurations, which can be extended, version controlled, and shared. In short, DDEV aims to allow development teams to use Docker in their workflow without the complexities of bespoke configuration. Me and @bernhard use it, and are very satisfied. I am using it on Windows 11 inside of WSL2. But it also runs on Macs and Linux machines.

I found a solution: instead of Wireframe::partial call $this->view->partials->get.

I have worked with a few multilanguage sites in ProcessWire and always found it so easy. We recently took on a WordPress site with multilanguage and wow, what a difference. I appreciate its all about the plugins that were chosen, but the plugin used is in the top 2 and it is so clunky. An entry for every language, so you have to upload the same images for every language just to change the text (I know there will be better ways to do this when you dig deep, but I am talking out of the box). Well done @ryan, when the next multilanguage site comes up I will always be confident in what we use.

@kongondo Confirmed! Thanks for updating.

@Jan Fromm Rest of the World is ready ?.

A week ago the new website of the wuppermann group went online. The Wupperman group is a EU-wide operating company with several locations in different countries. Their portfolio is all about steel fabrication. This includes flat producs, tubes & profiles. The technical production is developed by me, Olaf Gleba. The grafic design is supplied by C&G: Strategische Kommunikation GmbH. Homepage: https://www.wuppermann.com Some Impressions: (Secured) Shareholder portal, only available in german language Former screens deleted on behalf of the client. Technical notes: 1. All contents are populated by provided (i name them) content modules (e.g. Repeater Matrix Types) which gets the client what he needs and either prevent him from doing weird stuff. In nearly all textareas formatting is limited to a absolute minimum. For example, image insertion in CKEditor is generally prohibited. Instead there are dedicated fields for modules which holds media contents. 2. This and that.. - vCards are build on the fly with a admin hook on page save. - PrivacyWire as CCM (just a few cookies to handle Matomo and external movie content) - Uses the SearchEngine Module to handle (multilanguage) site search - Email Obfuscation Module for frontend e-mail addresses - Wire Mail Smtp to deliver automated e-mails - Multilingual (german, english, hungerian, polish, dutch) - Ajax driven content (for example on the contact page) - Heavy use of Fieldtype AssistedURL (Fork by @adrian) to provide language dependend, local file linking (fieldname_[de|en] approach) - Login area (closed shareholder portal) with secured file downloads ($config->pagefileSecure = true) - Email New User, Admin Action (create users batcher), Force Password Change for functionality like adding new users with specific roles, Password reset, Change Passwort a.s.o. - Distribution of concatenate/minified css and javascript is cachebusted (happens within my developement environment,- no modules (like AIOM etc.) involved). - Thanks to @ryan* all images are delivered in WEBP format (with fallback). *) s. https://github.com/processwire/processwire-issues/issues/1497 - The site uses a bunch of modules provided by the ProFields Package (for example Repeater Matrix and Table Fieldtypes).

@wbmnfktr thanks for starting this topic, very interesting! After reading all replies I think I get your point. I mostly develop with Django (Python) where DRF gives a powerful standardized API centered around models. Still, as you said, while working with other systems I always miss processwire for it's flexibility ;) From what I understood other systems include a REST API out of the box (more or less) where processwire "forces you to write some lines of codes" … and I guess that is the strength of processwire. It does not force you into a one fits all solution. My two cents: For an upcoming project I tested different solutions. With AppApi indeed I got resonable results in not 2 but 15 minutes. With JWT included, nice! (thanks @Sebi) For smaller needs URL hooks … for bigger needs –without auth– PageQueryBoss … –with auth– appAPI, is my way to go. But yes +1 for a core integrated solution that publishs pages based on standards . Doing so it would even be easy to get a clear, understandable and standardized API Documentation.

I just released a new extension module AppApiPage (waits for approval), which handles the initial steps from my post above completely automatic. You install AppApi and AppApiPage. That makes the /api/page route available and you only have to add the code on top of your template php to add a custom JSON output to your pages. <?php // Check if AppApi is available: if (wire('modules')->isInstalled('AppApi')) { $module = $this->wire('modules')->get('AppApi'); // Check if page was called via AppApi if($module->isApiCall()){ // Output id & name of current page $output = [ 'id' => wire('page')->id, 'name' => wire('page')->name ]; // sendResponse will automatically convert $output to a JSON-string: AppApi::sendResponse(200, $output); } } // Here continue with your HTML-output logic... I hope that this makes it even simpler to add a full-blown JSON api to new and existing pages.

Thx @Juergen that also helped me today. This is what I came up with (for future reference) when I needed to add a page clone button: /** * Add clone button to form */ public function addCloneButton() { // add button to form $this->addHookAfter("ProcessPageEdit::buildForm", function($event) { $form = $event->arguments(0); $form->add([ 'type' => 'submit', 'name' => 'btn_clone_plan', 'value' => __('Clone'), 'icon' => 'clone', ]); $form->get('btn_clone_plan')->addClass('ui-priority-secondary'); }); // process input $this->addHookAfter("ProcessPageEdit::processInput", function($event) { $form = $event->arguments(0); if($form != "InputfieldForm") return; // dont fire on inputfields if($this->input->post('btn_clone_plan')) { // tell PW to save the page $this->input->post->submit_save = 1; } if(count($form->getErrors())) { // clone only if there are no errors, otherwise do a regular save unset($this->input->post->btn_clone_plan); } }); // do the clone $this->addHookAfter("Pages::saved", function($event) { if(!$this->input->post->btn_clone_plan) return; unset($this->input->post->btn_clone_plan); // prevent endless loop! $clone = $this->pages->clone($event->arguments(0)); $this->session->redirect($clone->editUrl); }); } PS: This approach might be easier, but I wanted an extra button:

I'm sure it's the less used path, but a CLI is useful for anybody automating deployments either using some kind of CI/CD or manually called scripts. The goal of my migrations module was to result in reproducable db state, so automation is possible. If migrations can be run arbitrary times it's not going to do that – e.g. a field created and later deleted is not the same as a field deleted and later created. Therefore migrations have a fixed order (by timestamp) and a db table keeps knowledge about which migrations were already applied before.

Didn't want to imply your module needs anything or that it is "missing" something or that I was asking for a feature, I apologize if that's how it came out! Just wanted to give an example of an exception to the norm in case anyone finds this thread and of course, I agree it's the mission of all of us to contribute to open source and I must say this community has inspired me a lot to thrive into that direction rather than just consuming the work of others but also contributing, first step is to solve the very serious personal time management issues I have and just force me to do get open source done lol. So basically how it's useful for me is that, I keep a bunch of sites on one server and they all share template files and fields configuration. I keep files in sync using git and git worktrees, and with a shell script I make merges from the dev branch into the rest of the branches, including the migration files (each site is a branch). Then, if I need to make an update that involves any adding/removing fields I also have another shell script that goes on every site directory and runs a specific migration. It saves me a lot of time to run this for the 50+ sites I manage, I can very easily see if an error occurred, if migration was already run, if it didn't exist (then it means that site is now correctly wired up to the git repo), etc. Probably this is the least likely scenario of most PW users lol, as I have the feeling that most of PW users build heavily customized sites, for very specific requirements.

I use a zero-width space word joiner character to destroy the markdown: [Link-Beschreibung]⁠(http://www.beispiel.de) This will prevent users from copying it from the field description, though…

$page->numChildren is a whole lot faster and more efficient than $page->children->count(). In a case like this, I would stick with numChildren. It's okay if it's occasionally wrong with published or otherwise non-accessible page inclusions. Also $page->children->count() is one of those things you really can't use at the large scale, because it has to load all those pages. If you just need to check if a page has accessible children (regardless of amount), you can do: $hasChildren = $page->child->id > 0; To count all visible children: $numChildren = $pages->count("parent=$page"); I'll add a $page->numChildrenVisible property in the next commit.