Leaderboard

This week's commits are primarily focused on resolving reported issues (via GitHub issue reports). While that doesn't make for exciting reading here, it's an important part of working towards our next master version. Though I am working on various other projects including client websites running in ProcessWire, ongoing updates to Pro modules and development of other ProcessWire modules. One module I've been working on this week (and last week) enables you to export translations for multi-language fields into JSON or CSV files. These files can be read into other translation systems, edited, and then imported back into ProcessWire. So if you need all the content for a site translated from one language into another, it provides a very convenient means of doing so. More details on that one soon. That's all for today but stay tuned and thanks for reading. Have a great weekend.

As a side note, if the new site is an enhancement of the old site (rather than a totally new site built from scratch) and you have PagePathHistory installed (a must-have on every site) then you should be able to move the existing news articles to any new path and PW will automatically redirect visitors from the old location to the new location. But if it's a new site from scratch where the IDs of historical news articles are now different to the old site, then I suggest doing the redirects using the PW API rather than manually entering a long list of redirects in htaccess. There are different ways you could do it. You could hook ProcessPageView::pageNotFound or use URL segments on the template for the /news/ page. Both would be fine, but I think the latter is a bit easier. Enable URL segments on the template for the /news/ page, and at the top of the template file: // If there is a URL segment (i.e. no real page exists at the requested URL) if($input->urlSegment1) { // Check for a published news article with that name $article = $pages->findOne("template=your_news_article_template, name=$input->urlSegment1"); if($article->id) { // If match found then redirect $session->redirect($article->url); } else { // Otherwise throw 404 throw new Wire404Exception(); } } // Only one segment is allowed if($input->urlSegment2) throw new Wire404Exception();

Here's a conversation on reddit whether Composer could be susceptible to a similar attack

This module for ProcessWire enables the debug mode to bypass the restriction to install modules. This is useful if you are tired to manually set the debug mode in the configuration. Note Please note that this module doesn't replace the real debug mode in the configuration file /site/config.php. With this module you will not receive any errors/notices/warnings like in the real debug mode. It serves only to bypass the restriction to install modules. Installation To install this module you have to enable the real debug mode. After installation you should deactivate debug mode again. To enable the real debug mode, download /site/config.php via FTP and open it in a text editor. Look for a line where you can find $config->debug = false; change it to $config->debug = true; save the file and upload it again. After module installation change it back to $config->debug = false;. For all future module installations, you just have to enable the debug mode in the module settings like described below. After module installation, you should deactivate it in the same way. Settings The settings for this module are located in the menu Modules=>Configure=>DebugModeSwitch. Enable or deactivate debug mode Set the checkmark (1) and click the submit button (2) will enable the debug mode (3). The debug mode can be also restricted for superusers only (4). Links ProcessWire module directory: https://processwire.com/modules/debug-mode-switch/ Github: https://github.com/techcnet/DebugModeSwitch

So... just a short heads-up... a node.js module that's widely used - even in vue.js and well known software - was compromised by its developer. It seems that the repository was already cleaned-up again, yet in case you installed the module itself or something with it the last couple of days. Take a closer look, clean it up, fork a clean version whatsoever. https://snyk.io/blog/peacenotwar-malicious-npm-node-ipc-package-vulnerability/ node-ipc-dependencies-list https://github.com/zlw9991/node-ipc-dependencies-list Video with some more details about the whole issue.

@MarkE, the SelectizeAll module itself doesn't get involved with the change event. The problem is likely to be an incompatibility between the Selectize and htmx libraries. I can't do much about that, but in the newly released SelectizeAll v0.1.2 you can disable the module for an inputfield by giving it a "no-selectize" class. So when you create a select or AsmSelect inputfield in your module you would add a line like this... $inputfield->addClass('no-selectize'); ...and then if the two modules are used together your selects/AsmSelects won't be "selectized".

I think this works @kongondo $(document).on('reloaded', '.InputfieldRepeater', function (event) { htmx.process(this); }) Now I have the (non-trivial) task of working out how to target the right repeater item and swap in the converted measurement ?

Oh...kay... now I get it. Sure this could happen in some way in or with Composer as well. The r/thread is a nice read. This whole scenario was always the reason why I rarely used and use NPM or Composer - it's so often a big blackbox.

I meant composer as a package / dependency manager. It would also be vulnerable to a similar attack.

Great news! I've been trying to import data to and from services like Weblate and Crowdin several times to establish a collaborative effort to PW core and main modules translations. I've spent quite some time to make it work, I did communicate with these services' support, but couldn't make it easy with the current PW translations exports. Hope, that this module will make this task possible to complete. I wish we could somehow support the continuous type of translation workflow, but not sure it is possible without some intermediate steps, as translation files are not in the repo. Mentioning it here just in case)

?

The "Multiple page selection" version of Page Auto Complete doesn't support the "Custom PHP code" option (i.e. the InputfieldPage::getSelectablePages hook). In earlier versions of PW it used to be more explicit about that. Now it just removes the "Custom PHP code" option depending on what you have selected in "Input field type". Page List Select and Page List Select Multiple also do not support the "Custom PHP code" option. If you really are returning something like that from you hook then you could change to the "Selector string" option, which will work with autocomplete.

@netcarver Have you tried using boot.php? In site/config.php $config->statusFiles = array( 'boot' => 'boot.php', 'init' => 'init.php', 'ready' => 'ready.php', 'finished' => 'finished.php' ); and in boot.php <?php namespace ProcessWire; wire('classLoader')->addNamespace('Wireframe\Blocks', paths('templates') . 'blocks/'); wire('classLoader')->addNamespace('Wireframe\Traits', paths('templates') . 'traits/'); I don't remember if I used traits in pages classes or in some other parts of the code, but you can try.

Hi @Frank Schneider Have you enabled urlSegments in template settings for mitglied_edit page?