ryan

By parent, do you mean the page that the repeater lives on, or the parent of the page that the repeater lives on? If parent is the page that the repeater lives on, then there'd be no reason to query it since you could just access $page->repeaterField->find(). So I'm assuming you mean parent of the page that the repeater lives on. That's a tougher question, and not sure there is a good answer since repeaters are disconnected from the site's structure (they have their own structure off in the admin). The only physical connection between the repeater items and the page they represent is the repeater page name, which uses the syntax "for-page-[id]". Currently I can't think of a straightforward way to perform that query, at least in a manner that would be scalable to tens of thousands of items. A non-scalable way to do it would be: $selector = "template=repeater_eventdetails, date>0, sort=date, include=all, name="; $parent = $pages->get('/some/parent/'); foreach($parent->children as $p) $selector .= "for-page-{$p->id}|"; $items = $pages->find(rtrim($selector, '|'));

I haven't, but am also interested in hearing if anyone else has experimented with this.

Soma you and some other guys here make my job easy because most of the hard questions were already answered. So thank you for all the help and support give here. You all make this forum great.

I've actually been putting some thought to drafts and think I've got some good ideas to move forward with a simple drafts system soon. Page status 4096 is reserved for Page::statusDraft. That keeps drafts in the Unpublished territory, excluded from all but "include=all" selectors. Page IDs 500-999 are reserved for drafts (so the IDs will be reusable, unlike other page IDs). I don't imagine many would need more than 500 drafts at a time, but if they do, we can make the ID reuse optional. Drafts will be an optional module, not installed by default (like autocomplete, repeaters, etc.) Versioning will be something different entirely, as I don't want versions filling up the pages tables. But versioning will likely use drafts as a transition point.

Okay thanks, sounds like a bug then. I'll get on that.

I finally caught up with those 9 pages of posts and am down to 0 posts in my "new content" list. Sometimes things escape my new content list, so if anyone is waiting on me for anything or aware of something that I might have missed, please let me know. Happy New Year to everyone! Hope that you all have a great New Years day today.

Here is the same thing as a Textformatter module. To use, paste the following into /site/modules/TextformatterImagesToPages.module. Then, in your admin, to to Modules > Check for new modules. Click install on the new module. Then go to Setup > Fields and edit the field you want it to operate on ('body' for example). On the "details" tab, choose the "Images to Pages" text formatter, and save. The text formatter will be applied automatically when you access any $page->body field from the front-end of your site. /site/modules/TextformatterImagesToPages.module <?php class TextformatterImagesToPages extends Textformatter { public static function getModuleInfo() { return array( 'title' => 'Images to Pages', 'version' => 1, 'summary' => "Takes image links in HTML and converts them to page links." ); } public function format(&$str) { $rx = '{href="' . wire('config')->urls->root . 'site/assets/files/(\d+)/.+?"}i'; if(!preg_match_all($rx, $str, $matches)) return; foreach($matches[1] as $key => $id) { $page = wire('pages')->get((int) $id); if($page->viewable()) $str = str_replace($matches[0][$key], "href='$page->url'", $str); } } }

Most of the instances I've heard of where people lost their work had to do with creating new pages that weren't yet published. For unpublished pages, the issue Pete mentioned is really not an issue at all. Perhaps a setting to limit the auto-saving to unpublished pages would be all that's needed, since that is the time when this module is likely most valuable. I'd suggest this might even be a good default setting. The 3 instances I'm aware of–Mike (cmscritic), Teppo, and Peter–would have all been for an unpublished page (I think) and would have been saved by this module. Nice job btw!

First question would be why not just link to the page rather than the image in the first place? But thinking on it more, I'm betting you are inserting these from TinyMCE/CKEditor? Something like this might work: function replaceImagesWithPages($str) { $rx = '{href="' . wire('config')->urls->root . 'site/assets/files/(\d+)/.+?"}i'; if(!preg_match_all($rx, $str, $matches)) return $str; foreach($matches[1] as $key => $id) { $page = wire('pages')->get((int) $id); if($page->viewable()) { $str = str_replace($matches[0][$key], "href='$page->url'", $str); } } return $str; } echo replaceImagesWithPages($page->body); This type of thing could be bundled into your own Textformatter module for easy re-usability (let me know if I can elaborate). Note that this was written in the browser and not actually tested, so may likely need adjustments.

Strangely I can't duplicate the issue, but the error message you guys have mentioned is correct. It was attempting to call a parent::__construct() even though the class it was extending had no __construct in the chain of classes. I'm guessing some versions of PHP care and some don't. I have updated the module to remove that call. Please let me know if it works for you guys now?

In your /site/config.php file, you'll want to set a whitelist of allowed hosts. This was just added in 2.3.9 and it's a recommended security optimization. Include both your SSL and non-SSL host names in there. Please let me know if this resolves the issue you are experiencing?

Craig is correct, as this is most definitely related to the sessionFingerprint, as your IP address is clearly changing when the VPN disconnects and reconnects. It sounds like in your case, you should disable that feature by setting it to false in your /site/config.php file. I'm 99% sure that'll fix the issue you are experiencing.

The consensus around here has been that captcha is not worthwhile. Most of us get better results by using honeypots, which are simpler both for the user and the developer. However, if you or anyone else decides to build a Captcha Inputfield I'm here to support and answer any questions you have, and I'm sure there will be an audience for it in the modules directory. But if your goal is to prevent spam submissions, definitely look into using a honeypot first, as your users will thank you and you'll likely see less spam too.

Conversion of image type is more complex than just changing the extension. All the data in the image has to be uncompressed then re-compressed with the new format, and that's something that goes beyond the scope of our image manipulation functions at present. While true that some browsers will recognize a jpg as a jpg regardless of extension (by detecting the type in the image data), the file becomes essentially corrupt as it's no longer consistent with the indicated type.

Are you suggesting that a PSD file should be automatically renamed to a JPG file? Those are two very different file types. However, if you have the need to do that, I may be able to suggest a hook. But I anticipate you wouldn't be able to use any of the image manipulation functions on the renamed file without getting exceptions (unless PSDs can now pretend to be JPGs through some file data tricks). Regardless, a PSD is a full-blown Photoshop file and not an appropriate format for web storage unless you intend to distribute source files, in which case you'd definitely want to keep the PSD extension.

The module may need a Pages::deleted hook: public function init() { $this->pages->addHookAfter('deleted', $this, 'hookPageDeleted'); } public function hookPageDeleted($event) { $page = $event->arguments(0); $this->db->query("DELETE FROM " . self::TABLE_NAME . " WHERE pages_id=" . (int) $page->id); }

Thanks lpa! I am adding these to dev.

Field settings are saved in a compressed format that eliminates empty values. The value 0 is considered an empty value because it resolves to true in comparison to a blank string. So a blank string can be seen as the same thing as 0 in this case. Are you able to enter and save negative values on your page that is using this validation? If so, let me know as the validation in InputfieldInteger might need an adjustment.

Is your error message still appearing? ProcessWire doesn't abort a save even if there was an error on some field, so that is normal behavior. Though it will prevent an unpublished page from being published if there is an error occurring. If you want to literally prevent the save from occurring, you may have to throw an exception.

I'm not sure there's really much difference in sending them a reset URL or a password, as neither is encrypted once it goes out in an email. Though I prefer to use a unique reset URL, as it's less work for the user. Expiring that URL is definitely a good idea. I don't see it often used, but I also like to limit the usage of that URL or password to the session that initiated the request. Meaning, when you request the password reset, you get a unique token set in the session, along with a timestamp of when it was set (so you can determine when it should no longer be valid). This token can be the same as the unique URL you sent them. When the user comes back from the URL they clicked on in the email, the request is only honored if the token you set in the session is still active and matches with the URL they requested. Using this method provides a better accounting for the fact that email is inherently insecure.

Definitely check out version control for text fields if you haven't already. This module is so good, that it's rare I wish for anything else. That's not to say that there isn't more to be done with regards to core version control, but Teppo's module covers the most common version control needs beautifully.

For truly dynamic pages that need to change on every request, don't use a template cache or ProCache, and instead use MarkupCache for the parts that don't often change (if you need to use a cache at all). No doubt, delegating things to javascript where possible is very cache friendly with template caching and ProCache. Even if you are shifting things to be ajax-loaded, the ajax requests can themselves be delivered by ProCache or template cache, perhaps just on a shorter cache time. Not to mention, the results of those ajax requests can be cached client side in cookies if needed, serving as a client-side cache that you control. But I honestly don't think most people need to get into this level of caching, unless dealing with some major traffic considerations and/or server that can't keep up with it dynamically.

To check category permissions I need permissions set by template access for each category? DIfferent templates for the categories? Yes, though I used that only to keep the example really simple. Your actual needs may demand something more. For instance, if you wanted to define the roles that could access, with each category page, then you might create a new "custom_roles" Page reference field that selects from pages in /processwire/access/roles/. Then add that field to your "category" template, and edit your categories to select the roles. Then you could modify the previous example to be something like below, that adds a viewable() hook to category pages as well. /site/templates/admin.php <?php wire()->addHookAfter('Page::viewable', function($event) { // if it was already determined page isn't viewable, exit now if(!$event->return) return; $page = $event->object; $user = wire('user'); if($page->template == 'category') { $found = false; // check if user has any of the roles selected for category foreach($page->custom_roles as $role) { if($user->roles->has($role)) { // user has the role, so this page is viewable $found = true; break; } } // if no matching roles found, page is not viewable if(!$found) $event->return = false; } else if($page->category) { // if category isn't viewable, we'll say this page isn't viewable either if(!$page->category->viewable()) $event->return = false; } }); // the rest of admin.php ...

Module has been updated for this change (config.entities=false)

Teppo, the way you describe the entities config option, that makes sense to me. Given these issues, I wonder why they have it true by default. I have updated the InputfieldCKEditor module to have the entities option set to false by default. I really can't think of any security issues with doing that, especially given that we're requiring HTMLPurifier for the inline editor. As for why I seem to be getting the entities=false behavior for quotes already, I have no idea. Maybe something to do with HTMLPurifier and inline mode vs. regular mode.