Robin S

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}; }

Thanks @adrian, I'll have a think about those things. I realise now that I have made a lot of changes myself to FieldtypeMapMarker for different projects - every time I use it I find something that doesn't really suit me or work too well. Maybe I should go through all of that and consolidate it into my own fork. Then we could possibly look at where it makes sense to combine our forks together.

Thanks for this fork - a very useful enhancement. If you think you might submit a pull request I saw a few things that could be good to include. 1. The default address setting in the field config doesn't work in this fork. Maybe it needs separate fields for street, city, etc? 2. Perhaps you could integrate this fix for ajax-loaded inputfields: https://github.com/ryancramerdesign/FieldtypeMapMarker/issues/19 3. Because the inputfield places the text inputs inside paragraph tags, there is an excessive amount of vertical space between rows of inputs (in the default admin theme at least - I didn't check the others). Solutions could be to change from <p> to <div> wrappers, or to add a rule to InputfieldMapMarker.css to reduce the margin on paragraphs. Edit... 4. Would it be possible to avoid the trailing commas in the Address field if some of the components aren't filled out?

If it's not working then the GET variable "id" must not be present in the URL of the form page. How are you adding this GET variable when you prevent access to the protected page and redirect to the login form? Typically there are two ways you would add the variable: 1. Using the "Redirect to another URL" option in the Access tab of the template. 2. Using your own logic in the template files of protected pages, e.g. if(!$user->isLoggedin()) echo "<p>Please <a href='/login/?id=$page->id'>log in</a> to access this page.</p>";

I don't think you need a full webshop system such as Padloper or Snipcart for 4 products. Make it easy on yourself and use PayPal buttons - your work will be finished in 30 minutes.

You can use width in a find() selector with Pageimages, e.g... $wide_images = $images->find("width>1000");

@adrian, I just pushed another update in v0.1.5 that will allow the dropdown label in the toolbar to adapt its width to the length of the text (in the case that it is translated).

You would need to install the LanguageSupport module but I don't think there's any inefficiency in doing that. You don't need to actually create any additional languages - you just edit the default language to override whatever strings you want. I believe that's the standard PW way for customising strings so I wouldn't want to reinvent the wheel and create configurable fields for every string.

Great. I have applied your suggested change in the latest version.