Robin S

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...

If it were me I would be hesitant to do any significant development on a live website. Better I think to copy the site locally or to a separate testing account. But I think it should be possible to achieve what you want. As I understand it you have two objectives: 1. Prevent certain pages appearing a menu generated by MarkupSimpleNavigation. 2. Prevent certain pages from being viewed. For MSN you can conditionally set the selector according to whether the dev site is being viewed. Not sure what test you are using for that, but for MSN you would do something like this: $selector = ''; // Whatever your default selector is for the menu // Set $is_dev according to your test if(!$is_dev) $selector .= ", !showPageIn.title='Dev'"; // Now use $selector in your MSN options array Then to prevent viewing of dev pages (in case a visitor stumbled upon the URL of a dev page), in /site/ready.php: $wire->addHookBefore('Page::render', function(HookEvent $event) { $page = $event->object; // Set $is_dev according to your test if(!$is_dev && $page->showPageIn->has("title=Dev")) throw new Wire404Exception(); });

Yes I have tried it out... just now . Works great, thanks.

Yes, that's fair enough. I don't give anyone but myself access to Tracy, but need it sometimes when testing from non-superuser roles on a live server. But not all that regularly, and it doesn't take long to create the permission manually.

Hi @adrian, just wondering if Tracy should create the "tracy-debugger" permission on install to save the user creating it manually?

Alternatively, you already get the root page as an object in the first line of your code, so you can compare $child to $root and exclude it that way. $root = $pages->get("/"); $children = $root->children(); $children->prepend($root); foreach($children as $child) { // DoSomething1 ... if ($child->numChildren(true) && $child !== $root) { // DoSomething2 ... } }

Another community member helpfully pointed out that I entered the same link twice. I have fixed that now - the other link was supposed to be for a subsequent blog post that expanded on the field rendering feature: https://processwire.com/blog/posts/processwire-3.0.7-expands-field-rendering-page-path-history-and-more/#field-rendering-with-template-files

In your Hanna code, the page that your Hanna tag exists on is accessible as $page. So if your CSV file is in a "single" file field named "csv_file" then you could get the file like this... $csv_file = $page->csv_file; if($csv_file) { // A file exists in the field, so make your table by parsing $csv_file }

It is possible to output fields in your template file so that you can change the field order in your template and see the change reflected on the front-end. You would loop over the template fields and then output the markup relevant to that field. You could do this with a long if/else structure to check the name and/or type of the field... foreach($page->template->fields as $field) { if($field->name === 'title') { echo "<h1>$page->{$field->name}</h1>"; } elseif($field->name === 'images') { // ...etc } } But it would be tidier to set up render files for each field (see here and here) and then output the markup with... foreach($page->template->fields as $field) { echo $page->render->{$field->name}; }