adrian

Yeah, a little bit of regex magic should take care of that for you.

My example shows how you can do that with Hanna - you need to do something like define the value of a text variable within the hanna. They are self closing tags. There is no separate hanna close tag.

[[av_textblock size='' font_color='' color='' text='Some Text']] Although I think giving site editors the ability to change font size or color beyond selecting from <hx> tags is a bad idea for keeping a nice looking site.

Just got a couple of likes from @Knubbi on my posts above which prompted me to note that there is a Search and Replace action for my Admin Actions module: http://modules.processwire.com/modules/process-admin-actions/

Awesome thanks so much - this is really speeding my workflow up today.

Thanks Steve, it should be fixed in the latest version just committed.

It's clearly a BatchChildEditor module issue: https://github.com/adrianbj/BatchChildEditor/blob/339624b0a14a9f403ae73b37a08f3e0f5f8d6136/BatchChildEditor.module#L907 It's part of the Lister mode option so if you don't need that, just disabled it and everything will be fine. It's a limitation with PHP 5.3 and $this in enclosures.

@kixe - it might be worth noting that this module requires PHP's bcmath extension because of the call to: bcmod (and maybe others).

Hey Robin - I am really loving this module - it's becoming one of my key navigation tools, so thank you! This might be feature creep so I definitely won't mind if you don't think this is a good idea, but I was thinking an "Add New" link at the top of each list could be quite useful.

I didn't write the initial module - this is a port of a Drupal module. I did this for an agency who wrote the Drupal module and because they are now using PW for several sites, they wanted a PW version of this. It was their choice to use checkboxes. As you can tell they are set up to toggle automatically, but I agree it doesn't really make sense - users are used to radios toggling and checkboxes being for multiple selections. Maybe at some point I'll move this module to use radios, but we'll see ?

I agree but I wonder if you're solution actually makes sense. Surely this bit of code is not logical in the first place - why would we want to show the banner if auto_accept has already been triggered by a view. I feel like they were headed somewhere with this but didn't quite get the logic correct. // if they haven't explicitly accepted it (ie: auto-accept) then display the banner if (pwcmb_settings.auto_accept && cookieMonster.cfg.viewCount != -1) { cookieMonster.ui.show(); } I also find this weird: // if this is NOT the first page view (ie: 2nd, 3rd, 4th, 5th, ...) pageview, then implicitly allow cookies if (cookieMonster.cfg.viewCount == 1) { cookieMonster.allow(false); } // but if they haven't explicitly allowed cookies, then display the banner if (cookieMonster.cfg.viewCount >= 0) { cookieMonster.ui.show(); cookieMonster.cfg.viewCount++; } It says if it's not the first, but then it allows when viewCount == 1 and then another case of displaying the banner if they haven't explicitly allowed cookies. To me the auto accept should work the same as explicitly allowing, otherwise there will be this weird stuff when the user manage option is checked. I don't know - maybe I'll try to get some clarification from the original devs.

Yeah, but what I don't get it why you want to display the banner at this point. Auto accept is true and the page has been viewed - why now show it?

Maybe I don't fully understand what the auto accept mode is intended to do, but there certainly seems to be a difference in behavior when Allows users to manage is checked along with auto accept. Anyway, regarding the new cookieMonster.cfg.viewCount = -1; you have added, I don't really get it - why do we want to set the viewCount when the user blocks marketing cookies? Sorry, I am distracted on other things at the moment and I haven't ever really got my head around this part of the module.

I do want to hear from a few others, but I actually think that #3 (off in backend and on in frontend) makes most sense to me because that matches how PW itself works. I think perhaps a simple OF icon with either a red or green background somewhere on the console panel is probably a good idea as a reminder, but I don't think there should be a toggle - I think if you need to adjust the status, it should be added to the Console code.

Hey Bernhard - sorry for the hassles - hope you didn't do any long term damage to anything! As for whether this should be on or off, I am not really sure to be honest. Perhaps it should be "ON" if you're using the Console panel on the frontend and "OFF" if you're using it in the backend/admin. I don't explicitly set it on, but that is how it works by default. The problem with it being off is if you simply want to get the value of a field, it will return the raw, unformatted value: instead of: So, I guess we could take several different approaches: 1) Always ON 2) Always OFF 3) ON in frontend and OFF in backend/admin 4) Configurable as ON or OFF for both 5) Configurable separately for frontend and backend Any thoughts? What does everyone else think?

There are several outlined in the second Issue that @Robin S linked to. It would actually be great if you could comment on that issue to get Ryan's attention once again if you wouldn't mind.

@wbmnfktr - I am not sure about that fix. When I add that and I click the Do not consent, the banner keeps appearing on page reload. Does that not happen for you?

Thanks for narrowing it down to that option. It looks like it doesn't work in combination with the Allow Users to Manage option. If you uncheck that one, then the AutoAccept seems to work fine. It would be great if you could confirm that at your end, but I think I will make it so it's not possible to select both of these - it will be one or the other.

@Robin S - good call on the change of hook - thanks.

Maybe a typo, but you are missing the period in the $selector .= so that you are concatenating the check_access onto the selector.

Start by removing the $selector check stuff so that it just appends the , check_access=0 bit and once it's working build back up to protect other instances of Pages::find

I put this in my ready.php file: // hack to overcome this: https://github.com/processwire/processwire-issues/issues/550 $this->addHookBefore('Pages::find', function(HookEvent $event) { $selector = $event->arguments(0); if(is_string($selector) && strpos($selector, 'template=user') !== false && strpos($selector, 'name|first_name|last_name%=') !== false) { $selector .= ', check_access=0'; } $event->arguments(0, $selector); }); You'll need to adjust to suit the needs of your selector, but this is how I got around it and make it work for non-superusers. Sorry I forgot about this above. Definitely worth a read through that github issue as well: https://github.com/processwire/processwire-issues/issues/550

Not sure if this helps, but this works for me:

Hey @Macrura - just wanted to let you know that I just started using this module and it's very handy. I don't have enough pages to bother with creating an import script, so copy paste is the way to go and this has made things much quicker. Thanks!

Sorry guys, in a rush but perhaps including "check_access=0" in the selector for the page field will do the trick here. I might be totally off track and it might be a bug, but worth a shot.