Robin S

I think we need something like UserVoice for PW feature requests, so Ryan and other core developers can gauge the level of support for individual requests and prioritise accordingly. It would actually be good to have the same for PW issues, so we can get an indication of which issues are particularly problematic to the largest number of users.

Related modules... PageEditPerUser - it's not explained in the module description but there is a option to allow access to descendant pages of a page where edit access has been given. AdminRestrictBranch Edit: just realised you are talking about the front-end and not back-end. Sorry, disregard.

In a current project I am using a Repeater field to build a kind of pseudo-table, where each Repeater item is a row. Some of the rows are headers, and some have buttons that toggle corresponding checkbox fields in a hidden FormBuilder form. The problem was that when the Repeater items were collapsed I couldn't see which rows were headers and which contained buttons. I tried including the fields in the Repeater labels but it still didn't provide enough visual difference to be quickly recognisable. So I investigated how classes could be added to selected Repeater items in admin depending on the value of fields within the Repeater items. This is what I ended up with... In /site/ready.php // Add classes to selected service row Repeater items $this->addHookAfter('InputfieldFieldset::render', function(HookEvent $event) { /* @var $fieldset InputfieldFieldset */ $fieldset = $event->object; $attr = $fieldset->wrapAttr(); // Fieldsets in a Repeater inputfield have a data-page attribute if(isset($attr['data-page'])) { // Get the Repeater item $p = $this->pages((int) $attr['data-page']); // Check field values and add classes accordingly // If item is a header if($p->row_type && $p->row_type->id == 2) { $fieldset->addClass('header-row'); } // If item has a checkbox button if($p->fb_field) { $fieldset->addClass('has-checkbox'); } } }); In admin-custom.css (via AdminCustomFiles) /* Special repeater rows */ .Inputfield_service_rows .header-row > label { background:#29a5aa !important; } .Inputfield_service_rows .has-checkbox > label .InputfieldRepeaterItemLabel:before { font-family:'FontAwesome'; color:#73cc31; content:"\f058"; display:inline-block; margin-right:6px; } Result

Not sure if it could cause the issue, but in your copyParent() function you could try find() instead of findMany() - no need for findMany() when you have a limit of 50. Also, the selector you posted looks a bit off: $tx = wire('pages')->findMany("template=transaction-earn, start=$start, limit=$limit, sort=transactiondate, [tagreference=$tag, merchantreference=$merchant]"); What is going on with the section in the square brackets at the end? Looks a bit like a subselector but you are not matching it against a field.

Hi @joshuag, unfortunately this update does not resolve the problem I am having with uninstallation. When I do the following steps... Remove the existing module files Add the updated module files Do a modules "Refresh" Clear compiled files ...I still get the PHP timeout when I try and uninstall, regardless of which sub-module I try and uninstall from. Sometimes timeouts like this are caused by a circular reference in the code. I'm wondering about the fact that each sub-module installs and uninstalls all the others. That seems non-standard to me: normally where there are multiple sub-modules there is one "main" module file that installs/uninstalls the others. The other modules only require the main module but do not install/uninstall them. See FieldtypeRepeater for example. Could there be some circularity where FieldtypeRecurme tries to uninstall ProcessRecurme, which tries to uninstall FieldtypeRecurme, which tries to... and so on?

There is the Page Reference with Date Field module that might be useful for this sort of thing. I've never used it and the module page doesn't indicate that it is compatible with PW3. But the real problem with using Page Reference fields for likes or any purpose that could potentially use thousands of pages is that there is no pagination or limiting possible when getting the field value. So it's not just a matter of dealing with the inputfield in Page Edit but also the impact on memory when getting the value via the API. There's an open request about this but no sign of activity.

@joshuag, you say in the email: I think it would be good if you do bump the version number each time you make a release even if it is for bug fixes. Otherwise it isn't clear from the PW modules listing whether that installation has been updated to the latest version, so it's harder to keep track if you have multiple sites running Recurme. Also, it will be easier for you in terms of support if you can ask what the installed version number is and know from that what release of Recurme the user has installed.

I'm not seeing any jumping problem with scrolling/dragging/swiping in Chrome on Windows or in Safari on iPad. But from an interface design point of view I think there is a bit of an issue in that there is nothing to indicate that there are multiple items in the work section and that the user should should scoll/drag/swipe to see more.

You can show the field when the countries field is empty using the core inputfield dependencies feature: countries.count=0 Or you could show it when the page is unpublished (which would apply when the page is first added) with the help of my Custom Inputfield Dependencies module.

To me the main distinction is between the bulk importing of data (for which modules like ImportPagesCSV are great) and the occasional addition or editing of data which you do via Page Edit. But in any case it's not difficult to do what you are asking about. Add a textarea field in your template named "country_import" or something. Then use a hook to Pages::saveReady() to process the field contents and add them to the "countries" Page Reference field. In /site/ready.php: $pages->addHookAfter('saveReady', function(HookEvent $event) { $page = $event->arguments(0); // Only for the appropriate template if($page->template == 'YOUR-TEMPLATE') { // If the import field is not empty if($page->country_import) { // Get the individual country titles in an array $country_titles = explode(', ', $page->textarea_1); // Find the country pages with those titles $country_pages = $this->pages->find([ 'template' => 'country', 'title' => $country_titles, ]); // Add the country pages to the countries field $page->countries->add($country_pages); // Empty the import field $page->country_import = ''; } } }); You could use the same principle for other fields if you think there's a major benefit to it.

A couple more links that may be useful:

Who is creating the pages? You (the developer), or a client? If you are creating the pages then I think it would be better to use the API or a bulk import module (ImportPagesCSV, BatchChildEditor) to bring this data in initially rather than spend time making something special in Page Edit. API $countries_string = 'Nigeria, Kenya, Australia, Russia, France'; // Maybe you would instead create an array of country strings to process multiple pages at once // 'Page One Title' => 'Nigeria, Kenya, Australia, Russia, France', // 'Page Two Title' => 'Russia, ...' // ... $country_titles = explode(', ', $countries_string); $country_pages = $pages->find([ 'template' => 'country', 'title' => $country_titles, ]); // Set $country_pages to the Page Reference field ImportPagesCSV Use a text editor to replace instances of ', ' with '|' in your countries string. Now the country titles are in a format that can be imported to a Page Reference field by ImportPagesCSV (see the module readme). You could import all the page content via the module, or just the countries field if you prefer (create a CSV that contains two columns - the page title and the pipe-separated string of country titles).

I don't think you can store objects in $session. See this comment from Ryan for instance: Storing an array (without objects) seems to work: $my_array = []; $my_array['animal'] = 'cat'; $my_array['colour'] = 'orange'; $session->my_array = $my_array;

To solve this you need to look at the code for each method you are considering hooking and ask yourself things like: What class is the method in? Does the method fire when I need it to? Does the method have an argument or return value that I need to use in my hook? So you are considering hooking ProcessLogin::afterLogin() or Session::loginSuccess(). When you look at afterLogin() you see: It is a method of ProcessLogin, a Process module that handles the PW login form. So it is only going to fire if a user logs in via the core PW login form. Maybe that isn't what you want if you are using a custom login form or logging in users via the API as part of some script. It depends on what you are doing. The method comments in the source code say it is only intended for when a superuser logs in, which could give you a clue if it is the best method to hook or not. It has no arguments that could be useful to quickly tell you things about the user who has logged in (although you could still get the $user object in other ways). So chances are Session::loginSuccess() is going to be a better option because it is a method of Session, so more closely connected to the current user session regardless of how they logged in. And it conveniently has the $user object as an argument so you can easily check properties of the user such as name, role, etc, in your hook.

This is deliberate and Ryan has talked about it but I don't have a link handy. Probably because there can be situations where a field contains a lot of data in which case the user should be notified of a problem but not have all their work thrown out. See this example from @Soma where he shows how you can set a field back to its previous value when you want to reject a submission:

Your module should be autoload in order to use that hook. See the autoload options for the getModuleInfo() method: https://processwire.com/api/ref/module/

Headings Case A plugin for CKEditor fields in ProcessWire CMS/CMF. Adds a toolbar button for changing the case of all headings or selected headings between sentence case and title case. This is useful when you are copy/pasting text from a document that has been supplied with an inconsistent or incorrect system of capitalisation. Installation The plugin folder must be named "headingscase" – if needed, rename the folder to remove the "-master" suffix added by GitHub. Copy the "headingscase" folder to /site/modules/InputfieldCKEditor/plugins/ In the field settings for each CKEditor field that you want to activate the plugin for: Check the "headingscase" checkbox at Input > Plugins > Extra Plugins Add "HeadingsCase" at Input > CKEditor Settings > CKEditor Toolbar Usage To change the case of all headings, click the toolbar button with no text selected in CKEditor. The first click applies sentence case; the second click applies title case. To change the case of a single heading, select all or part of the heading in CKEditor before clicking the toolbar button. There can be situations where the results need manual correction: proper names, acronyms, etc. Exceptions for small words Certain short English prepositions and conjunctions (three letters or less) are excluded from capitalisation when title case is applied. Edit the exceptions array in the plugin source code if you want to customise this list of exceptions. https://github.com/Toutouwai/headingscase

Great, pull request made.

In general, you should do this by putting your HTML structure into your template files. Only content should come from your fields. So this... ...should be in your template file, not in a textarea field. Once you've got the hang of "normal" template files you can explore field template files too - these are more of an optional extra than a must have.

Not tested thoroughly, but this should work, in /site/config.php: $config->paths->files = $config->paths->assets . 'example/'; $config->urls->files = $config->urls->assets . 'example/';

@ryan, could you please add an option to include setlocale() in the exported config.php if it is defined. Now that PW is giving warnings if setlocale() is missing it would be nice not to have to remember to manually add this each time a profile is installed.

I can't reproduce that. Maybe you have some odd unicode character in your text that is confusing SmartyPants? Or an unclosed open quote before the sentence in question?

No ideas about the cause of this issue sorry. This may not be as bad as it sounds. Export/import fields via core feature Export/import templates via core feature Export/import modules and module settings via Module Toolkit Copy PHP files: templates, config, ready, etc Here's where it gets a bit experimental: Export/import pages via new core feature. @horst has had some success with it.

Welcome @nasenfloete Maybe you can post the API code you are using the add the repeater items so others can see if they can reproduce the problem. I don't see why the role or permissions of the user should have any influence on adding repeater items to the user page via the API.

That's because "Manual drag-n-drop" is the default sort setting, i.e. choosing it is the same thing as leaving the setting empty. Manual drag-n-drop means the "Move" option in the page list actions: Whether this solves the order of your menu is another story though. You'd need to post the code you are using to generate your menu before people can help with that.