adrian

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?

Sure, it's just a little weird though as $loginForm should work everywhere in regular templates - at least it has in my testing. No problem here - would you mind doing a little testing in the isProtected() function to see where it might be failing. Is $pagesToCheck including the parent which is protected? Is $this->matchedParent being populated with this page? etc This module is designed to protect access to pages - I am not sure that it should actually prevent pages from being found. I am happy to revisit though if you think otherwise - it should be easy enough to do.

Hi @tpr - I have made all those requested changes and also several other updates to the module. Please let me know if you find any problems.

You can also avoid recursive issues with hooks on save by just saving the field you have changed, rather than the entire page, eg. $OtherPage->save('ThemeCachedCSS');

Ok gotcha - I see how it helps now. I had a quick look and couldn't figure out what it achieved, but now I see and agree it's a little nicer. I wish there was a way to not have it partly cover the sidebar, but with those elements being absolutely positioned, I don't see an option. I think what I ended up with is a decent compromise though - it's narrow enough that it doesn't interfere, but is still obvious enough. If anyone has any better ideas I'd be happy to change.

Hey @tpr - where do you think this should be applied? Sorry if I am missing the obvious

I know it doesn't help much, but I am using the update module with PHP 7.1 with no problems. I know there were some issues with early versions of PW 3. Have you tried upgrading to the latest dev?

PW won't let you call php files directly from the sites directory (including the templates subfolder). You can either put the load.php into a folder above sites, or you could assign the file as a template for a page and load("the_page_url");

yep: /** * Installer: Database Configuration * */ $config->dbHost = 'localhost'; $config->dbName = 'pwtest'; $config->dbUser = 'root'; $config->dbPass = ''; $config->dbPort = '3306';

Well given that PHP can't determine the screen width, you'd have to get it via JS and then do an AJAX call based on that width. Honestly I don't think there is much point to that. Just get as many posts as you need for the widest screens and then limit their display with css or js.

Let's take this to PM