Robin S

Hi Louis, This is a strange one. I did some testing (as opposed to just writing code in the browser like I did previously) and it seems the problematic part of the selector is: includeFooter!=1 I took this construction from a post here on the forum that suggests that this matches unchecked checkboxes but for some reason this doesn't seem to work. This works: includeFooter=0 and this: includeFooter='' But the weird thing is that neither 0 nor '' equals 1 so I don't understand why the !=1 construction doesn't work. Maybe someone can explain this.

Thanks @mr-fan, I'm familiar with that thread and I am activating users via an email link. But in principle I think unpublished/published users is the ideal way to have users in an inactive/active state. That's what the published status of a page is for, so it shouldn't be necessary to add a new field for the same purpose. And it also has the benefit of preventing login and view access for unvalidated user accounts without the need for additional logic in login functions and page templates.

Thanks for the module! Another approach to inherit the values of parent page fields: $foo = $page->foo ?: $page->closest("foo!=''")->foo; So if field "foo" is empty for the current page $foo gets the value of the closest parent in which field "foo" is not empty. Not to say this is as flexible as your module approach though.

Solved now - $sanitizer->textarea works just fine with no options needed. I just couldn't see the line breaks because I put the plain text message in WireMail's bodyHTML.

When using basic WireMail I'm looking for a way to convert the HTML message to a plain text version while keeping line breaks. For example, I want: <h1>She sells seashells</h1> <p>On the sea shore.</p> ...to become... She sells seashells On the sea shore. I thought one of the sanitizer methods might help out here and I've tried a few things with the "newlineReplacement" option for $sanitizer->textarea but no luck yet. Any suggestions?

Users are pages, but in the Users section of the admin there isn't the same support for unpublished users as for unpublished pages. When users register on the frontend I set their status to unpublished until their email address is validated (thanks to a suggestion in the forums from Soma). But while users are unpublished it isn't possible to make edits to their profile via admin because there is no "Save and keep unpublished" button like there is for other pages. To save changes in admin the user must become published. Also, there is no ability to unpublish a user from admin. This would be a useful option if a user account needs to be suspended rather than deleted. Edit: another small thing that would be nice to have is for the user list to honour the useHoverActions config preference for PageList. I keep hovering on the user list and then I remember I have to click the name to get the flyout links.

Just a heads-up that there appears to be a conflict between Batch Child Editor and Pierre-Luc's Password Reset module. ProcessWire: ProcessPageEdit: Unknown template #0 ...\site\modules\BatchChildEditor\BatchChildEditor.module(711): BatchChildEditor->isAllowedTemplateAdd(147, Object(Page)) #1 ...\site\modules\BatchChildEditor\BatchChildEditor.module(348): BatchChildEditor->createChildEditSet(Object(Page), Object(Page), Object(InputfieldWrapper)) #2 ...\wire\core\Wire.php(459): BatchChildEditor->addChildEditFieldset(Object(HookEvent)) #3 ...\wire\core\Wire.php(333): Wire->runHooks('buildFormChildr...', Array) #4 ...\wire\modules\Process\ProcessPageEdit\ProcessPageEdit.module(456): Wire->__call('buildFormChildr...', Array) #5 ...\wire\modules\Process\ProcessPageEdit\ProcessPageEdit.module(456): ProcessPageEdit->buildFormChildren()

Thanks for this module, Pierre-Luc. I get a couple of errors when using it. When assigning the template "password-reset" to a page or attempting to edit a page with the template assigned I get: Edit: this error seems to be caused by a conflict between Password Reset and the Batch Child Editor module. After uninstalling Batch Child Editor the error message is not shown. And when viewing a page with this template assigned on the frontend I get: Looking at line 32 maybe this error is because my site is not multi-language?

I forgot the quote marks for the find selector. Have updated my post.

If the renderChildrenOf() function is producing the markup (classes, etc) you need for a Bootstrap menu then you won't need to make any changes within the function. It already contains a foreach within the function so you just need to give it the PageArray of the top-level menu items. $homepage = $pages->get(1); $main_nav = $pages->find("parent=1, includeFooter!=1"); $main_nav = $main_nav->prepend($homepage); echo renderChildrenOf($main_nav); Depending on what you want for the footer menu you might use renderChildrenOf() for that too, or write your own foreach for $footer_nav

Sounds good to me.

I think you already solve that scenario with if(strpos($imageVideoName, 'video-') === false) continue; So a manually uploaded image will not be replaced (well, unless the image name by chance included the string 'video-' but that's unlikely). And that makes total sense to me. It wasn't what I expected at first but now I understand the intention behind it I see how it's the best option. And this behaviour could be mentioned on the module config screen or module description to clear up any confusion.

Hi Adrian, It's totally fine if you think it's best to require the thumbnail field to have maxFiles '0' - as I mentioned above, I can only see myself using the module with a dedicated image field that I will make non-editable to users, so for me the field will only hold a single image even if maxFiles is set to 0. But if you wanted to support fields with maxFiles '1' I found that simply reordering the code in your module (the version before your most recent release) fixed the bug. By placing this section... //Delete any images from videos that were removed from the text fields during this update if($page->{$this->videoImagesField}){ foreach($page->{$this->videoImagesField} as $videoImage){ $imageVideoName = pathinfo($videoImage->filename,PATHINFO_FILENAME); if(strpos($imageVideoName, 'video-') === false) continue; if($this->whichImages != 'firstAvailable') { $imageVideoNameArray = explode('-',$imageVideoName); $imageVideoID = str_replace('video-', '', trim(str_replace(array_pop($imageVideoNameArray), '', $imageVideoName),'-')); } else{ $imageVideoID = str_replace('video-', '', $imageVideoName); } if(!in_array($imageVideoID, $allVideos)){ $page->{$this->videoImagesField}->delete($videoImage); $page->of(false); $page->save($this->videoImagesField); } } } ...above the sections that grab the thumbnails from YouTube/Vimeo any unneeded thumbs are disposed of before the field is repopulated with the new thumbnail. But I didn't do extensive testing so there are perhaps consequences to reordering the code like this.

Sorry, sloppy testing on my part. You're absolutely right; relative time only works for $pages->find(). Shame though, as would be nice to use it for PageArrays.

Thanks @BitPoet, you've helped me understand this better. It was because my relative time string was cast to an integer that I was getting confusing results (rather than an error or no results at all). Although in regards to... ...I ran a couple of tests and it seems that relative times work for any PageArray - so they do work for $pages->find(someselector)->find(selector_with_relative_timestamp). Edit: does not work And relative times seem to work for any custom Datetime field, so not just "created", "modified" and "published". But you've nailed it about the Comments fieldtype, which of course is not a PageArray. Would be nice to use relative times with a Comments find so thanks for making that Github request. Although now I understand a bit more about when relative times are possible and when they're not it's pretty easy to just do: $time = strtotime('2 days ago') or whatever and use the variable in the selector. And a little off-topic, but for anyone wanting to do a find on comments across multiple pages this function from Ryan's blog profile is very useful. FieldtypeComments::findComments should probably be mentioned in the Comments docs.

Thanks @LostKobrakai, I think you may have hit upon what is giving me the unexpected results when using a relative time in a selector. I did some testing with a $pages->find() selector on a datetime field and the results were identical for strtotime and for having the relative time in the selector. So no problem there. But the selector that is giving me odd results when the relative time is in the selector vs stored in a variable as a timestamp with strtotime is: $comment_page->comments->find("created_users_id=$this_user, created>='20 hours ago'") This uses find on a comments field - does this find operation filter in memory or with a database query? Is there a way to know when a particular find operation will be performed in memory?

Thanks @gebeer, I will definitely check out those parts of the PW code. I need to do more testing and will post back when I do, but based on some quick tests it seemed that the strtotime way was producing correct results while the native PW relative date was producing incorrect results. I do have the right timezone set in my config though.

It's cool to be able to use relative times in selectors like: post_date>='90 minutes ago' But for debugging purposes I'd like to be able to get the timestamp that '90 minutes ago' actually results in. How can I do that? I thought it would be the same as PHP's strtotime, but in a selector: post_date>='90 minutes ago' Produces different results to: $mytime = strtotime('90 minutes ago'); ... post_date>=$mytime

Currently you're getting your top-level menu items with: $pa = $homepage->children; Try changing to a find selector. If there is some common attribute of the pages you want for the footer menu (template, value of a field, etc) you could use that to exclude the pages, otherwise you'll need to exclude them by name or id. $pa = $pages->find("parent=1, id!=1050|1051|1052"); Edit: just noticed that you have added a checkbox to select pages for the footer nav. So you can do: $footer_nav = $pages->find("parent=1, footer_checkbox=1"); $main_nav = $pages->find("parent=1, footer_checkbox!=1");

The demo shows an "insert paragraph here" feature when you hover on the bottom of the div. Not sure if that's part of the div plugin or a different plugin you'd need to install.

There is a CKEditor plugin that looks like it's designed for what you want: http://ckeditor.com/addon/div You can try it out in the demo, third toolbar row.

I think this is the problematic step. CKEditor can't know that you want to wrap these selected elements in a new element. Try creating an empty paragraph (maybe with a space or temporary character in it), select and apply the "Box" style, then cut and paste your paragraphs into it. You're probably aware of this already: it will be easier to see your box element if you add some styles for .box in your CKEditor "contents.css".

Found some helpful discussion related to this issue here. The value of the inputfield must be set to a Pageimages object for an existing page. By default $page is used (which isn't what is wanted for this example) but it can be changed to a different page. In the context of Soma's gist the fix is to add the following at the end of the "success" section: $form->get("myimages")->attr("value", new Pageimages($uploadpage)); So the complete success section is if(!count($form->getErrors())){ // if no error occured // create new page and save values $uploadpage = new Page(); $uploadpage->template = "upload-entry"; $uploadpage->parent = $pages->get("/upload-api/"); // add title/name and make it unique with time and uniqid $uploadpage->title = date("d-m-Y H:i:s") . " - " . uniqid(); $uploadpage->addStatus(Page::statusUnpublished); $uploadpage->save(); // save uploaded files to new page and remove temp files $files = explode("|",$form->get("myimages")->value); foreach($files as $file){ if($file && file_exists($upload_path . $file)){ $uploadpage->myimages->add($upload_path . $file); unlink($upload_path . $file); } } $uploadpage->save(); $form->get("myimages")->attr("value", new Pageimages($uploadpage)); $sent = true; // or better do a redirect here before showing thank you text. }

I'm trying Soma's gist for uploading a file from the frontend using the core File inputfield. After submit the file uploads just fine and I get the success message, but I also get an error when the form is re-rendered. Warning: filemtime(): stat failed for .../site/assets/files/1228/test-image.jpg in ...\wire\core\Pagefile.php on line 324 I believe the inputfield is trying to display information relating to the previously uploaded file, like it does in Admin. The reason this file can't be found at that location is because page 1228 is the page where the form is, whereas the file has been inserted into a different page. There's a line in the gist that looks like it's intended to solve this: // reset value before rendering the form again to prevent PW errors trying render files (as in admin) $form->get("myimages")->value = ''; // reset field value But maybe this isn't the right way to reset the value of a File inputfield? Edit: actually, the form isn't re-rendered on a successful submit, so not sure what is causing the submitted file to be looked for in this wrong location.

Ahh, right. I was meaning the file I have auto-prepending to my templates, which I happen to have called init.php. I should have been clearer.