Robin S

MarkupAdminDataTable::action() is a method that you call, not a property that you set. You would call the method like this: $table->action(['Home' => './']);

See here:

Added in v0.2.1

The trailing slash setting is something that applies to URLs rather than paths, i.e. $page->url rather than $page->path. Related GitHub issue with response from Ryan: https://github.com/processwire/processwire-issues/issues/273

Hi @adrian, thanks for the report. Please update to v0.4.4 and it should work.

I've added support for "Page (Autocomplete Single)" columns in v0.2.0.

Not a solution for VSCode but just for comparison... PhpStorm automatically adds the parent folder to the tab label as soon as two files are open with the same name. It's a nice feature.

Yes, it's InputfieldTextTags: https://processwire.com/blog/posts/pw-3.0.177/

Select Once Per Table Adds a setting to "Select", "Page (Select)" and "Page (Autocomplete Single)" columns in a ProFields Table field so that each option can only be selected once per table. Requires the ProFields Table module. There could be a number of situations where this module might be useful, but perhaps the primary situation is when you want to store extra information for pages that are selected in a Page Reference field. So instead of using a Page Reference field like this... ...you could use a ProFields Table field together with Select Once Per Table to store extra information for each selected page like this... The module ensures that pages/options that are already selected in the Table field are disabled as you add new rows or edit existing rows. Configuration To enable the module for any "Select", "Page (Select)" or "Page (Autocomplete Single)" column in your Table field, edit the column settings and add selectOnce=1. https://github.com/Toutouwai/SelectOncePerTable https://processwire.com/modules/select-once-per-table/

I'm not clear on how this relates to the Connect Page Fields module. Could you explain a bit more about how the module is involved in the error?

@Orkun, in case you missed it, Ryan has fixed this issue: https://github.com/processwire/processwire-issues/issues/1482

I see what you mean. It does seem like a bug that Ryan should take a look at. Edit: GitHub issue opened. https://github.com/processwire/processwire-issues/issues/1482

Answer to a similar question here:

In your template file: if($input->get('print')) { // Your special print-friendly markup here } else { // Your normal markup here } In your normal markup include a link to the print-friendly view: <a href="<?= $page->url ?>?print=1">Print-friendly view</a> If you want to automatically open the browser's print dialog you can include this in your print-friendly markup: <script> window.print(); </script>

I don't think $event->replace = true is supposed to have any effect on whether an "after" hook fires for a method - it just means that the code inside the hooked method will not execute. If you're trying to stop subsequent hooks from firing then have a look at $event->cancelHooks (https://processwire.com/api/ref/hook-event/)

I suggest checking that the PHP extensions and settings are the same between your PHP 7.4 instance and your PHP 8 instance. For example, someone posted recently with the same issue and found that the problem was due to unexpected settings in php.ini

I can confirm this. It's like the order of the field names is treated as if they are in order of priority, but I don't think this is expected - all the fields in the OR condition should be treated equally. Could you please open a GitHub issue so Ryan is alerted? https://github.com/processwire/processwire-issues/issues

A few suggestions: 1. It's best to match using a page's ID rather than its name, because the ID is globally unique but the name is not. So instead of... $pages->find("template=Technique, relation_technique_substance.relation_technique_substance_select=$page->name") ...you can do... $pages->find("template=Technique, relation_technique_substance.relation_technique_substance_select=$page->id") ...and because the string value of a Page object is its ID it's typical to do... $pages->find("template=Technique, relation_technique_substance.relation_technique_substance_select=$page") 2. You don't need to create a PageArray and add pages to it because $pages->find() already returns a PageArray. So this... $techniques = new PageArray(); $selector_tech = "template=Technique, relation_technique_substance.relation_technique_substance_select=$page->name"; $techniques->add($pages->find($selector_tech)); ...can be simplified to... $techniques = $pages->find("template=Technique, relation_technique_substance.relation_technique_substance_select=$page"); 3. PageArrays have a count() method/property, so rather than... if (sizeof($techniques) > 0) { ...try... if ($techniques->count) { 4. To answer your main question, the value of a Repeater field is a (Repeater)PageArray so you can use ->find($selector) to search within it. foreach ($tech->relation_technique_substance->find("relation_technique_substance_select=$page") as $relation_technique_substance) { Now any Repeater items where relation_technique_substance_select does not include $page will be excluded.

It's working inside a Repeater for me. This module works via JavaScript, and only with the inputfield. You're showing an SQL error but this module won't be anything to do with that. If a totally different inputfield is also affected then it's unlikely to be anything to do with this module.

I think I've found a fix for this. Please update to v0.3.3 and let me know if that version resolves the issue for you.

You would need to edit the module to add the permission settings in the getModuleInfo() method or equivalent "info" file. You can refer to Ryan's ProcessHello module as an example: // name of permission required of users to execute this Process (optional) 'permission' => 'helloworld', // permissions that you want automatically installed/uninstalled with this module (name => description) 'permissions' => array( 'helloworld' => 'Run the HelloWorld module' ), If you want the permission to be automatically installed you would need to uninstall and then reinstall the module.

Thanks to @monollonom in v0.2.5 you can now use the module to add files/images to fields using the API. From the updated readme: A addFromUrl method is also added to the API to achieve the same result. The argument of this method is expected to be either: a URL: "https://domain.com/image.jpg" an array of URLs: ["https://domain.com/image1.jpg", "https://domain.com/image2.jpg"] Example: $of = $page->of(); $page->of(false); $page->file_field->addFromUrl("https://domain.com/path-to-file.ext"); // No need to call $page->save() as it's already done in the method $page->of($of); Should you have an issue using the method, please have a look at the "errors" log to check if something was wrong with your URL(s).

Welcome to the PW forums ? PW doesn't currently provide a way to find pages by the length of a field value. Although I think it would be a nice feature so I took the liberty of opening a request: https://github.com/processwire/processwire-requests/issues/424 Technically you could achieve it with a custom SQL query: $sql = 'SELECT pages.id FROM pages LEFT JOIN field_title ON field_title.pages_id = pages.id WHERE CHAR_LENGTH(field_title.data) > 10 AND pages.templates_id != 2 AND pages.parent_id != 2 AND pages.parent_id NOT IN (SELECT pages_id FROM pages_parents WHERE parents_id = 2 OR pages_id = 2)'; $ids = $database->query($sql)->fetchAll(\PDO::FETCH_COLUMN); $results = $pages->getByIDs($ids); But you might find it simpler to stick with what you're already doing.

Check that the "Inputfield column widths" setting in the AdminThemeUikit module config is the same before and after the upgrade. If you want to avoid the JS-set widths then I think you want the "Uikit uk-width classes" option.

As a general rule (not related to PW specifically), when you see an inline style in the DOM it's almost always an indication that the style was added by JavaScript. It's not because somebody has some preference for inline styles as such. So if you see an inline style in the PW admin it's probably because the style needs to be set dynamically by JavaScript (or needed to be at the time the admin theme was authored). No doubt. But some of the bundled PW admin themes pre-date widespread browser support for flexbox. And fully overhauling a legacy admin theme would be huge job that I expect is not a major priority for Ryan. I haven't seen this in AdminThemeUikit, which is the most recently added core theme. If CSS3 features like flexbox are important to you then this is the admin theme you want to be using.