Robin S

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.

I guess you could exclude pages that are in the trash by changing... $referenced_on = wire('pages')->find("$pr_fields_str=$page->id, include=all"); ...to... $referenced_on = wire('pages')->find("$pr_fields_str=$page->id, include=all, status!=trash");

Thanks for tackling this project! If the rrule for an event doesn't need to be searchable via $pages->find() then you could store it in $page->meta() and use the standard field table for the event occurrences. And if there really was a strong need to find event pages by rrule then you could add a custom search method that queries the pages_meta table.

I think you must have some other bug in your code. When doing $some_pagearray->add() this is WireArray::add() and the argument can be a single item or a WireArray of items. So there shouldn't be any problem adding multiple pages to the PageArray like this. My two "basic_page" pages with colours in a "multiple" Page Reference field: And you can see the result: By default a Page can only exist once in a PageArray so you'll notice that the "Orange" page is not duplicated in the PageArray despite being selected on both pages. The order of colours looks a bit random but you can apply whatever sort you want by doing something like... $colours->sort('title'); ...or... $colours->sort('sort'); ...before the PageArray is output in your template.

When adding/saving Repeater items the sort order is determined by the "sort" value of each Repeater page, not by any order you might apply to the Repeater PageArray. An explanation of sort values is here. You could use the $pages->sort() method to set the sort value of the Repeater page you're adding and it will automatically update the sort values of the sibling Repeater pages. $thatPage->of( false ); $newItem = $thatPage->my_repeater->getNew(); $newItem->foo = 'bar'; $newItem->save(); $thatPage=>my_repeater->add( $newItem ); $thatPage->save(); // Set the sort value of the new item to 0 and adjust sibling sort values $pages->sort($newItem, 0);

FieldtypeConcat causes the same error, so that will add to the argument for a core fix.

@adrian, it might be that every Fieldtype needs to create a table in the DB regardless of if it is used or not. For instance, FieldtypeFieldset creates a table that is never used. FieldtypeRuntimeOnly originally did create a DB table because I based it on FieldtypeFieldset, but later versions prevented the table from being created after a pull request from you. You could open an issue on the PW repo to see if Ryan will add a check in findRaw for fieldtypes that do not have a corresponding table, but if he's not willing I think the only fix will be to go back to creating a table for FieldtypeRuntimeOnly fields on field creation.

@Ksenia, I read your post a few times but I'm not sure I understand what you're trying to do. A couple of things that might help... 1. The space after the equals sign in the selector here is wrong: $selector_ind .= ", relation_individual_technique.relation_individual_technique_select= $selected_technique"; It should be: $selector_ind .= ", relation_individual_technique.relation_individual_technique_select=$selected_technique"; 2. If you're trying to get a PageArray of organisations, and those organisations are referenced in a Page Reference field in individual pages then you can do something like this: // A new empty PageArray that will hold the organisations selected for all the individuals $organisations = new PageArray(); // The $individuals PageArray has been created elsewhere in your code foreach($individuals as $individual) { // Add to $organisations from the "organisations" Page Reference field $organisations->add($individual->organisations); } // Now do something with $organisations

Why not use a JS modal to confirm age rather than redirecting to another page? Like this: https://www.vineonline.co.nz/

Welcome to the PW forums! A URL segment is suitable for a single tag but not for multiple tags. The simplest way to submit multiple tags is via checkboxes in a form. If you want a different appearance (e.g. something that looks more like buttons instead of checkboxes) then once you have the basic form working you could hide the checkboxes with CSS and show some buttons that check/uncheck the hidden checkboxes using JavaScript. This is a generic example but you can adapt it to your scenario... At the top of your template file: // Get your tag pages $tags = $pages->find("template=tag"); // Get the array of tags that the user has submitted via the form $selected_tags_raw = $sanitizer->array($input->get('tags')); // Sanitize the tags against the valid tags $selected_tags = $sanitizer->options($selected_tags_raw, $tags->explode('name')); // Build up a selector string $selector = "template=document"; // Add the selected tags to the selector string - these will use AND logic foreach($selected_tags as $selected_tag) $selector .= ", tags=$selected_tag"; // Find the matching pages and later output them wherever you need $matches = $pages->find($selector); And later in the template file markup where you want the form to appear: <form action="./" method="get"> <?php foreach($tags as $tag): ?> <?php $checked = in_array($tag->name, $selected_tags) ? ' checked' : '' ?> <label><input type="checkbox" name="tags[]" value="<?= $tag->name ?>"<?= $checked ?>> <?= $tag->title ?></label><br> <?php endforeach; ?> <button>Submit</button> </form>

I'm not sure if I'm a typical user, but I would only want the import/export features on fields where I've specifically enabled them, and doing it that way would mean I have to remember to disable the import/export any time I add a new Table field. If nobody has mentioned this need until now maybe it's quite rare and hookable methods would be enough for those who need it? In the short term I edited the module and added... public function ___allowExport(InputfieldTable $inputfield) { return true; } ...and near the top of TableCsvImportExport::buildTableExportForm()... if(!$this->allowExport($event->object)) return; ...and in my ready_admin.php... // Only show Table CSV export option on selected tables $wire->addHookAfter('TableCsvImportExport::allowExport', function(HookEvent $event) { $inputfield = $event->arguments(0); $field = $inputfield->hasField; if(!$field || $field->name !== 'plant_votes') $event->return = false; }); So one option would be to add something like this for both import and export options, and people who need it can use hooks to do tests on field, page, user, etc and return false whenever they don't want the import/export features to be available.

@adrian, could you please open a GitHub issue or raise this in the RuntimeOnly support thread? I'd like to confirm a few details but don't want to take this thread off-topic.

I've never seen a file at that path before. My sites don't even have a "/wire/config/" directory.

I was just trying to think if there was a way to achieve what I wanted without changes to the module. I saw that the module was adding the import/export features according to a permission so thought I might be able to grant that permission selectively at runtime. But I later realised that the permission is checked at the ready state rather than before the InputfieldTable render so even if my idea was possible I'd have to set the permission at every page load which would be a bit over the top. I think that a couple of extra checkboxes on each Table field config would be ideal - something like "Allow CSV export" and "Allow CSV import", although it would still depend on the user having the relevant permissions so there should probably be a note about that. Existing users of the module would expect to have these options checked on all existing fields and I guess you could deal with that in the module upgrade() method. Thanks!

Hi @adrian, My first time using this module - looks amazing, thanks! (silly me, I've used the awesome import features before) In my site I have a number of Table fields that are used for various purposes, but just one Table field that I want to allow users to export to CSV from. I couldn't see a way to show the export interface just on this one field. Any tips on how I could achieve this? Or would you consider adding a hookable method that would determine if the import/export interface gets added to each Table field? (the relevant permissions would still apply) Thanks. Edit: very minor thing... in AdminThemeUikit there is an outline around the inputfield that has the export iframe and this looks a bit weird. Not sure if there is a better way but I hid it with some custom CSS: .Inputfield_tableExportIframe { outline:none; }

Do these inputfields have a column width set so that they all appear in the same row? If so then I think it is recent core behaviour that collapsing one inputfield in a row collapses all the fields in the row. This didn't use to happen but it did make for some weird gaps and outline anomalies when a single inputfield in a row was collapsed, so the new behaviour is probably better. So if you have an inputfield that will usually be collapsed I think the best thing is to put it on a separate row within the fieldset.

@PascalKonings, the suggestion from @Zeka is probably the way to go, but in case you do want to stick with image tags you can set them dynamically in a hook in /site/ready.php: // Dynamically set the selectable tags for an images field $wire->addHookAfter('InputfieldImage::renderReadyHook', function(HookEvent $event) { /** @var InputfieldImage $inputfield */ $inputfield = $event->object; // The images field $field = $inputfield->hasField; // The page that the field is on $page = $inputfield->hasPage; // Only for a specific images field if(!$field || $field->name !== 'your_image_field') return; $config = $event->wire()->config; $js_name = "InputfieldFileTags_$field->name"; $data = $config->js($js_name); // Set the tags however you like, using $page if needed $data['tags'] = [ 'carrot', 'pumpkin', 'cauliflower', ]; $config->js($js_name, $data); });

I believe so, but the simplest thing would be to try it and see.

The Limit Table module (previously not in the modules directory but I just added it) adds this feature to Profields Table.

Thanks for the suggestion. I'll keep it in mind but for now will leave the interface as it is for a couple of reasons: The intention with this module is just to create a temporary mode to activate when doing a drag sort, and leaving the repeater interface as per the core default at other times. At this point I don't want to get into making broader changes to the repeater interface: hacking controls into the inputfield header (the core doesn't make this easy to do), setting a default view mode, storing the view mode in a cookie, etc, like what is done with image fields. I'm predicting that users will first identify the item they want to drag with the repeater field in its normal mode. When easy-sort mode is activated the repeater items move quite a bit from their original position, and it's a feature of this module that the item you want to drag gets identified with a black background so it's easier to locate. This requires a button per repeater item rather than a single button per repeater field. Fixed in v0.1.1. Although personally speaking I gotta say... I wish @ryan would drop those ancient legacy themes from the core because it's a real hassle for module developers to support multiple themes. The Uikit theme has been the default standard for several years at this point and it's the only theme that's likely to get attention and further development going forward, so PW users should get on board with it. I only test my modules in AdminThemeUikit but will consider compatibility fixes for legacy themes on a case-by-case basis.