Leaderboard

Hello @ryan and @Francesco Schwarz, There are currently a lot of issues (about 20% of the total) that are still open on the processwire-issues repository but marked as "Resolution: fixed (close when ready)." Some of these date back over a year. I doubt many of the older ones will ever be closed by the initiator. There is a similar situation building up with the issues tagged as "Resolution: Not a bug" - though there are less of them. If that's the case, how about closing any issues that are 3+ months old (or that have not been tagged as a discussion) with a polite note that the issue should be re-opened if needed? This would really help reduce the list of open issues.

I've added this tweak AOS (asmCounter): https://processwire.com/talk/topic/13389-adminonsteroids/?do=findComment&comment=170536

@matjazp Thanks, I've fixed that (came to the same solution without reading yours first :)) In v1.9.9 there is a tweak to add counters to asmSelects (for Page Reference and Options fields):

A pet hate of mine is when an editor uses a paragraph of bold text for what ought to be a heading. When I need to tidy up poorly formatted content like this I will quickly change such lines of text into the heading of the appropriate level, but that still results in markup like... <h2><strong>Some heading text</strong></h2> The <strong> has no business being there, but it's a bit of a hassle to remove it because you have to drag a selection around the exact text as opposed to just placing your cursor within the line. That gets tedious if you have a lot content to process. I figured there has to be an easier way so started looking into the ACF (Advanced Content Filter) features of CKEditor. What I wanted is a rule that says "strong tags are disallowed specifically when they are within a heading tag". (I guess there could occasionally be a use case where it would be reasonable to have a strong tag within a heading tag, but it's so rare that I'm not bothered about it). With the typical string format for allowedContent and disallowedContent there is no ability to disallow a specific tag only when it is within another specific tag - a tag is allowed everywhere or not at all. But I found there is an alternative object format for these rules that supports a callback function in the "match" property. So I was able to achieve my goal with the following in /site/modules/InputfieldCKEditor/config.js: CKEDITOR.editorConfig = function(config) { config.disallowedContent = { // Rule for the <strong> element strong: { // Use "match" callback to determine if the element should be disallowed or not match: function(element) { // Heading tag names var headings = ['h1', 'h2', 'h3', 'h4', 'h5', 'h6']; // The parent of the element (if any) var parent = element.parent; if(typeof parent !== 'undefined') { // If there is a parent, return true if its name is in the heading names array return headings.indexOf(parent.name.toLowerCase()) !== -1; } else { // There is no parent so the element is allowed return false; } } } } }; Another tip: if you want to debug your allowedContent or disallowedContent rules to make sure they are being parsed and applied successfully you can log the filter rules to the console. For convenience I used /site/modules/InputfieldCKEditor/config.js again. // Get the CKEditor instance you want to debug var editor = CKEDITOR.instances.Inputfield_body; editor.on('instanceReady', function() { // Log the disallowed content rules console.log(editor.filter.disallowedContent); });

Breadcrumb Dropdowns Adds dropdown menus of page edit links to the breadcrumbs in Page Edit. The module also adds dropdowns in Edit Template, Edit Field, Edit User, Edit Role, Edit Permission, Edit Language, and when viewing a log file at Setup > Logs. Configuration options Features/details The module adds an additional breadcrumb item at the end for the currently edited page. That's because I think it's more intuitive for the dropdown under each breadcrumb item to show the item's sibling pages rather than the item's child pages. In the dropdown menus the current page and the current page's parents are highlighted in a crimson colour to make it easier to quickly locate them in case you want to edit the next or previous sibling page. Unpublished and hidden pages are indicated in the dropdowns with similar styling to that used in Page List. If the option to include uneditable pages is selected then those pages are indicated by italics with a reduced text opacity and the "not-allowed" cursor is shown on hover. There is a limit of 25 pages per dropdown for performance reasons and to avoid the dropdown becoming unwieldy. If the current user is allowed to add new pages under the parent page an "Add New" link is shown at the bottom of the breadcrumb dropdown. If the currently edited page has children or the user may add children, a caret at the end of the breadcrumbs reveals a dropdown of up to the first 25 children and/or an "Add New" link. Overriding the listed siblings for a page If you want to override the siblings that are listed in the Page Edit dropdowns you can hook the BreadcrumbDropdowns::getSiblings method and change the returned PageArray. For most use cases this won't be necessary. Incompatibilities This module replaces the AdminThemeUikit::renderBreadcrumbs method so will potentially be incompatible with other modules that hook the same method. https://modules.processwire.com/modules/breadcrumb-dropdowns/ https://github.com/Toutouwai/BreadcrumbDropdowns

@wbmnfktr No problem ? @adrian I agree with you (and, as it happens, I agree with your analysis in that issue - it was one of the ones I read before starting this thread), and dealing with these semi-subjective issues is more difficult than the clear-cut cases of a bugfix. However, I'd like to still advance the thought that having a closed issue re-opened, perhaps multiple times, would send a louder signal than keeping it open indefinitely and just having someone give the occasional thumbs-up to one of the pro-posts.

Hi @netcarver - I very much appreciate where you are headed with this, but I am not sure I agree with automatically closing issues 3+months old (even those tagged with not a bug, or fixed) because there is often further discussion after tagging which I think warrants further input/consideration from Ryan. One example is: https://github.com/processwire/processwire-issues/issues/494 - others have chimed in with their agreement and I still consider it a bug because it's possible to set the description and notes for a fieldset. If Ryan doesn't think it's a bug, then I don't think it should be possible to set these in the first place, because it's current confusing and inconsistent behaviour. While I don't expect this will ever be high enough on his priorities to be fixed I still don't think it should be closed because I am convinced it's still something that needs attention, one way or the other. I think the best approach is to encourage issue OPs to be more diligent in closing fixed issues because with so many building up it becomes even harder for Ryan to reconsider some of these other ones which still have some validity. I hope that makes sense and doesn't seem obstructionist in moving forward with an improvement to the current situation which is obviously getting out of hand and not sustainable.

I've updated the module (no version change), so you can update and hopefully it will be OK. Re-download or manually update styles/aos.min.css (plus do some hard refresh to eliminate cache).

Update... The above works okay but it seems that the match callback only fires when CKEditor loads, so to be sure that any disallowed content resulting from the current page edit is removed you have to save the page twice. After a bit more hunting I think I've found a better approach that uses CKEditor's DTD object. It's not quite as straightforward as you'd expect at first because element objects within the DTD object are not fully independent (e.g. CKEDITOR.dtd['h2'] seems to refer to the same object as CKEDITOR.dtd['p']). This SO post helped me find a solution. In /site/modules/InputfieldCKEditor/config.js: // For numbers 1 to 6 for(var i = 1; i <= 6; i++) { // Create the tag name from 'h' plus the number var tag = 'h' + i; // Create clone of DTD heading object so it can be modified individually CKEDITOR.dtd[tag] = Object.assign({}, CKEDITOR['dtd'][tag]); // Disallow strong element from being contained within heading element CKEDITOR.dtd[tag]['strong'] = 0; }

Sure, I was just more interested in the cause but will try the module soon ?

Thanks for your thoughts @wbmnfktr - not sure what I am going to do with it just yet, but if you feel like testing that branch in my fork, I think it's probably best to report issues on Github.

New version just committed that adds support for turning off autoloading of css and js assets files. It also fixes the strange issues that @wbmnfktr was having on some pages. It also adds a "pwcmb-active" class to the body of the page when the banner is displayed.

Ok... I got this totally wrong in your first post and didn't get this @-comment/feedback process. Sorry if my answer was therefore kind of rough. With this comment/feedback process I'd agree with your concept of closing unanswered-open-but-fixed issues.

Thanks for the feedback everyone; some really good ideas here. I guess that Ryan and Francesco are the ones who get to declare if things are getting out of hand though ? Whilst there is, obviously, the ideal issue closure (issue closed by the opening poster after verification that it is really fixed); the reality is that many of the issues have been left unanswered for many months following a commit to the codebase, addition of a tag and a comment on the issue with an @ mention to the person who raised it. If there is no feedback for months following these actions, I'd personally be inclined to close the issue with an invitation for anyone to re-open with a follow-up post if needed. IIRC anyone can re-open an issue by simply posting a new entry on it; closure does not necessarily mean an end to a conversation. Best wishes! Steve

https://github.com/ryancramerdesign/LoginRegister/issues/10

Maybe some kind of Bot can automate the closing of issues that have been marked as "Resolution: fixed (close when ready)" after 2 weeks of applying the label? That would at least clean up those issues.

Thx for the clarification @adrian. Ok, if the usecase fits it seems to be a good solution, but I wished there was a good way to have better and easier control of which pages are shown inside the admin or inside the tree. Taking care of all that tedious stuff (search, pagination etc).

Hey @bernhard - the issue with the num of children is still there, but it doesn't affect the ARB module because it only shows the one branch that the user is allowed to see. I don't think ARB is hacky - I think it's a good solution if it works for your use case. Some of the gists linked to in that post above however are a bit hacky - they don't handle lots of things (like search results) and also have the num children issue and also the problem of hiding a parent of a child that the user might actually have rights to.

There are two things coming up my mind to get this done: FormBuilder + some hooks for checking and saving responses something similar like the Social Impact Award tool @bernhard built in the past

AdminRestrictBranch (https://processwire.com/talk/topic/11499-admin-restrict-branch/) might actually suit your needs as it takes care of the page tree, search results - everything really.

Thanks. Yes, it was macrura's AdminPageFieldEditLinks module.

@dragan Thanks for the reply! I do have some select-options on the filter page, but I need those fields to be searchable through fulltext search unfortunately. I have used the value|title approach, but since I need to support fulltext search, searching the values instead of the titles is not an option. I'll probably use pages from the start the next time, but for now I have to work with what I got. Regarding @heldercervantes's comment, I actually found a solution to that. Turns out that while the magic getter for $field->title and $field->value always return the default values, the proper methods $field->getTitle() and $field->getValue() return the correct values in the current user language. I did post a reply, it never got accepted though .. Still, I'm not sure how to get this fulltext search to work with the current setup.

Discussed recently here:

@bernhard if there is another safe way to give user edit rights and still make sure they can't see or edite pages of others I don't mind changing letting them in the backend and create processmodule pages. Current pseudo backend looks like this. Everything a user adds is private and may not be seen by another or changed by another. The only exception is the classifieds section which is to be seen in the frontend (but also in the backend only for the user who made it). I see in your article that you also use forms. But then I would need to apply the same logic as I do now (or lacking to have done now). What would I need to do If don't want anyone to see the standard pw backend (including the tree). And only have them see somthing like image above, but if they click on 'edit' they can use the pw backend for adding/changing text and images (with use of all the backend security present) of that particular page. Or use the page tree and make sure everything they did not make is hidden (except for the parent templates). Turtles is parent for turtle. They did not create the Turtles page but it groups all turtles from all users. That would be something like this Turtles turtle 2 Grourps group 1 Classifieds classified 4 classified 7 Another user would see different pages. I did tried something like this before, but could not get this running correctly. ohjah, the site is multilangual and with the api the title and name are synchronized on save. Also the name is based on userid and a timestamp so no user can have the same name. Title can be the same as this does not creates issues. I know a lot of questions, but I am quite proud of how far I cam so far, but are still far from being a programmer and understanding how it all works.

I'm looking forward to the 2FA updates. I'm hearing of more and more companies forcing 2FA with their email systems(GSuite or Office365). We've had these discussions and will probably do this at our company as well. Once people start getting used to using it with their email and banks, they will start to expect it with their websites as well. I agree with Ryan, I think it will look good if Processwire already has this security built in. It builds trust with larger organizations. As a website administrator, I currently have to set up a secure password for each of my site editors so they don't get hacked. I can't rely on them doing it. I also have to disable them from reseting their password to something easier to remember. With 2FA, I don't care what they set their password to. It would be nice if we could somehow require/force 2FA for specific roles like Site Editors. I'm not sure if this is a different technology then 2FA, but when using G-Suite, you also have the option to use the Google Prompt. https://support.google.com/accounts/answer/7026266 This makes it much easier to sign into accounts. I wonder if that is just a Google thing, or if that is something that Processwire can utilize as well? They also offer several different ways to authenticate https://support.google.com/a/answer/175197?hl=en including Yubi Keys, Google Authenticator App, Google Prompt, SMS text message codes, and backup codes.

Everybody thanks for your input. I just bought a refurbished macbook pro 15" 2015 with 256Gb with 2 months of apple warranty left and 12 months warranty of the retailer. I got a new display and new accu (complete top casing) with 0 cycles. This should sufficient for the coming years. Will get it tomorrow with the postalservice. Looking forward to unpack it ?

You should activate ACF + HTML Purifier.

Please again consider this change. It would also allow you to add a dropdown for the children of the currently edited page (the one I suggested to remove ? ). You could add a slight delay for the hover – this way one gets not distracted. To add visual clarity to the behaviour one could turn the angle down – if preferred, one can keep the click target to these angles:

Just released 0.2.4 of AdminThemeBoss with compatibility:

Make that optional in module config, I personally prefer to click ?

@MarcoPLY more info about options fieldtype there. There you go ( should support multi-language) : wire()->addHookAfter('LoginRegister::processRegisterForm', function ($event) { $form = $event->arguments[0]; foreach($form->getAll() as $f) { $name = $f->attr('name'); if(strpos($name, 'register_') !== 0) continue; if($name == 'register_subscribe_newsletter' && wire('input')->post->register_subscribe_newsletter == 1) { $options = wire('fieldtypes')->get('FieldtypeOptions')->getOptions(wire('fields')->get('shipping_countrycode')); // get the field foreach ($options as $value) { // loop if(wire('input')->post->register_shipping_countrycode == $value->id) { // check field options id $country_title = $value->title; // assign country option title } } $mc = wire('modules')->get("SubscribeToMailchimp"); $email = wire('input')->post->register_email; $subscriber = [ 'FNAME' => wire('input')->post->register_pad_firstname, 'MMERGE4' => $country_title, ]; $mc->subscribe($email, $subscriber); } } }); ?

I think perhaps I am not understanding what you are looking for, but does this suit your needs? foreach($page->my_repeater as $item) { foreach($item->fields as $field) { echo $item->{$field->name}; } }