Robin S

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.

Hi @adrian, I just pushed an update that makes those strings translatable within the module file. As for the other issue, if your tag name is long it can overflow the standard width that CKEditor applies to combo panels (I don't set any explicit width in this module). I could make a config field for panel width but I'd rather not because I think the default width is suitable in most cases and to get a dynamic value from PHP it would mean putting the CSS inline which is kinda ugly. Maybe you could just set your own width for the panel in some custom admin CSS? .cke_combopanel__hannadropdown { width:300px !important; }

@adrian, I think that should be fine, but could you first make the change on your local installation? If it seems to work okay let me know and I'll update the module.

This post outlines two strategies for grouping pages under headings according to category:

Two modules that could help with this... Fieldtype Dropdown Dynamic: probably the easier alternative if you only need to select a single option. Fieldtype Select External Option: the alternative to go for if you need to select multiple options.

A page ID of zero means a NullPage - that's not a valid page you can redirect to if login is successful. When setting the value of $requested_id you should set a fallback value (e.g. "1", the home page) if no id is present as a GET variable. Something like: $requested_id = (int) $input->get->id ?: 1;

The searchable AsmSelect feature is cool! Just wanted to add: ajax-loaded inputfields (via inputfield visibility setting or repeater item setting) trigger a "reloaded" event on the inputfield to signal when the field is loaded. So you could use this instead of the requestAnimationFrame trick if you want. See InputfieldAsmSelect.js for an example of how this event can be used. $(document).on('reloaded', '.InputfieldAsmSelect, .InputfieldPage', function() { console.log('The AsmSelect inputfield was ajax-loaded'); });

Thanks, will do.

Hi @teppo, Just wondering about updating to the v2 branch on a project I have under development. In the quote above, do you mean that the range of fieldtypes supported on the v2 branch is currently narrower than the v1 branch (only text and file/image fields)? Or do you expect that all the fieldtypes supported in v1 (integer, datetime, etc) will also work in v2 branch but just that you haven't tested them yet? If it's the latter I will probably go ahead and upgrade (unless you think that wouldn't be wise to do yet).

Check to make sure you don't have HTML Entity Encoder selected as a text formatter for the field. I just tried installing the Codemirror plugin for CKEditor and it's working as expected here (although I did need to select a light-coloured theme because the extra specificity coming from editor.css forced the text to black).