Robin S

Hi Adrian, The expand and collapse icons in the Dumps panel are not clickable. Probably a z-index issue.

It was fixed after 3.0.165 master was released: https://github.com/processwire/processwire-issues/issues/1247 You can upgrade to the latest dev release to get the fix.

This might work: foreach($users as $u) { $u->of(false); $u->save('user_payment'); }

Part of the process that happens when you set a Files or Images field value is the copying of the file to the page's folder in /site/assets/files/. The solution is not to set the Pageimage to the field. Just use some variable name like... $header_image = getHeaderImage($page); ...or if you want it stored on the Page object then invent some property name that isn't a field name, e.g. $page->the_header_image = getHeaderImage($page);

Below are the style overrides that I apply, mostly just spacing changes and fixes for things that looked off to me. There might be one or two things in there that don't make sense out of context because I'm also loading some custom JS to change the icon of the "user" menu and have the primary link be to the site frontend rather than the user profile. The problem is that if you create the minimal module that extends AdminThemeUikit (i.e. just the class declaration and the getModuleInfo method) then what you want to see is everything displaying as per AdminThemeUikit. Then you would add custom CSS/JS and override any AdminThemeUikit/AdminThemeFramework methods as needed. But what you actually see is this: If that is expected then it would be helpful to have some documentation or a blog post about how to go about extending AdminThemeUikit, or what file structure is needed for a full custom admin theme if anybody is game enough to try that. The only hookable methods that I can see are AdminThemeUikit:renderBreadcrumbs and AdminThemeFramework::getUserNavArray. So for the thing I mentioned (manipulating menus) you can only customise the "user" menu. It's not possible to dynamically add items to the Pages, Setup, Modules or Access menus without resorting to JS hacks like AdminOnSteroids does. And on the topic of the admin menus, the caching is a bit of a pain and doesn't measurably improve performance according to my tests: https://github.com/processwire/processwire-requests/issues/268#issuecomment-464200684 Another menu related request: https://github.com/processwire/processwire-requests/issues/189 What would be great is if for each major part of the admin theme layout (e.g. header, menus, top of content, bottom of content, footer) there was some hookable method so it was possible to inject custom markup at those points.

Depending on how much mixing of relative and absolute dates occur on a single page, it might be possible to avoid those scenarios by excluding specific processes and/or URL segments, e.g. if($page->process != 'ProcessPageEdit') { $wire->addHookBefore('WireDateTime::relativeTimeStr', function(HookEvent $event) { $timestamp = $event->arguments(0); // If given a date string, convert it to a timestamp if(!ctype_digit("$timestamp")) $timestamp = strtotime($timestamp); $event->replace = true; // Set your preferred date format below $event->return = date('Y-m-d H:i:s', $timestamp); }); }

A dedicated field for height is definitely the way to go, but just wanted to add that for the example titles you gave, the height follows the noun and if that applied consistently then potentially you could include the noun in the search text:

You can use a hook to replace all relative time strings in admin with a specific date format. Add the following to /site/templates/admin.php, at the top after the namespace declaration: $wire->addHookBefore('WireDateTime::relativeTimeStr', function(HookEvent $event) { $timestamp = $event->arguments(0); // If given a date string, convert it to a timestamp if(!ctype_digit("$timestamp")) $timestamp = strtotime($timestamp); $event->replace = true; // Set your preferred date format below $event->return = date('Y-m-d H:i:s', $timestamp); });

Recurring dates / calendar module A big +1 from me for this. A lot of sites need this kind of functionality. The key thing is solid RRULE support in a user-friendly interface. It's really common to have events that occur on a regular schedule (e.g. the first Tuesday of the month for now until eternity) but then occasionally have exceptions where the event is moved to a different day or cancelled for a particular date. The Recurme module had the right general idea but if you take a look at the source code you can see why it's not really scalable and needs a lot of tidying. A robust calendar module is not a simple thing so it would be great to have something that's built to the standard of Ryan's other Pro modules. Flexible content I find that Repeater Matrix is fine for when the content is divided into discrete conceptual and visual blocks on the frontend. It's pretty easy to make the mental connection between "conceptual/visual block on the frontend" and "Repeater Matrix item in the backend". Where it's not so good is when you have a long piece of text that is interspersed with different pieces of other content, e.g. text - image - text - graph - text - pullquote - text. In this scenario the editor/author wants to think of the text as one conceptual unit. Breaking the text across multiple Repeater Matrix items feels wrong, and it's difficult to locate and move paragraphs between the different blocks. For this scenario (which is pretty common now - think of Medium articles or other longform articles containing rich content) the Statamic Bard fieldtype looks like it nails the solution pretty well. The user wants to see a single flow of text with elements floating inside the text that represent the other pieces of content. These floating elements should reveal the content they contain (or at least the type of content) so that the user can understand what is what, but perhaps be edited outside of the text editing interface where that is more practical, e.g. click an element to edit it in a modal. I have actually made a couple of different experimental modules that expand Repeater Matrix in this direction but haven't found a fully satisfactory solution yet. Admin theme I'm pretty happy with AdminThemeUikit and don't think it looks dated. I've said before that there's too much padding between and around elements and the main page heading is way too huge (maybe this is where the "cartoonish" criticism comes from), but these things are very simple to fix with custom CSS overrides. I wouldn't want to see the admin styling change every year and I can't relate to the desire to be endlessly changing the admin to keep up with the latest fads. The admin is a place you go to do work, not to see pretty things. It should be plain and utilitarian, which AdminThemeUikit already is. Having said that, a couple of ideas that would make it easier for those who want to tweak the admin: 1. Maybe there could be more config fields in AdminThemeUikit to let people adjust things like spacing and font size without having to add their own stylesheet to the admin. 2. It would be pretty good if developers could more easily create modules that extend AdminThemeUikit so if they want a customised admin theme they only have to override certain specific methods rather than completely duplicating the module. Right now if you do... class AdminThemeFoo extends AdminThemeUikit ...the admin experience completely breaks so it's not currently a good foundation to build on. And it would be good if there were more hookable methods in AdminThemeUikit so that it becomes possible to manipulate the main menus for instance.

Hi Adrian, I spotted a minor layout bug with the new editor links in the Dumps panel:

Thanks, I did notice this when it was released and it looks like a nice module. It's only for single images though, and I'd still like to see image and file reference fieldtypes in the core. For some situations such fieldtypes are needed (e.g. avoiding duplication of images/files and associated data/descriptions when the asset is used on multiple pages, roles that may select files/images but not upload new files/images, scenarios where images/files need to be centrally managed, etc) and the fact that the core doesn't cater to this feels to me like a gap that should be filled.

Hear, hear! ? One place to find ready answers to this question is the requests repo: https://github.com/processwire/processwire-requests/issues That repo currently has 289 ideas for improvements, and it would be fantastic if you can find the time to do a quick first pass through the repo and add any comments or questions to the requests, and indicate which ideas you think are the most promising for developing this year. At the top of my wishlist is an Image Reference fieldtype: https://github.com/processwire/processwire-requests/issues/207 I'm imagining something that works much like a Page Reference fieldtype, with various options for defining which images are selectable and some elegant way of selecting from a large number of images (maybe a modal interface similar to Lister that lets you filter and select images for adding to the field).

Could you please add the steps you are following to reproduce the problem? I'm trying to reproduce it but am not able to. What I'm doing is: Template settings have slashUrls set to false (0). I upload an image to a "single" image field and save the page. I delete the uploaded image file from /site/assets/files/1234/ I check the filesize of the PageImage to confirm that PW can not locate the file. I call the size() method on the PageImage with the now missing file. I tried with both the GD and ImageMagick sizer engines. I check the slashUrls setting of the template. So far I don't experience any changes to the template settings of the page.

v0.3.0 released, which adds dropdowns to Edit Role, Edit Permission, Edit Language, and when viewing a log file at Setup > Logs. @flydev ??, this version should also fix the problem you reported above.

Awesome, thanks @ryan!! I'm just about to go away on holiday but looking forward to working with Combo when I get back. I think it would be cool to have a visualisation of the subfield placement in Edit Template, and when subfields are moved in the visualisation it populates that custom placement field in template context behind the scenes. But that's just an icing on the cake thing, and maybe a better fit for a third-party module. Thanks again for Combo - it's a pretty revolutionary addition to the PW toolbox I reckon. ?

A quick proof-of-concept using the API only... Before (Combo subfields grouped together inside fieldset): After (Combo subfields interspersed with other fields): Hooks: // Reposition Combo subfield inputfields in Page Edit $wire->addHookAfter('ProcessPageEdit::buildFormContent', function(HookEvent $event) { /** @var InputfieldWrapper $wrapper */ $wrapper = $event->return; // Imagine this is sort order data coming from some config field $insert_after = [ 'test_combo_colours' => 'image', 'test_combo_description' => 'file', 'test_combo_decimal' => 'test_repeater', ]; // Get the Combo subfield inputfields $combo = $wrapper->getChildByName('test_combo'); $combo_inputs = $combo->getInputfields(); // Reposition them foreach($insert_after as $combo_subfield_name => $normal_field_name) { $combo_subfield = $combo_inputs->getChildByName($combo_subfield_name); $normal_field = $wrapper->getChildByName($normal_field_name); $wrapper->insertAfter($combo_subfield, $normal_field); } // Cannot just remove the Combo inputfield or else subfield value changes don't get processed // So instead a separate hook is used to replace the rendered output of the Combo inputfield // $wrapper->remove($combo); $event->return = $wrapper; }); // Don't render anything for the Combo inputfield $wire->addHookBefore('InputfieldCombo::render', function(HookEvent $event) { /** @var InputfieldCombo $inputfield */ $inputfield = $event->object; $field = $inputfield->hasField; if($field->name === 'test_combo') { $inputfield->wrapAttr('style', 'display:none'); $event->replace = true; }; });

It rearranges them using JS. I can't remember now but presumably I struck a problem trying to reorder the inputfields using the API before the form renders, because that would be better for sure. I'll PM you the module so you can take a closer look.

I hadn't imagined adding the subfields of a Textareas or Combo field individually. I figured if you add the field then you get all the subfields rather than picking and choosing. Or I might be misunderstanding you. It's just the flexibility of the sort order I'm interested in - some sort of interface that defines the Page Edit form, where I can see the individual subfields and can sort them amongst other inputfields. I think having two AsmSelects would probably be the simplest thing. One that adds/removes fields from the template, but isn't sortable (it doesn't need to be because a field is either in a template or not and doesn't really have a sort position as I understand it). And one that defines the sort order, width, visibility, etc, of inputfields in Page Edit, but doesn't allow inputfields to be added or removed (it would get too confusing - better to allow that to be defined by the fields that belong to the template, and you can always set visibility to hidden to "remove" a particular inputfield if necessary).

@ryan, a few things to clarify and add to my earlier post... My dream/request for ProFields Textareas and ProFields Combo is really about the Page Edit interface. It's only about the modules in that they render multiple inputfields in Page Edit and I'd love to have extra flexibility to arrange those inputfields. The fieldtypes work brilliantly just as they are. To me, the attractiveness of Textareas and Combo is that they reduce the number of fields that are required for some projects. The only time this matters to me is on large sites that have hundreds of fields (or rather would run into the several hundreds if I don't take measures to be efficient with fields). And although I always plan for efficiency and haven't yet run into performance issues due to excessive fields or templates, there are topics in the forum that indicate it can be problem: A typical project scenario for me is... Client describes what they want - often it's a catalogue-type site for scientific data. I can see it's going to involve a ton of fields (or might in the future), so I start planning how I am going to handle them efficiently. Often a lot of the fields in a template will have identical requirements - they're just simple text/textarea/CKEditor fields without any special settings needed. I look at Textareas and read in the description: Sounds perfect! But when I get into the nitty gritty of the project it turns out that all these similar fields need to be interspersed with image, file, table, repeater fields. Or worse, I see a bunch of fields that are all adjacent and related so a great candidate for Textareas but some time down the line the client wants to stick an image field in the middle of them. Now I have a problem and have to scrap the Textareas field and break it up into multiple fields. I can see the same situation arising when I start using Combo (which seems like it can do everything Textareas does and then some, which is awesome). The way I see it, the beauty of Textareas and Combo fields is all about the reduction of fields needed for a project. Their appeal to me is not about grouping fields into a smaller set beyond the bigger grouping of "all these fields belong to this template" and I've never needed to add a Textareas field to more than one template. The loading of the field data and the field.subfield API syntax doesn't matter to me one way or the other - it's not a benefit or a problem. But the fieldset grouping in Page Edit is a limitation rather than a feature because it often means having to rule out Textareas/Combo from scenarios where otherwise they could avoid a lot of field overhead. Right now we have a "Fields" inputfield in Edit Template that is doing two duties: 1. It allows fields to be added and removed from the template/fieldgroup. 2. It determines the order and layout of inputfields that are rendered in the Page Edit form. These two things are related to an extent but in some ways they are quite different. Bundling them into one interface has worked fine for almost all the fieldtype modules in PW, but when I think about special fieldtypes like Textareas and Combo that can render multiple inputfields it seems like this interface holds them back from going to another level of usefulness. I don't know what the perfect way to handle it is, but one idea is to separate 1 and 2. So there would be a "Fields" inputfield that simply determines which fields belong to the template. And there would be a "Page Edit layout" inputfield that is all about the layout of inputfields in Page Edit, not concerning itself with which field each inputfield corresponds to. In most cases adding a field to "Fields" adds one inputfield to "Page Edit layout". But for some special fieldtypes (Textareas, Combo, maybe FieldsetGroup, maybe some third-party fieldtype modules in the future) these modules add multiple inputfields to "Page Edit layout" that can be sorted individually. And when the Page Edit form renders it loops over the data from "Page Edit layout" and renders those inputfields accordingly. As far as I know this wouldn't require any changes to how the Page Edit form submission is processed. In my hacky module I am moving inputfields all around the Page Edit interface and it doesn't affect anything else in PW. I know this wouldn't be a simple change but for big sites I think it could allow Textareas and Combo to cater to more scenarios, be more accommodating to changing project requirements, and thereby save a lot of field overhead.

Also, I want to open the page in Page Edit after it is cloned. Here is a hook for that: // Edit the cloned page after it is created $wire->addHookBefore('ProcessPageClone::execute', function(HookEvent $event) { $event->wire()->addHookBefore('Session::redirect', function(HookEvent $event) { $url = $event->arguments(0); $id = (int) filter_var($url, FILTER_SANITIZE_NUMBER_INT); $redirect_url = $event->wire()->config->urls->admin . 'page/edit/?id=' . $id; $event->arguments(0, $redirect_url); }); });

If you have the core ProcessPageClone module installed you can copy a page via Page List: But sometimes I don't want to hunt around through Page List to find the page I want to copy, and instead I have found the page via the admin search and have it open in Page Edit. So I used this hook in /site/ready.php to add a "Clone this page" button to the bottom of the Settings tab. // Add a clone button to the Settings tab of Page Edit if this page is allowed to be cloned $wire->addHookAfter('ProcessPageEdit::buildFormSettings', function(HookEvent $event) { $wrapper = $event->return; $modules = $event->wire()->modules; $page = $event->process->getPage(); /** @var ProcessPageClone $ppc */ $ppc = $modules->get('ProcessPageClone'); if($page && $ppc->hasPermission($page)) { /** @var InputfieldButton $f */ $f = $modules->get('InputfieldButton'); $f->value = 'Clone this page'; $f->href = $event->wire()->config->urls->admin . 'page/clone/?id=' . $page->id; $wrapper->add($f); } }); Maybe somebody else has this need and finds this useful.

Thanks for this great new module @ryan! The Combo module seems in some ways like an enhanced ProFields Textareas: both modules provide multiple inputfields that look just like real separate fields in Page Edit but are contained in a fieldset and are actually just one field behind the scenes. As you've said, this is great for efficiency because it reduces the total number of fields needed for a project. In some big sites I've worked on the ProFields Textareas module has been fantastic because it's reduced the number of fields I need by 50% or more. The new Combo field looks like it will be even better than Textareas so I'm excited to start using it. But there is something that holds Textareas and Combo back from being even more useful, and that is the fact that all the subfields have to be rendered together inside a fieldset. In my experience there are many situations when you have fields in template that technically could be catered to by Textareas (and now Combo) but the problem is the layout in Page Edit: 1. The subfields of the Textareas/Combo are not sufficiently related to each other that they should be grouped together inside a labelled fieldset. What I mean is that as a developer you identify fields whose technical requirements make them a good fit for Textareas/Combo, but the fields don't conceptually belong in the same group in the mind of the client/administrator, so you don't want them all grouped together under one parent fieldset label. 2. You have some other separate fields (e.g. Repeater, ProFields Table) that you want to intersperse between the Textareas/Combo subfields. The consequence of these two problems is that it either isn't practical to use Textareas/Combo in some situations where it has the potential to avoid a lot of extra fields, or you end up creating many more separate Textarea/Combo fields than are necessary or desirable from a technical point of view. You might remember that I raised this in the Textareas forum, and ended up making a hacky module that rearranged the Textareas subfield inputfields in Page Edit so I could get around the two issues described above. But what I'm dreaming of is having a core or official ProFields solution to this... What I'm imagining is an enhanced version of the core template editor. If a field is added to a template and the fieldtype reports that it renders multiple subfield inputfields (Textareas and Combo are the only fieldtypes I can think of that do this, but perhaps more fieldtypes will fit the bill in the future) then those subfields become individually sortable in the template editor. So it would be possible to make a layout in Page Edit that went something like... title combo.text repeater combo.textarea table combo.integer etc Here's a screenshot of the interface of my hacky module to show the general idea - although this is actually separate from the template editor and is therefore not nearly as good as it could be. (And before anyone asks, this module is way too buggy and hacky for me to release publicly, hence my request for a solution from Ryan). I know this wouldn't be a simple thing to implement but I think it would make ProFields Combo and ProFields Textareas hugely more useful. Thanks for considering!

Access > Users is already supported as a variation of Page Edit. For the other ones you mentioned if they were to be supported I'd want to do that as some generic method that uses the flyout menu JSON. I'll take a look at that in the new year.

v0.2.0 released, which is a fairly major refactoring of the module with some new features. There are now dropdowns in ProcessTemplate and ProcessField that allow you to quickly jump from editing one template/field to another. There are config options to disable these new dropdowns if you don't want them for some reason, and options to exclude system templates/fields from the dropdowns. The update is available directly from GitHub but unfortunately I am locked out from editing this module in the directory (I've emailed @ryan about it) so v0.2.0 won't show up there until the next automatic update runs.

This module is just the inputfield and doesn't get involved with what the user might want to do with the field contents. But I take your point that some users might not know how to convert Markdown to HTML, so thanks for raising it. Using the textformatter you suggested is one way to get HTML from Markdown, or alternatively you could use $sanitizer->entitiesMarkdown() on the field value. I've added a paragraph to the readme. For me personally, the current application is for getting HTML out of custom fields for File/Image fields because CKEditor isn't supported there. Although I emailed Ryan today with some suggested fixes for getting CKEditor working there so hopefully that might change soon. More broadly I think some people just prefer working with Markdown rather than a full-blown WYSIWYG, so this is an inputfield for them. ? I don't think EasyMDE has options for loading custom CSS - the previewClass option is just if you want to specify a different class name than the default on the preview wrapper element. If you want to target the preview element with custom CSS in Page Edit you could write style rules like this: .InputfieldEasyMDE .editor-preview h1 { color:red; } And load your custom CSS file with AdminOnSteroids or with a hook like this: $wire->addHookBefore('ProcessPageEdit::execute', function(HookEvent $event) { $config = $event->wire()->config; $config->styles->add($config->urls->templates . 'custom-styles.css'); });