Robin S

I actually ended up writing my own backup script because I wanted the backup to run by cron job at a fixed time rather than have the unpredictability inherent in LazyCron. But in terms of this module my vote would go for having CronjobDatabaseBackup identify the backups that it creates either by filename prefix or something distinctive in the Description as per @horst's suggestion. Then the backups can be safely stored in /site/assets/backups/database/ where they can be viewed and restored via ProcessDatabaseBackups and there is no requirement to use a "file protection string" to protect backups not created by CronjobDatabaseBackup.

FYI, the core has built-in support for relative time strings: https://processwire.com/api/ref/wire-date-time/relative-time-str/

Just what is shown in the Implementation field: echo $page->comments->renderAll(); I suggest testing a Comments field on a clean installation of PW so you can determine that it does indeed work and then you can focus in on what might be different on your other site.

@kixe, I feel that the settings "Maximum number of backups" and "Remove backups older than" should only apply to backups created by CronjobDatabaseBackup. If the user has made manual backups, or backups have been made by a different module, then CronjobDatabaseBackup should never delete those backups. What do you think?

I think custom database tables and SQL queries would be the way to go. This is a good read on working with hierarchies in MySQL: http://mikehillyer.com/articles/managing-hierarchical-data-in-mysql/

You are posting in the support thread for the third-party Image Extra module. This is already reported in the GitHub issues repo: https://github.com/processwire/processwire-issues/issues/1070

To reproduce, put an input element in your template that is not within a form. <input type="text" value="someone@domain.com"> It's valid to use inputs, textareas, etc outside of a form element.

Thanks for the reminder - I just tried this for the first time and it works well. I still think it would be a nice feature to add to Duplicator because it's more efficient time-wise to download all the images you need in one hit while you have a coffee rather than page by page as you edit. Plus I reckon people will find other use cases for selectively including page files in a backup.

Big, big thanks @adrian for all your ongoing work on Tracy Debugger - it just gets better and better!

Hi @flydev ??, A feature request... It would be awesome if there was a feature to enter a selector string that determined the pages whose files will be included in the backup. So that if the selector string was "template=basic-page" then in the backup the only directories inside /site/assets/files/ would be those belonging to a basic-page. My use case is that I sometimes need to copy a site to my local machine to do some work, but that work only involves one part of the site. My connection speed is not great where I live (particularly upload speed) so it would be a big help if I only needed to download/upload the related files and not all the site files. Thanks for considering. ?

If you don't need to do anything with the existing page then you can avoid loading it: if($pages->count($selector)) continue;

Yes, it's the styling CKEditor applies to all dropdowns - the Format and Style dropdowns are the same. I don't want to override the CKEditor defaults because the desired width for the dropdown will probably vary from person to person, but Adrian's solution is a good one. If you want to style the items (font size, etc) within any of the CKEditor dropdowns you can add custom CSS to /site/modules/InputfieldCKEditor/contents.css. For example, I don't like the "preview" styling added to items in the Format and Styles dropdown so I have this custom CSS: .cke_panel_list .cke_panel_listItem a * { font-family:sans-serif, Arial, Verdana, "Trebuchet MS"; color:#333; font-weight:normal; font-style:normal; text-transform:none; letter-spacing:0; font-size:14px; padding:0; margin:0; }

@Roope, a feature request: it would be great if it was possible to avoid the email replacement within elements that are given a particular HTML class, e.g. "no-emo". My current issue is that if I show an email address as the value of a text input or textarea then EMO replaces those strings, which create invalid markup. Probably EMO shouldn't touch emails that are the values of form elements, but it would also be handy to be able to disable EMO inside other elements so I thought I'd request that class option.

I think you should open an issue for this at GitHub. In WireShutdown the combination of... // use text-only output if an http request that is ajax if($useHTML && $config->ajax) $useHTML = false; ...and... } else if(!$useHTML) { $why = $this->labels['cli-mode']; } ...means that every AJAX request is wrongly treated as being CLI mode.

It works out of the box for me. Are you including the CSS and JS as per the implementation notes?

I was surprised to discover recently that a datetime inputfield using the jQuery UI datepicker will accept any old nonsense that an editor might put into it, allowing the page to be saved and often converting the input into strange unwanted values without warning. More info: https://github.com/processwire/processwire-issues/issues/1138 I think the core should be validating the input, but in the meantime here is some code that will check the input against the configured format (date only - I haven't tried time settings) and alert the user if the value is invalid. In the case of invalid input the previous value is restored. In /site/ready.php: // Datetime fields: load Vex to use for invalid date alerts $wire->addHookAfter("InputfieldDatetime::renderReadyHook", function(HookEvent $event) { $this->wire('modules')->get('JqueryUI')->use('vex'); }); In custom admin JS (loaded however you like - I use AdminOnSteroids) // Validate datetime inputfields $(document).on('focus', '.InputfieldDatetime input', function() { $(this).data('prev-value', $(this).val()); }); $(document).on('blur', '.InputfieldDatetime input', function() { var format = $(this).data('dateformat'); try { $.datepicker.parseDate(format, $(this).val()); } catch(e) { $(this).val($(this).data('prev-value')); var example_date = $.datepicker.formatDate(format, new Date('23 Oct 2014')); vex.dialog.alert('The date you entered is not in the valid format. Example of format: ' + example_date); } }); Result:

It works fine here: pageQueryJson() is not a core method. If that method is the cause of your issue best to ask in the module's support thread.

Thanks! I just had to start a User Switcher session and then the logout button did the trick.

Hi @adrian, Is it possible to switch into a user with the guest role only using the User Switcher panel? I didn't see the default guest user available there so I created a new user with only the guest role but it doesn't appear either. Or do you know of another way to get the debug bar to appear on a remote site when not logged in? (of course you would never to this on a live site - my site isn't publicly accessible)

What version did you update from? I think it hasn't been possible to set access controls on fieldsets for some time, maybe years. I think there might be a couple of reasons for why you can't set access controls on fieldsets: 1. Edit access (in Page Edit) for a fieldset is meaningless because a fieldset doesn't store any user-editable data. 2. Generally speaking fields do not "know" that they belong to a fieldset. You can run your own logic like this... ...but there is no simple property of a field A that indicates that it is within fieldset B. So setting view/edit access on a fieldset doesn't actually set view/edit access for fields within that fieldset. Back when it was possible to set access controls on a fieldset it might have appeared that there was access control in that maybe the inputfields didn't get rendered, but I doubt that this was proper access control/security on the fields within the fieldset. So my guess is that Ryan removed that option so devs wouldn't get the wrong impression that they are setting access control on fields by setting it on a parent fieldset. So I think your options are... 1. Set access control on the fields within your fieldset. 2. So long as you know and are comfortable with the fact that it isn't proper access control, you could remove the fieldset using a hook: $wire->addHookAfter('ProcessPageEdit::buildFormContent', function (HookEvent $event) { /* @var InputfieldWrapper $wrapper */ $wrapper = $event->return; // Do some test based on roles if($event->wire('user')->hasRole('some_role')) { // Remove fieldset $fs = $wrapper->getChildByName('your_fieldset_name'); $wrapper->remove($fs); } });

v0.1.1 released with support for Repeaters and comma as decimal separator. Thanks @David Karich!

Thanks, will discuss with you over on the PR.

Do you know if there's a way to query some Shopify API to get all the IDs and titles of products that exist in the Shopify store? So that a client only needs to maintain products in Shopify but the PW site could run a cron job where every day it gets all the product IDs and titles and automatically creates pages for them?

This markup actually belongs to InputfieldWrapper rather than individual inputfield renders. There is the InputfieldWrapper::setMarkup method that you can use to customise the markup that is rendered by InputfieldWrapper. See the defaultMarkup property as a starting point for what can be customised: /** * Markup used during the render() method - customize with InputfieldWrapper::setMarkup($array) * */ static protected $defaultMarkup = array( 'list' => "<ul {attrs}>{out}</ul>", 'item' => "<li {attrs}>{out}</li>", 'item_label' => "<label class='InputfieldHeader ui-widget-header{class}' for='{for}'>{out}</label>", 'item_label_hidden' => "<label class='InputfieldHeader InputfieldHeaderHidden ui-widget-header{class}'><span>{out}</span></label>", 'item_content' => "<div class='InputfieldContent ui-widget-content{class}'>{out}</div>", 'item_error' => "<p class='InputfieldError ui-state-error'><i class='fa fa-fw fa-flash'></i><span>{out}</span></p>", 'item_description' => "<p class='description'>{out}</p>", 'item_head' => "<h2>{out}</h2>", 'item_notes' => "<p class='notes'>{out}</p>", 'item_detail' => "<p class='detail'>{out}</p>", 'item_icon' => "<i class='fa fa-fw fa-{name}'></i> ", 'item_toggle' => "<i class='toggle-icon fa fa-fw fa-angle-down' data-to='fa-angle-down fa-angle-right'></i>", // ALSO: // InputfieldAnything => array( any of the properties above to override on a per-Inputifeld basis) ); But this applies to the whole InputfieldWrapper. In terms of making it more targeted you can set markup for individual inputfield types by using the inputfield class name as a key: $wrapper->setMarkup([ 'InputfieldText' => [ 'item' => '<li {attrs}><p>Markup before</p>{out}<p>Markup after</p></li>', ], ]); But you can't target individual inputfields by name or something like that. LoginRegisterPro has a similar setMarkup() method but has the added feature of letting you use "name=some_inputfield_name" as a key: https://processwire.com/store/login-register-pro/docs/#customizing-markup-and-or-class-attributes-html It would be cool if a feature like that was added to the core InputfieldWrapper::setMarkup method.

I can see why it's awkward for your use case, but the getMarkup() and getText() methods are working as per their documentation as I understand it. The argument can be one of two things: "field name" or "markup string with field {name} tags in it". The method has to distinguish between those two possibilities and it does that by looking for the presence of "{" and "}" - if those characters are not found it treats the string as a field name. Basically you're requesting a new feature which is a third possible argument to these methods, namely a string that isn't a field name and doesn't have {name} tags in it. I'm sure Ryan would consider that if you raise it in the requests repo, but given how many existing requests there are you'll probably want to come up with a workaround in the meantime. You could do this... echo $page->getMarkup($modules->get('MyModule')->MyTextFormatSetting) ?: $modules->get('MyModule')->MyTextFormatSetting; echo $page->getText($modules->get('MyModule')->MyTextFormatSetting) ?: $modules->get('MyModule')->MyTextFormatSetting; ...or in the case of getMarkup() the method is hookable so you could do this... $wire->addHookAfter("Page::getMarkup", function(HookEvent $event) { $key = $event->arguments(0); if(!$event->return) $event->return = $key; });