adrian

Actually, I take that back - having "None" selected is a valid option as you can choose to output the components manually. For now, all you need to do is save the module config settings page once and the errors will go away, but I will fix the module so this is not necessary - should have it done pretty quickly. EDIT: Updated version of module just committed now saves default config settings during installation.

The problem is that you haven't selected a "Phone Output Format" in the module config settings. The module needs this to know how you want it formatted. Do that and the errors will go away ! That said, I should probably handle this better

Yeah, that's what I thought That's not how this works. You need to create a dedicated template for the login form. Perhaps called: loginform.php This template should only contain the framework of your site, eg the header and footer, like in the example, or however you like to structure things, along with $loginForm where you want it to appear. This loginform.php template will be called instead of basic-page.php, home.php, etc if the page is protected and the person needs to login. Does that make more sense now?

Sorry you're having trouble. All I can think is that you are trying to add it to a template that is not selected under the "Login Template" option in the config settings for this module. Are you trying to add it to an existing PW template file like home.php ? The way this works is that the module uses the selected "Login Template" instead of the template that is normally used by a page. Does that make sense / solve your problem?

For the fun of it, I have another solution for you. Firstly, install Migrator via the zip Then extract the contents of the attached file into the assets folder. You should end up with a structure that looks like: assets/migratorbackups/blank-profile Then go to Setup > Migrator > Restore and choose the blank-profile option from the select - it will be the only option available. That should be it. Let me know if that works out for you.

Hi Cerulean and welcome to PW! I honestly think the easiest way would be to delete any installed pages, templates and fields via the admin panel. Then remove the un-needed files from the templates directory. The only other way I can think of would be to replace the contents of the site folder with those from site-blank and then dropping the entire database and using the install.sql from site-blank/install to repopulate it. Then delete the install folder when you are done. Honestly though, this sounds like it could be fraught with danger

Love it Tom - really nice design and functionality - very sharp! One comment at the moment - maybe it's just me, but I find the Contact Us straight to mailto a little annoying

This module has intentionally been kept very simple, hence the login box appears on it's own. I actually prefer this for sites in development so that users can't see anything about the site until the protection has been disabled. However, what you are looking for is available in the Page Protector module. Just use the Login Template option in the module config settings. If you have any questions about it, please continue this discussion over in that thread.

Ok, I have committed a new version that supports protection via the API. You can now do: // all optional, except "page_protected", which must be set to true/false // if setting it to false, the other options are not relevant $options = array( "page_protected" => true, "children_protected" => true, "allowed_roles" => array("role1", "role2"), "message_override" => "My custom login message", "prohibited_message" => "My custom prohibited access message" ); $page->protect($options); Let me know if you have any problems. EDIT: I am wondering if in your case dedicated code might be a better solution. This module stores the protection info in the module's data DB field. While this works great because there is no need for special fields to be added to the templates of a pages to be protected, I am worried you might come across some scaling issues if you have thousands or potentially millions of users, all wanting to protect various pages. I have no idea on the scale of your social network, but this is definitely something to consider.

Some examples from some of my modules - only because I quickly know where I have used these things I'll link to the hook, so obviously also view the called function as well. New tab https://github.com/adrianbj/ProcessRedirectIds/blob/master/ProcessRedirectIds.module#L104 $this->addHookAfter('ProcessPageEdit::buildForm', $this, 'addTab'); Add content to existing tab https://github.com/adrianbj/BatchChildEditor/blob/master/BatchChildEditor.module#L100 $this->addHookAfter('ProcessPageEdit::buildFormChildren', $this, 'addChildTabContent'); Obviously with this, "buildFormChildren" could be replaced with buildFormSettings etc. Hope that helps.

Glad you like it Not currently possible - I didn't really think it would be that useful since this is primarily a tool for site editors. I am willing to add the option - perhaps a new protect method so you could do something like: $page->protect($options); where $options would be for children, message, roles, prohibited message. Would you mind giving me a use case scenario so I can get a better idea of how useful this feature would be ?

Hi Hummer and welcome to the forums! I honestly don't really understand your needs properly - $page->children() will only return the children of the current page, not the page itself. Could you possible clarify exactly what you want a little better?

Hey Joss - thanks for the file. The issue was with some broken images embedded into your blog posts - some linking to an old joomla site . Migrator now handles broken images properly so no errors. I also took the opportunity to add a few more fixes and enhancements to embedded images and captions - links to the original sized version now also work (although I am wondering the best way to add a class for lightbox display of these. I don't want to assume the class that users want, so maybe this needs to be a configurable setting - any thoughts?). Please try the latest versions of both ProcessMigrator and MigratorWordpress (again from my fork) and let me know how you go. Here's a screenshot of what one of blog posts looks like for me once imported. Be patient - it can take quite some time to download all those images, but it will work

Thanks - it seems to be working fine here. The only thing is that you should remove the extra space around the image - not sure what software you are using, but in Illustrator, you want Object > Artboards > Fit to Selected Selected Art. Do you definitely have the "Display thumbnails in page editor?" setting checked for the image field? As for the front-end display issue - if you are getting a broken image, can you please inspect the element and check the path to the image and see if it seems logical and also check that the image exists at that location. Let me know what it says.

Lance - that is strange. I am going to be doing some work on improving SVG support to handle images without defined width/height in the next few days and will submit a PR to Ryan. I am not sure why it isn't working for you after you have added those attributes though. Could you please PM the image so I can test?

Hey Joss, Thanks for testing this out. Looks like you have come across an issue with a very recently added function to scan through RTE fields and automatically generate resized versions of images that have been embedded. Actually I am wondering - is the WP still still online and working? It needs to be so that the module can download the images from the site and add them to each of the pages in PW. Any chance you could PM me the WP xml file so I can test? I am heading out for the rest of the day, but I will look into it in the morning for you - I am sure it will be an easy fix. PS, Please make sure you are always using the latest version of Migrator and also MigratorWordpress (my fork - Nico's is not up to date)

$fields->save() would save details about that field - various settings etc, rather than the contents of the field on that particular page. $event is coming from the event that is hooked, so in this case, @majkiris is hooking page save, so by getting the first argument from the save event, he is getting the page object. You could also do: $page = $event->argumentsByName("page"); The first argument, eg arguments[0] won't always be the page object, it depends on the hook. Sometimes, for example, it might be the width of an image. Hope that helps a little.

I think what you are looking for is: $page->save("total"); If you did just $page->save() you'd end up in a loop because your hook would get called again each time it saves itself. EDIT: Oh and in case you haven't figured it out, you need to set the field value first: $page->total = $ratTotal;

This gets you the label in the context of the entered template. $templates->get("template_name")->fieldgroup->getField('body', true)->label; You could also do this to get for the template of the current page: $templates->get($page->template->name)->fieldgroup->getField('body', true)->label;

Wait till you see what horst has in the wings to replace this Stay tuned!

I am sure lots of very cool things could be done, all of which will require a little more than the 5 mins of planning and 20 mins of coding I put into this one Here is a revised version (with a new name) with about an extra 15 mins of coding that adds support for batch adding/removing of fields from templates. I think I might actually make use of this version quite a bit. EDIT: I don't think "Template Setup Batcher" is the right name - not really about setting up templates from scratch. Oh well - maybe change again if a newer version ever happens ProcessTemplateSetupBatcher.module

I think hanna code makes the most sense here, but of course if you'd rather avoid that for some reason (maybe no other needs for it on the site, or whatever), you can always do your own replacement. Have your editors enter [[gallery]] somewhere in the body copy and then in your template do a simple: echo str_replace("[[gallery]]", $galleryCode, $page->body); You just need to define $galleryCode in your template code somewhere before the body is output.

Inside a module I think you probably want $this->page or wire('page') Have you checked that $file->filename is returning a valid path to the file? Also, have you seen horst's module: http://modules.processwire.com/modules/local-audio-files/

encho - there is no need to create any templates/fields - that occurs automatically. I have personally only tested it with the blog section of a WP site so far, but I think it should also work with normal WP pages. I will actually be using it myself in the next couple of weeks, so if there is an issue with ordinary pages, or any other specific types of WP content, I will be keen to get these sorted out. Could you perhaps PM me your WP xml export file so I can take a look?

Gazley, I am not sure what version of blog you are using but I know that kongondo made some relatively recent changes to help with clean up of pages when uninstalling. But it sounds like you might need to do some cleanup anyway at this point. Did you use the PW backup module to do your backup and restore? Unfortunately there is a bit of a limitation with that backup module at the moment in that it doesn't start with a blank DB when restoring so you can get that situation with existing tables. At this point I would suggest uninstalling the blog again and then manually removing the DB tables - all that start with "field_blog_*". Also check to make sure there is no entry for the blog module in the "modules" DB table. Hopefully with a clean start it should install fine.