ryan

Lpa: I looked at your map, and you've got a Javscript error occuring related to magnificPopup. That error is occurring before the map resize gets to occur (due to the setTimeout), so it is effectively preventing the JS code from running. If you can resolve the JS error you are getting, my guess is it would start working.

In that case, it can be done. The security aspect was really the main thing that would prevent one from wanting to use this on the front-end, as it's a module meant for people that have access to edit pages. Not that I've tried it, but if the security aspect is not applicable then it should be possible to get it to work on the front-end.

The submit buttons that sometimes didn't register were driving me nuts. After trying to debug it for a long time, I gave up and just dumped the jQuery UI theme that we were using, downloaded a fresh copy of jQuery UI and put in it's default UI theme to replace. That seems to have fixed the issue. The only place you'll likely notice the jQuery UI theme change is in the datepicker, which isn't quite as pretty as the one that came with that other theme... but I'd had it with the submit button issue. I think we're better off just to stick with the latest version of a generic jQuery UI theme from the source, just to avoid bugs like the submit button one. It doesn't matter much to the admin theme, as very few things are actually styled by jQuery UI's stylesheet (datepicker, slider, etc.) Joss–glad to see you experimenting! Regarding a "site" link, the theme has one as the home icon that leads the breadcrumb trail. I like it and think it makes sense, but have heard more than once that others aren't getting it, so I think we'll have to add a site link somewhere else. Regarding opening in a new window, this would be controversial because a lot in the development community think that a site/app should never open a new window and instead leave the choice to the user (click vs. cmd-click). I lean towards the side of leaving it to the user... not because I have a problem with target=_blank, but because it would drive me insane to have new windows opening all the time like that.

It could potentially be done right after we wrap up the 2.4 release. The amount of work and time involved would probably go a little beyond what was involved in developing dependencies, but not not nearly as time intensive as developing the multi-language support. The workflow would simple and the same thing as it is when you are editing an unpublished page at present, at least from the perspective of the editor. I think this is also similar to what Soma was talking about with their existing system. Because it would be a draft of a live page, there would also need to be an option to "abandon draft". But beyond that, it would be the same as editing an unpublished page. Of course, you could preview it and such, like you can with an unpublished page. Drafts would use more overhead than a regular page edit (since it has to make a copy of the page first), so you'd designate which templates you wanted it to utilize the drafts system for. The page creation process would not change at all, since a draft would only come into play with a published page (a draft is a working copy of a published page).

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.