adrian

It's not a bug - when saving, output formatting has to be off. PS - you should get familiar with Tracy: bd($page->of()) is a lot easier than messing around with ob_start and var_dump

Well, that's weird - here it returns true or false. Anyway, we are getting off track. Either turn on output formatting before $event->message, or simply add first() before url and you should be fine. Does that work or not?

Do a little experiment and dump or bd($page->of()); before your $event->message and see what you get.

Any chance you have output formatting turned off?

This is the usual array of images problem - either add first()->url, or set the image field to only accept one image.

Is this what you are looking for?

No problem! Should I commit the version with $page->protected property then? I assume that is still something you need to get it working in your scenario?

Perhaps I should add another variable ($ppid - protected page id) to the array that is passed to wireRenderFile. This would be the id of the page that is protected, whether that is the current page, or the parent which is protecting it. That way you could do a $pages->get($ppid)->body to get the appropriate text. Would that be useful? Attached version has this if you want to try it out. Does that idea also help with your multi-language content question? I don't think I am totally following what you need there. PageProtector.zip

Hey @renobird - I have one site that is 5 levels deep and I think it would be great. How many levels are you thinking would be too many? What do you think the issue is with too many levels? Maybe I am just not seeing what the issue would be yet? Maybe long page titles (like journal article titles) would be a problem?

Just my 2 cents, but I'd rather see just the one official admin theme that supports top and side menus. The key thing is that I'd like to have that official theme easily skinnable. I would love the options to color and style the theme with CSS while keeping all the html and php standard. The problem with some of the third party themes back in the early PW 2 days was that new features added to the default theme never made it to the third party themes. I'd also love to see the page tree in the sidebar and the other menu items (setup, modules, access) in the top menu. I am not certain, but I think now that the page tree is cached it won't be a performance issue to have it in the sidebar anymore?

That's not the intention of this approach - the login template you select should be a dedicated template file (it shouldn't really even have a PW template associated with it). The only thing it should echo is the head, footer, etc and $loginForm - that is it! I believe if you follow that approach everything should work as expected and be secure with no need to redirect. Sorry if that's not clear. Sorry about that - silly mistake - I have now replaced it with the PageProtector version I was referencing.

Absolutely! Datamaps supports chloropleth and bubbles. I often use the bubbles options for the markers at various locations. You can color and size them as needed and also add a tooltip with more info. You can even add click events to trigger display of further information on the page - perhaps a chart related to turtle info at the click site. The other great thing about datamaps is that because it outputs as SVG (via D3JS), you can manipulate the elements with css and js very easily. It really is a pleasure to work with. It also works great with AngularJS and I expect it will integrate nicely with VueJS as well (something I plan on trying soon). You can also use your own map data rather than relying on the built-in world / country maps. You just need to convert ESRI shape files to the topojson format, which is awesome for the web. As you can tell, I am a huge fan of the datamaps library Perhaps you should dive in and ask more detailed questions as they come up - probably time to start a new topic though.

I haven't used this module, so not sure how to best integrate chloropleth into it, but I am sure someone who has will chime in. Datamaps works great with PW - no need for a module - just use the dataUrl option and point it to a PW bootstrapped php file which uses PW selectors to grab the required data (Profields Table field works great as a data source, but not necessary), populate an array, and the run json_encode on it. I would recommend starting with a manually populated json file first to make sure you have datamaps working properly, and then work on the dynamically generated file. It's not difficult, but might be a little tricky your first time. PS Of course if your data is in a non-PW database table, you can do direct SQL queries to build up the array/json

http://leafletjs.com/examples/choropleth/ Another awesome option for chloropleth maps is: http://datamaps.github.io/

Yeah, I was hoping to avoid that - I never like polluting all templates with settings type fields if I can avoid it, but maybe in this case it is the only option. I guess if it's set to hidden and system so it can't be manually deleted (but deletion is taken care of during module uninstall), and its checked status would be toggled when checking the "Protect this page" checkbox on the Settings tab, then it wouldn't be too invasive. The other catch of course is that protecting a parent that has thousands or more children could result in a very slow page save because it would need to update the status of all those children as well.

@tpr - just had a quick play with a protected property and selectors. Runtime properties only work with in memory page arrays, so you would have to do: $allResults = $pages->find("template=basic-page"); $notProtectedResults = $allResults->find("protected=0"); I think you already figured this out Anyway, that example works with the attached version. What are your thoughts on the best approach here? PageProtector.zip

Hey @tpr - thanks for the report. I'll take a look at the issue with protected() and trying to make the property available in find() selectors - not sure if this is possible or not. Regarding the child issue - it is working here if use the default login form and also if I choose a login template - that is both options seem to be working fine. Perhaps it's a Latte issue when using wireRenderFile like I am around line 304 ? I don't really understand this - users should see the same login form no matter what page they try to visit (because it renders the template you have chosen) - I don't see any reason to redirect - again, maybe a latte issue? Any chance you could try the module without latte just to see if everything works as expected? Maybe I am still not understanding though?

I agree and think you have a great little module here that will likely become a default install for me.

Oh, I wouldn't say that at all. Lots of the code in Migrator is very messy - I was just joking

I won't take that as too much of an insult

@tpr - I am attaching a new version of the module which rejigs things a bit. It now lets you do: if($page->protected()) { It returns false or the id of the page that is protecting the checked page, which could be itself, or the closest protected parent. This should let you handle your search results however you want. I thought about automatically removing protected pages from results, but I think there are just too many contingencies to do it this way - I think it makes more sense to let the dev handle it via protected() Please let me know how this goes and also if it by chance fixes your issue with child pages not being protected. PageProtector.zip

If I understand the issue correctly, you can just add the image and then get the image name by getting the last added image. no need to clean the name - just let PW do it when you ->add() it. I do the same thing here: https://github.com/adrianbj/ProcessMigrator/blob/0dbeacdf4d1d4a8060d1d513ca9cb2eced3e540a/ProcessMigrator.module#L2577-L2595 As you'll see further up in that function - I am using virtually the same code as you for extracting external images from HTML, importing them locally and setting the new URL in the HTML.

I completely agree - subtle stuff like this makes all the difference in letting you know how something will behave!

So doesn't that mean that you agree that there isn't a need to prevent search from finding protected pages? I guess perhaps it all depends on what you are returning on your search page - if you are providing a preview of some of the content, then I guess this becomes an issue. I guess I'll make it configurable. BTW - thanks for looking into the child pages issue - I can't imagine why it's not working at your end.

Yeah, but they won't be able to get in the window, they'll just be able to see the curtains I would think you'd still want your users to be able to search for the members area - no?