adrian

Looks good here:

A significant update: 1) new auto-accept mode 2) fixes an issue when in EU only mode but the user is outside the EU - GTM tracking beacon is now properly sent 3) tweaks to support older versions of jQuery. Please note that these changes are basically just a port of recent changes to the original Drupal version of the module so let me know if you notice any problems.

One branch is any page you choose and all its children, grandchildren, etc. It does not allow for giving a user access to multiple separate branches.

I'd say it will be a moderate amount of work to convert that PageTable>Repeater action to a Repeater>PageTable action. I don't have time to do this, but would be happy to accept a PR if you or someone else wants to do it.

The hard part is getting OPs to actually close issues when they are fixed and there is no ongoing discussion - if we could do that, then things would look quite a bit leaner in the Issues repo.

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

I think that would be ok so long as it only happens if the thread is also quiet for those two weeks and also if it doesn't prevent the OP from re-opening. I think there are quite a few examples where there is ongoing discussion about further refinements to an issue even after that tag has been added.

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.

Are you running the latest version of the PW Upgrades module? It looks like it is pointing to the old ryancramerdesign github repo.

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.

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.

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.

FYI - I just merged the 3.0 branch to master - be warned that this is a breaking change because of the new data_country db field so please don't update existing installs unless you're prepared to do some DB manipulation - if you want to and can't figure out the required SQL commands, let me know and I can post something here.

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.

Just add the period in: echo "<option value='.".$sanitizer->alpha($subject->title, Sanitizer::translate)."'>{$subject->title}</option>"; This will result in: <option value='.mapsampgeo'>Maps &amp; Geo</option> Is this what you are looking for?

I think the issue is likely php 5.3 - is that the version you are using? Any chance you can upgrade? If not, let me know and I can make an adjustment to support 5.3

Thanks Ryan! While I think this is a great idea in principle, I can't honestly see any of my clients wanting to use this. I guess at least protecting superuser accounts will be a nice improvement. Does anyone else think this will be a hard sell to clients, or do you think they will be really keen to use it? Maybe I need different clients ?

Not sure if this is the issue or not, but in your selector for the Page Reference field please try adding: access=0

Honestly I haven't looked into it at all. As I mentioned in my first post, this module is converted from a Drupal one and so that JS file is almost unchanged from the Drupal version. Just taking a quick look now and I agree that it all looks like a pretty straight-forward conversion and given that I hardly ever use jQuery on my sites, I would welcome the change. That said, I don't have an immediate need for it at the moment so it won't be high on my list - do you feel like putting together a PR ? ? I am happy to implement this if it helps. I am curious though what scenario this is useful for - why do you prefer to manually inject them?

@Macrura - I decided to take a different approach with this. Now all the issues I noted above are no longer relevant. Please grab 1.0.4 and let me know how it goes.

I would still recommend the module that soma linked to - if it's just for Youtube or Vimeo videos, this is a much nicer approach than pasting in iframe embed code.

I guess that is another situation where my implemented fix may not be great. I did look at an alternative which is to grab the title from the locked div (rather than the title <input>). The only catch with this approach is that you can't be certain there isn't other html in there - for example, AOS adds a link to edit the field and with locked fields, this is also in that div, so you need to exclude that when extracting the title via js. I suppose I could pass the title to the js file in a different manner so that the updating will still work - do you think I should look into that?

Are you by chance using the master instead of develop branch again? Remember this was fixed on the develop branch:

@Macrura - I implemented a fix based on my assumption mentioned above. I have disabled the "Rename Without Title Change" option when the title field is locked. I think this is a reasonable approach. I guess the only scenario where this isn't perfect is if a title is changed via the API such that the name is different. Could you please try the new version and let me know if it works as expected for your needs?

foreach($subjects as $subject) { echo "<option value='".$sanitizer->alpha($subject->title, Sanitizer::translate)."'>{$subject->title}</option>"; } Check out the inspection of the select options and you can see it's working as expected.