Robin S

I had a look at this, and it seems it isn't possible to directly set the optionAttributes property of inputfields that extend InputfieldSelect. That is probably why @kixe made this module. But what you can do is use a hook to remove the existing options, and then add them back with some attributes... $wire->addHookBefore('InputfieldCheckboxes::render', function(HookEvent $event) { $inputfield = $event->object; // Only for a specific field if($inputfield->hasField != 'your_field_name') return; $options = $inputfield->options; // Get the existing options $inputfield->options = []; // Remove all the existing options // Add the options back with attributes foreach($options as $value => $label) { // Set whatever attributes you want as $key => $value in the last argument of addOption() $inputfield->addOption($value, $label, ['disabled' => 'disabled', 'data-foo' => 'bar', 'class' => $this->sanitizer->pageName($label, true)]); } $event->return = $inputfield; });

If it's working for your purposes then I think it's fine to do it the way you are. My suggestion is that you have the function return false by default rather than true, and reverse the logic in the conditionals. In general, when permissions are involved I'd say it's best practise that the default state be that the user can do nothing, and then you actively add permissions as needed. This post did get me thinking about if you could use the core permissions system for your needs. I found that when creating a new custom permission, if you prefix the permission name with "page-" then it gets some special features: namely that you can activate that permission for a role individually for each template. So that sounds promising for your needs, but I found that the downside is that the user must have the "page-edit" permission in order for the individual template activation to work. So that probably rules the option out because it's likely that you would want these permissions to be usable on roles that aren't allowed to edit pages. Maybe someone can shed some light on how "page-" prefixed permissions work. Are they mentioned anywhere in the docs or a blog post? Is there any other way to assign permissions on a per-template basis besides making them "page-" permissions? And do folks think it would be worth opening a request for per-template permissions that don't require the page-edit permission?

We do really need @since added to the documentation so module developers can know which methods will require which PW versions, and avoid to confusion when working on older sites. Maybe you could "thumbs up" the existing request and hopefully Ryan will act on it soon: https://github.com/processwire/processwire-requests/issues/158

No, I don't mind. Go right ahead.

How long have you been using this mouse for? Do you really prefer using those mouse buttons over keyboard buttons? I'm always looking for better efficiency and ergonomics, but I've always found the mouse to be the least ergonomic component of computers. I find I get mouse fatigue much faster than keyboard fatigue (the scroll-wheel in particular is a killer). Those 12 thumb buttons are interesting, but I would have thought that going from using all ten fingers/thumbs on a well-spaced keyboard to doing more work using a single thumb in a tiny space would be less comfortable and more prone to RSI. And for coding, isn't using the keyboard unavoidable? If the keyboard is unavoidable, wouldn't it be most efficient to do as much as possible with the keyboard and as little as possible with the mouse? Genuinely curious because I've never used a mouse like this before.

The PHP docs for the function say "yes".

In terms of adding markup to admin themes, the following hookable methods are common to all admin themes: AdminThemeFramework::getUserNavArray Allows you to add items to or remove items from the "user" dropdown menu (Edit Profile, etc). AdminTheme::getExtraMarkup Allows you to add markup to the following regions of the admin template: head notices body masthead content footer sidebar For example... $wire->addHookAfter('AdminTheme::getExtraMarkup', function(HookEvent $event) { $regions = $event->return; $regions['masthead'] .= '<p>hello</p>'; $event->return = $regions; }); So not every place in the admin theme markup is covered (I don't see how it could be), but it allows for simple additions to the admin theme. No doubt you would need some custom admin CSS to position and style whatever markup you add. Other approaches... Manipulate the rendered markup string For some cases this might do the job. For example... $wire->addHookAfter('Page::render', function(HookEvent $event) { $page = $event->object; if($page->template == 'admin') { $out = $event->return; $out = str_replace('<div class="uk-navbar-right">', '<div class="uk-navbar-right"><p>hello</p>', $out); $event->return = $out; } }); Copy your preferred admin theme module from /wire/modules/AdminTheme/ to /site/modules/ Make whatever changes you need to the copied files, perhaps by including a separate PHP file at the right place in the template markup. That will make it easier to update the admin theme module from the core version when you choose to.

To check if a given file exists, I think you would be better off using PHP's file_exists(). It's very fast and it caches so I doubt it would have any significant impact on performance.

Sure, please do.

I got tired of having to open the link dialog in CKEditor in order to check where a link is pointing to, so made this simple plugin. Link Hover A plugin for CKEditor. Shows the href attribute of a link in a tooltip when the link is hovered. This saves you from having to open the link dialog in order to check where a link points to. Installation This readme assumes installation in ProcessWire CMS. The plugin folder must be named "linkhover" – if necessary, rename the folder to remove the "-master" suffix added by GitHub. Copy the "linkhover" folder to /site/modules/InputfieldCKEditor/plugins/ In the field settings for each CKEditor field that you want to activate the plugin for, check the "linkhover" checkbox at Input > Plugins > Extra Plugins https://github.com/Toutouwai/linkhover

In this situation you aren't using WireUpload directly - rather Pageimages::add(). You can only give this method one image path at a time, but if you call it repeatedly in a loop it will keep uploading the images you give it until it is finished (or until PHP times out - you might want to increase max_execution_time if you have a lot of images to upload).

Besides Adrian's excellent suggestions... Many of the common inputfield properties are outlined here: https://processwire.com/api/ref/inputfield/ For properties specific to a particular inputfield type you can read the code comments in the core files, or if you have the very handy API Explorer pro module you can browse the properties in a nice interactive interface within the PW backend:

For a page $p with images field "images" and an array of image paths/URLs... $p->of(false); $u = new WireUpload('image_check'); foreach($image_paths as $image_path) { // Get path parts $parts = pathinfo($image_path); // Convert filename to PW format $image_name = $u->validateFilename($parts['basename']); // Look for filename in images field if(!$p->images->get($image_name)) { // Image does not already exist in field, so add it $p->images->add($image_path); } } $p->save();

This fieldtype wont be suitable for what you want. Instead, add a hidden textarea field to your templates, then in a saveReady hook loop over the template fields and add markup-free text (use strip_tags) to the textarea. You'll need an if/else structure to handle all the different field types you want to support.

Oh man, I want the best of both worlds - some of those pimped out Aussie 4WD campers are insane! Kiwis love their off-roading but I've never seen such amazing 4WDs until we went to the top end. Some folks have dropped some serious money on those. Proper go-anywhere Landcruisers with every conceivable mod-con built in. Love it.

Not at all. My partner and I had three weeks exploring NT's top end last winter and had nothing but good experiences. The Aussie grey nomad idea is genius - that's how I want to spend my retirement.

As a general rule, I find it preferable to avoid relying on parent-child structures and use Page Reference connections instead. I think it's more flexible and future-proof that way. So rather than nesting those things I would create separate branches for them and then connect Job Sites and and Specialities with Contractors using Page Reference fields (in conjunction with Connect Page Fields). I'd use Lister Pro instances to make it easy for editors to find whatever page they are looking for.

@adrian, thanks for the regex fix! Applied in v0.1.6. When I moved to the deep south I soon found out that a UPS is an essential piece of kit. And the irony is I'm only a short hop from the largest hydroelectric power station in NZ. Why, of course . If you're feeling at all homesick, check out the trailer for this documentary I heard about yesterday: A different kind of backwards...

@adrian, sorry for the interlude - there was a power cut here. Not sure if you saw the edit to my earlier post: if the widgets are correct when you close the dialog but incorrect when you reload the page then it's an issue with this regex. But it looks correct to me - the pattern should match any number of characters after an opening delimiter up until a closing delimiter. You probably know more about regex than me though - does the pattern look right to you?

I'm not aware of any way to do that. This module uses the widget component of CKEditor, and the dialog for that is defined once for all widgets in the CKEditor instance.

Hi @adrian, I regularly use multiple Hanna tags within a single field and haven't seen that issue before. It sounds like the closing delimiter of the first tag isn't being detected for some reason. I'm thinking that there must be some content in your tag that interferes with the detection of the closing delimiter. Does changing to a different Hanna tag delimiter fix it? To debug you could try logging the "name" data attribute here, which should be the hanna tag contents without the delimiters. Edit: actually, if it isn't matching the closing delimiter when the page reloads then it's probably related to the regex here. But it looks correct to me.

The changes/validation done by CKEditor happen via Javascript when the field is loaded in Page Edit. You won't be able to automate that with the API. But you could loop over the pages using the API and process the field using a PHP DOM parser (e.g. Simple HTML DOM), removing the <a>, adding the <p>, and converting <i> to <em>. Incidentally, I often need to work with pages that have scientific species names as their titles - the way I deal with it is through markdown formatting in the main title field rather than using a separate formatted field. And often it's easier for editors if you use a sort of "reverse" markdown, where you apply the markdown syntax around words that are not to be italicised, as those are fewer in number. Then you do the italic/normal styling with CSS.

There is an option in the ImportPagesCSV module for that: ImportPagesCSV can't do that for you, but after the data is imported you could loop over the pages and do the group assignment via the API. Or you could write your own API script for importing the CSV data and do the group assignment as you import. Below is a link to an action for @adrian's AdminActions module that will take a CSV file from a file field and loop over the rows.

@tpr, I noticed that the positioning of the button dropdown is a bit off for the Save button at the bottom of Page Edit (AOS feature "Show save dropdown on hover instead on click"). The one at the top is okay. Seems that both the Default and Uikit themes are affected. Top button (all good): Bottom button (position is off):

I'm interested too if this is possible, but I suspect it isn't. Because if getting data from another site was as simple as bootstrapping then I don't think there would be statements like this... ...or the stated benefit of PW3 multi-instance...