ryan

@MarkE There's definitely a lot of potential for this to evolve over time. Another example is that it can edit any pages this way, not just children. For that reason, I put in a hook: ___getChildren($page) so that anyone can override what are the "children" for the page. If there is hierarchy, such as there would be if the selector "parent_id=$page" were changed to "has_parent=$page", then I agree the way repeaters do hierarchy could work here too. But I figure the best bet is to keep it simple, focused and straightforward at first to get to a stable version 1, and then start evolving it to do more after that, if there's interest.

@Jonathan Lahijani If you edit your child page template and temporarily enable $config->advanced = true; you can click on the "System" tab and check the box to have it show the "name" field on the content tab, which should do the trick.

With the current project that I'm working on, there's eventually going to be an enormous amount of data to edit within it (in ProcessWire), and so I've been looking for ways to optimize and facilitate the editing experience. The goal is to save the people editing as much time as possible, and reduce the number of steps necessary to make common edits. This is what motivated the recent Table field updates. The is also what motivated a new module I'm working on called PageEditChildren. The PageEditChildren module takes the existing "Children" tab in ProcessWire's page editor and replaces it with a new one that lets you edit all of the child pages inline, directly from the parent page. For specific cases, such as the one shown in this video (below), this provides a more convenient way to edit multiple pages at once. It can significantly reduce the amount of back-and-forth between the page editor and the page list, or multiple page editors, keeping it all in one page editor session. Likely you would use this module to replace the "Children" tab on just some (not all) pages. Specifically, pages where the relationship between parent and children is one where they are often edited as a group. This is a fairly common use case in ProcessWire, and one where this module can save you a lot of time. From an editing standpoint, it has a lot in common with repeaters. Other modules that have some crossover are PageTable (core) when configured to create/edit children pages, and BatchChildEditor. Both use page editors in modal windows to accomplish editing children, a different approach than PageEditChildren, which keeps it all part of the single page editor. Though BatchChildEditor can edit title and status (hidden/unpublished) inline, and supports CSV export/import options, among other useful tools. All of these modules are worth consideration when there is a need to optimize the editing experience between parent and children. This is just an early preview of PageEditChildren, so I'm going to work on the module and test it out a bit more before releasing it. But it could be ready to share as soon as next week. Supporting file/image and repeater fields in this module required some minor core improvements, which are in this week's core updates. I'm interested to hear your thoughts on whether this would be useful in your sites as well? More next week. Thanks for reading and have a great weekend!

@adrian I hadn't thought of that in awhile, is it something you have come up with a need for? It would probably be fairly simple for me to add.

This week we have another update to the ProFields table field. A couple of weeks ago I wrote a blog post about Table v28 and the new actions features that it added. I've been working with Table a lot for my current client project, and have found these new features very useful. But I'm doing a lot of data entry in Table and found I still wanted more. Specifically, I wanted to be able to apply some of the actions directly on the row I was working in (rather than having to select it and then scroll down to the actions). Kind of like how one can click the Trash icon on any row to delete the row... I wanted to be able to apply other actions in the same way (Add, Clone, Copy, Paste). And Table v29 (released today) does exactly that. Another desire I had is for the for row-level actions to be just really simple, with not too much to look at... something folks could use rapidly without having a lot to read. This leaves several powerful and verbose features for the actions menu you saw earlier (the one that appears under the Table). Below is a video that outlines these new row-level actions. It's actually the same video from before, but I added to it for the version 29 features. So I'll try to post a link that starts at the timecode of the new stuff. But if you haven't seen this video before, you may want to rewind to the beginning. Below is the full CHANGELOG for this version: Expanded actions support so you can also execute actions directly on individual rows, which is often more convenient than selecting rows and then applying actions. Hold down the SHIFT key before clicking the row actions select and it will convert any actions that usually append rows to instead prepend rows. This works with the the Add, Clone and Paste actions when clicked at the individual row-level. It also works with the Select action for selecting multiple rows at once. The Select action is there in part for people that may not realize you can already click the sort arrows to select the row. Removed the Vex dialogs when copying or pasting and replaced them with other visual cues to indicate successful copy and/or paste. Added a new config option for disabling the DELETE (trash) icon on individual rows when individual row actions are enabled. This is because the row actions already include a delete action, so the trash icon can be redundant for some who might prefer the additional space. For all non-page selection column types, a new "Settings" option was added (named “formattedValueType”) to indicate how the value should be represented when accessed from a formatted page. Previously the API value was always the selection value. Now you can specify that it should include both the value and label (in your choice of array), or just the label rather than the value. Table v29 beta is available for download now in the ProFields download thread. More core updates are likely for next week. Thanks for reading and have a great weekend!

This week we have ProcessWire 3.0.238 on the dev branch. This version contains 17 commits containing new features (some via feature requests) as well as issue fixes. Recent updates have been nicely covered in ProcessWire weekly issues #517 and #518. Also added this week are the following: Improvements to ProcessPageClone, which now supports some new options such as the ability to configure it to always use the full clone form (a requested feature), and an option to specify whether cloned children should be unpublished or not. New $datetime->strtodate($date, $format) method that accepts any PHP recognized date string and reformats it using the given format. It also supports date strings that PHP doesn't recognize if you give it a 3rd argument ($options array) with an `inputFormat`. The existing $datetime->strtotime() method now supports an `inputFormat` option as well. The Inputfield class now has new methods: $inputfield->setLanguageValue($language, $value) and $inputfield->getLanguageValue($language), added by the LanguageSupport module. Previously there were no dedicated methods for this, so you had to manage them with custom keys containing language IDs if you wanted to programmatically use an Inputfield in multi-language mode. The ProcessWire.alert() JS method has been updated with an auto-close option (`expire` argument) that automatically closes the alert box after a specified number of seconds. InputfieldDatetime has been updated with 7 new interactively configurable settings for the jQuery UI date picker. See the screenshot below for an example of a few. Plus, its API has been updated with the ability for you to specify or override any jQuery UI datepicker option, either from PHP or JS, as requested by Toutouwai/Robin S. See the new datepickerOptions() method and phpdoc for details. Next week we've also got some more updates to InputfieldTable that take the newly added actions even further and make them easier to use. Thanks for reading and have a great weekend!

This week we have some updates for the ProFields table field (FieldtypeTable). These updates are primarily focused on adding new tools for the editor to facilitate input and management of content in a table field. All the details can be found in the new blog post with an accompanying screencast video— https://processwire.com/blog/posts/table-field-with-actions-support/

@TomPich I wouldn't recommend caching a field value like that, as I don't think you'll get any performance benefit since the amount of work for PW to do is the same either way there. What I'd recommend doing instead is caching the resulting output, which also means only loading the repeaterConsultants when it will be used to generate that cached markup. Whatever markup you generate, use that as your cache value, for example: echo $cache->get('consultants', 'hourly', function() use($pages) { $out = ''; $consultants = $pages->get(1027)->repeaterConsultants; foreach ($consultants as $consultant) { $out .= "<li>$consultant->consultantName</li>"; } return "<ul>$out</ul>" ; });

@iank I had a look at this and it seems like it can happen if you omit homepage language segments, and are also using the PagePathHistory module. What happens is that PagePathHistory provides a shortcut for finding the page, leaving no language segments for PagePathHistory to detect the language. I don't think PagePathHistory supported multi-language URLs until 3.0.186, so maybe that's when the issue started. Though the entire URL-to-page mapping system has been rewritten since 3.0.165 via the new PagesPathFinder class, so who knows. I think maybe it's not been reported before because just about everyone is using language segments on the homepage, and I always recommend doing so, but didn't intend to require it. I've attempted a fix on the dev branch, it's just one line of code, so maybe it'll work just to modify your copy too. Do you find this fixes it there? https://github.com/processwire/processwire/commit/9e6b89cf9331fccb8f41ae0b1785e21c8c5d62f0

@Robin S That's correct and good to point out. The term "move" refers to manual sorting, changing parent, or both.

On the dev branch this week are a few issue fixes, but also some new features. The "Parent" field in the page editor (Settings tab) now is contextual to the page's template family settings. Now it will just show you the allowed parents, if you've configured them in the template. Previously it would show you a page tree to select from anywhere in the site. This saves you time, as well as the hassle of getting an error message after save, should you select a parent that isn't allowed by the page's template family settings. Next, the page tree "Move" actions (that you see when hovering a page in the tree) are now a little smarter. Previously, these Move actions would appear for any page that was either sortable or moveable. But now it also checks how many other allowed parents there are, per template family settings. If there aren't yet any other potential parent pages existing in the site, the page is no longer considered moveable, and thus won't show a Move action. This useful addition was added per Bernhard's request, as was the addition to a couple new classes used in the page tree to better differentiate between public vs non-public pages... something that I understand Bernhard's admin style may soon demonstrate. This week a question came up through email about how to make multi-language "required" fields require a value in all languages the page is active in. Currently multi-language required fields only require a value to be present in the default language. If you want to make them require all active languages, you can do so with a hook in /site/ready.php. I thought it was pretty useful so thought I'd share it here. Though maybe we'll have to add it as a feature. if($page->process == 'ProcessPageEdit') { $wire->addHookAfter('Inputfield(required=1,useLanguages=1)::processInput', function($event) { $inputfield = $event->object; $page = $inputfield->hasPage; if(!$page) return; foreach($event->wire()->languages as $language) { if($language->isDefault()) continue; if(!$page->get("status$language")) continue; // skip languages not active on page $value = $inputfield->get("value$language"); if(empty($value)) { $inputfield->error("Value required for language " . $language->get('title|name')); } } }); }

Pruning is kind of an expensive operation as it involves finding existing log entries, exporting them to a new file, then deleting the old file, then renaming the new file to the old filename. I'd avoid doing it every time you save a log entry. I prefer to manually prune from the admin. The error messages seem to indicate that maybe the prune is colliding with the save. Likely pruning immediately after saving is happening in the same timestamp and not giving it a chance to consistently save a log entry. So at the least, I would disconnect your prune() operation from your save() operation, perhaps moving your prune operation into a LazyCron::everyDay hook.

This week we have a new core version on the dev branch. Relative to the previous dev branch version, the new 3.0.237 version has 33 commits containing 20 issue fixes, 6 feature requests, and more. See the core updates section of ProcessWire Weekly 511, 512, 514 and 515 for more details. It's been about a month and a half since 3.0.236, which is a little longer than usual between version numbers, but that's largely because if the new Invoices site profile (see blog post). I'm off work tomorrow (Friday), so writing the usual weekly post a day early. As always, thanks for reading and I hope you have a great weekend!

That sucks, but I'm guessing they might make exceptions for some projects, so I'll have to ask them. Still, not nearly as much of an issue as what CKEditor did. But if it stays GPL and they don't make an exception for any projects, then most likely we couldn't include TinyMCE 7 with the core. In that case, we'd develop it was a non-core module, and folks would have to install it as a 3rd party module (in /site/modules/). ProcessWire's core is completely separate from what people develop or what they might add-on their site, so they don't have to share the same license. PW is built so that modules are independent of ProcessWire in the same way WP and PW are separate applications that can run on the same webserver, or a website is independent of the webserver that's delivering it, or a browser is independent of the HTML it renders or JS it executes. https://processwire.com/about/license/3rd-party-files/

This week there is a new version of the Site Profile Exporter module released (ProcessExportProfile). This is the module that was used to export last week's Invoices Application Site Profile. While this module has been around for a decade now, this latest version makes some nice improvements, which I'll cover below. @bernhard pointed out to me that he's using the module to make a new site profile, but he found it cumbersome to enter all the profile information every time he wanted to export the profile. So this new version now lets you update an existing profile with 1-click, making it much easier to re-export a profile. This version also adds a preview of what your profile will look like in the ProcessWire installer (the part where the user would select it for installation). Lastly, this version has several other small improvements and fixes as well. If you've ever thought of building a site profile, this module now makes it that much easier. This week I've also been starting to focus on the next long term client project, which is kind of a different and unique one that I look forward to. That's in part because I expect it will also involve a lot of improvements to the ProcessWire core and ProFields modules as part of it. Some of my favorite ProcessWire improvements have accompanied projects like this. There just isn't any substitute for real-life, large-scale projects when it comes to improving and optimizing the core and modules. Next week will be a shortened week here, so I'll likely post the usual weekly update Thursday rather than Friday. Thanks for reading and have a great weekend!

@joe_g It looks to me like you've got an autoload module that's injecting scripts into your admin (a cookie content module or SEO type module?). Such a module should only be injecting scripts into the front-end, and not into your admin. So I would identify what module is doing that and stop using it, or update it to only load on the front-end. It you can identify what module it is, let me know and I can suggest what to change about it. Likely it's just a change to 1 or 2 lines.

@joe_g In addition to what Bernhard mentioned, I would figure out the location of the prepareInjection.js file at the top of your JS console. That looks like a React file, and I'd wonder why it's loading here. Perhaps it's coming from some module? You should be able to click on it to identify the location, or view your Network tab and find it. You might see it coming from some site/modules/ModuleName/ directory? If so, try temporarily disabling that module to see if that's the issue.

The invoices application site profile that I uploaded last week now has a companion blog post: https://processwire.com/blog/posts/invoices-site-profile/ Thanks for reading and have a great weekend!

@fruid The cache time should be fine. I'm guessing maybe it just didn't work on the first use for whatever reason, and the non-working data was cached.

@fruid Make sure you are using the newest version (version 3). Go to Modules > Site > ServiceCurrencyConversion. At the bottom is a checkbox to "Refresh rate data now". Check the box and save. Now make sure that you see HKD in the table shown on the configuration screen. If you don't, edit your /site/modules/ServiceCurrencyConversion/currencies.txt file and make sure it's in there, adding it if it isn't, and refreshing again. If you don't see any data loaded, I'm guessing that your server is blocking the outbound http request to the exchange rates API. You could modify the module WireHttp call to force it to use CURL or fopen, depending on what your server supports. Let me know if you need help.

@teppo Not very straightforward, but here's a function that would tell you whether or not a translation exists for the given phrase in the given file, in the current language. Maybe we need a dedicated core function for it? function isTranslated($text, $textdomain) { $translator = wire()->user->language->translator(); $translations = $translator->getTranslations($textdomain); $hash = $translator->getTextHash($text); return isset($translations[$hash]) ? $translations[$hash]['text'] : false; } Example $text1 = 'About Us'; $text2 = isTranslated($text1, '/site/templates/about-us.php'); if($text2 === false) { echo "Not translated: '$text1'"; } else { echo "Translation of '$text1' is '$text2'"; }

This week the new ProcessWire Invoices site profile has been released on GitHub here: Invoice Application Site Profile. This particular profile is much broader in scope than the others I've developed for ProcessWire, so will benefit from more descriptive information about what it includes, how to use it and modify it, and how you might build further from it. That info will all be coming next week in a new blog post. But feel free to download and install the site profile sooner if you'd like. If you are already familiar with ProcessWire, then perhaps most of it will be self explanatory. While this site profile doesn't cover everything that you might do with an invoicing application, it does cover everything that I've needed over the last year of using it with my clients. Though admittedly, I don't have a lot of clients, nor do I send a lot of invoices. Given that, when my existing invoicing service raised the monthly rate from $3/month to $20/month (a year or so ago), that's what motivated me to build this site profile. And it does everything my previous invoicing service did, and in fact does it better. While much of it was built several months ago, major improvements have been made to it over the last couple of weeks, preparing for it for release as a ProcessWire site profile. My hope is that you'll find this site profile easy to work with, and easy to build out further where needed. For instance, I imagine some may want to add in the ability to pay an invoice. It would be relatively simple to add in FormBuilder with its Stripe Processor plugin, or perhaps some other payment solution. But all my clients pay by check, whether physically or digitally, so I've not needed to add payment ability to the application yet. In any case, I hope that you find this site profile useful, and please let me know if you run into any issues with it or have suggestions for future upgrades to it. Thanks for reading and have a great weekend!

@hellomoto It looks to me like you can drop the use of DatabaseQuerySelectFulltext. I don't see any text columns or fulltext indexed columns in your query, and I don't think it's doing anything at present. That DatabaseQuerySelectFulltext class is primarily for doing partial matches on text columns, most often using MySQL's fulltext indexes. Your schema doesn't have any columns that would typically be used with this class, and I don't see any indexes on the columns. Currently I'm wondering if you even need a getMatchQuery() method? Your schema is pretty simple, and it seems like the core Fieldtype::getMatchQuery() should handle it fine. If not, can you give me an example of a selector that is not working? (remove or comment out your getMatchQuery method completely to test). The only thing I can spot in your schema that confuses me is the CHAR column with no length specified. I've only ever seen CHAR(n), where n is the fixed length of the CHAR column. Would "CHAR" be the same as CHAR(0), which either holds a 0-length string or a null? If so, then this may be a reason to have your own getMatchQuery, as PW consider blank string and NULL to be the same when querying the DB. So a simpler solution might be to just change it to a TINYINT, CHAR(1) or ENUM, so that you can be explicit about the ON or OFF (1 or 0, etc.) value, rather than trying to distinguish between two empty values (blank vs. null). Then it should work with the core getMatchQuery. The sf1 and sf2 columns may need to be indexed for best performance though.

There are a few commits on the dev branch this week, but nothing particularly notable. I had to do some client work this week but also ventured back into the Invoice site profile, which I mentioned quite awhile ago, but hadn't yet released. I'm hoping to finish that up and release it as another site profile option for ProcessWire very soon. Perhaps as soon as next week. I had originally planned on building out that Invoice site profile quite a bit more, but having used it for my own invoices for many months (maybe a year?), I think it's better to keep it simple. Otherwise I'd be making assumptions about what others might need. Even in its relatively simple state, it suits my own needs well. And I think if it gets more complex, then people are less likely to explore and modify it, making it less useful as a site profile. The site profile is also simple enough right now that it doesn't need to be a Pro module or need Pro-module support. Since we don't have a lot of site profiles to choose from, I'd rather keep it free. It is admittedly more of a mini application than a website, which is why I think it might bring some more diversity to the available site profiles. Chances are it won't replace whatever invoice service you might be using, but I think it's still pretty useful, whether using it to create invoices, or just using it to explore more of ProcessWire. More next week. Have a great weekend!

@hellomoto It looks like you are building a custom Fieldtype? If so, can you paste in the contents of your getDatabaseSchema() method? Matching an empty value can depend on the schema, though usually is handled by an OR condition that matches an empty string or the non-presence of a row. Matching the non presence of a row is done by performing a LEFT JOIN on the field_* table along with a WHERE condition that matches "IS NULL field_table_name.pages_id". It can be a little tricky, so luckily PW handles this situation for you internally, and doesn't require your Fieldtype to handle it unless you tell PW that you want it to… To describe further, ProcessWire matches empty values automatically, and so may not even call your getMatchQuery() for most empty-value matching selectors. But if PW isn't correctly matching it for you, then you may need to implement your own "empty" match logic. PW asks your Fieldtype::isEmptyValue() method (if implemented) if you would like to handle that situation (details). If it sends a Selector object to your isEmptyValue() method and your method returns true, then you are telling PW you want to handle matching the empty value: public function isEmptyValue(Field $field, $value) { if($value instanceof Selector) { // tells PW your getMatchQuery will match empty values return true; } return parent::isEmptyValue($field, $value); } So if you have a method in your Fieldtype like above, then your getMatchQuery() would have to have logic to match an empty value. I don't think your current getMatchQuery() would correctly match an empty value, so I'd need to see the schema to identify what would be needed.