ryan

Thanks for these updates. We'd talked about getting AdminBar bundled into the core distribution and I still want to do that. If you still want to lets try and get it in before 2.2. I just need to update the Modules system to deal with duplicates in case someone upgrades a system that already has /site/modules/AdminBar/ installed.

Thanks for sharing your experiences with these PDF tools, this is really good info! I have not experimented with PDF generation with PHP before and almonk's module and your info opens a lot of doors.

PW doesn't handle page numbers internally. Like with regular URL segments, it's up to you to decide what to do with them. PW doesn't know or care what your bounds are for page numbers. The MarkupPagerNav module is not a dependency for handling page numbers, and may or may not be used (that's a runtime decision). So if you want to handle numbers that are out of bounds, you can throw a Wire404Exception when that occurs (like you would with an unknown URL segment), though I don't usually bother with it. I think a better thing to do is to leave no results (with the pagination intact) or send a session->redirect back to page 1 or the last page. That way, if there used to be a page number in bounds that no longer is, at least you are providing a way for for that traffic to get back in-bounds.

ProcessWire's API prevents changes to some system templates/fields, so you have to go behind it's back and use a DB query. So to switch it back to the previous fieldgroup, insert this into one of your templates temporarily and view a page using the template (like your homepage): <?php $name = "name-of-template-you-want-to-fix"; $template = $templates->get($name); $fieldgroup = $fieldgroups->get($name); $db->query("UPDATE templates SET fieldgroups_id={$fieldgroup->id} WHERE id={$template->id}"); Once you do that, it should be fixed and you can delete the above code snippet. To turn off advanced mode, edit your /site/config.php and locate the line that says $config->advanced = true; and change it to false.

Thanks for posting that. Hooks in ProcessWire are one of those things that is still evolving, so rather than try to cover every possibility and publish an official list of hooks, I'm taking the strategy of letting it evolve a bit first and adding new hooks as needs surface. Looking at an grep (or findstr) of all available hooks doesn't tell the full story. By that I mean that one shouldn't give up if they find there is no hook for something they need to do. Instead, post in the forum or email me and I'll make an existing function hookable or add a new one to cover a need. Likewise, one shouldn't assume that all the hooks that appear are recommended... Over time I've been discovering that several things that are hookable don't really need to be (though I don't plan on removing any hooks). As the software matures more, we will eventually have a good idea of all the hooks that make sense and will publish an official list of hooks. But until then, the grep (or findstr) is the best way to see them all. I just wanted to make sure I gave that type of list some context and encourage people to get in touch as new hookable needs surface.

The 'Search' label is actually in this file: /wire/modules/Process/ProcessPageSearch/ProcessPageSearch.js this line, near the bottom of the file: var label = 'Search'; I'll be starting up the support for multi-language here very soon, so hard-coded labels like this will be a thing of a past in the near future.

I echo that sentiment–thanks to everyone here!

You can also use the "%=" operator in your selector, rather than "*=", i.e. "body%=que", and that will work. The "%=" operator uses the MySQL LIKE command rather than a fulltext index, so it's not bound by word length or stopwords. However, on a large site it is a lot slower since it's not using indexes. Though you may have to be dealing with hundreds or thousands of pages before the difference would be major. I compared broad text searches on a site with 3,500 pages and didn't perceive any difference in speed when replacing the "*=" with "%=". However, it really may depend on the server and *= is going to be measurably (if not noticeably) faster the larger the site gets. So if you can tweak your MySQL settings to support words below 4 characters like in Antti's link, then that is preferable since it is technically more efficient.

It was a bug. Thanks for finding it. Just fixed it now, so it's in the latest commit. It sounds like you must have made it angry. Actually, I have no idea what that is – please let me know if you can reproduce it. There was a missing </ul> tag in the InputfieldCheckbox module (used by the status boxes) that was fixed a few commits back, so if you aren't running a new version from this week, it's possible that could be it.

Always open to suggestions. Right now they are alpha ordered by category and module name. I'm not sure you can get more straightforward than that? At least, I would worry about causing confusion with any other type of order. One possibility would be to have a couple of categories at the top that duplicate whats in other categories, but call out "New Additions", "Popular Choices", etc. Soma also put together a great module that shows just one category at a time. While I prefer to see everything at once, I do think that module makes it more approachable to look at.

Good suggestion and I totally agree. We need to be able to define a default sort in the Template 'Children' tab. I'll add it.

I don't understand?

Thanks guys, I've committed this update.

There are probably a hundred different approaches here. The truth is that unless you go out and buy a system designed specifically for owner online property and booking availability management, it's going to involve a lot of customization and code on your part. So I think that how you approach this in ProcessWire is probably not going to be all that different from how you'd approach it outside of ProcessWire (or in another platform). I think it would also be worth looking at full blown frameworks like CodeIgniter, CakePHP or one of the others too. But if you like the way ProcessWire handles everything else, then I think you'll find it to be a very solid foundation to build such features from. With regard to an owner role for editing: there is no owner role in ProcessWire at present. Though the framework is in place to easily support one (and there used to be one in earlier versions). If you are seeing an owner role in your system, you may want to get the latest version of ProcessWire (2.1) as a lot has changed. But unless your site is very small scale and the owners are a trusted group of peers, I wouldn't suggest setting them up with admin account… you certainly could, but you no longer control the experience. And the experience in PW admin is tailored more towards general site management than a specific purpose like yours. Instead, it's better to give them forms on the front-end where you can tailor the experience to the need and control access. ProcessWire's API is designed for this usage and makes this sort of thing much easier. For instance, you might want to reserve some fields on your property page for you to manage, and others for the user to manage. You could have a page reference field to /processwire/access/users/ that would enable you to select what user(s) had access to change what pages. <?php // $page->owner is a page reference field you have added if($page->owner->id == $user->id) { // user may edit // output a form of just the fields you want them to edit and/or process them } else { // user may not edit } The owner field doesn't necessarily need to be on the active page (like if you don't want to manage this stuff on a page-by-page basis). It could be on some parent. That's up to you to determine what access check works best for you. The way I've accomplished this on other sites is to build a custom Fieldtype for managing rates. Unfortunately it's not code that I can share because I don't have permission to. But Fieldtypes that extend FieldtypeMulti are a great fit for this sort of need. PW supports Fieldtypes with any number of subfields, and in any quantity. This is one of the reasons (of many) why PW uses one table per field, rather than one table per template. Every subfield is automatically searchable by PW's selector engine (though you do want to choose the appropriate indexes in your DB schema to keep your searches fast). For an example, a selector to perform the search you inquired about might look like this: <?php $date_from = strtotime("10/10/2011"); $date_to = strtotime("10/24/2011"); $max_cost = 500; $cottages = $pages->find("rates.available=1, rates.date_from>=$date_from, rates.date_to<=$date_to, rates.cost<=$max_cost"); Of course, you can add in any other fields from your 'cottage' template to search at the same time. As a good starting point, I would suggest looking at the existing FieldtypeMulti types, like FieldtypeComments and FieldtypeFile. These give some insight on how to structure a Fieldtype to carry more complex data types (with any number of subfields) in any quantity. If you are comfortable attempting a custom Fieldtype I'll be happy to help with any questions you have along the way.

It's true there really isn't time for redundant formalities until I can make this a full time job. I was half-kidding about an official changelog, as it's one of those things that version control helps so much with (though it was not optional before things like GitHub). So I like the suggestion to make use of the existing commit logs, and use some standard conventions in there so that it would be easier to parse as a changelog. I'll go with this.

I'm a little confused by the remaining code. It looks like they are using an <iframe> embed (like newer style youtube embeds), so I don't understand why the <object> or <embed> tags are even necessary… they don't need them. Even more interesting is that it looks like they are doing yet another embed with the <script> tag. They have full markup control over your page at that point.

Soma thanks for the kind words and good to hear that your CEO & COO are on board too. Though tell them they should use it for the BIG projects too. Thanks Antti–great ideas. I'd even forgotten that some of this was specific to 2.1. I need to start keeping an official changelog.

Thanks for finding this and for the fix. I've tested it and all seems to work well – committed to the source.

If you console.log the length of the string in the textarea, does it increase/decrease at all in any of those onchange events?

I agree. I think Aloha is being marketed better, but Mercury seems like the better product based on my relatively brief experience with them. Though Aloha's massive size weighs heavily on my impression too.

Sure, I'll be happy to add this. I've added it to my list here: https://github.com/ryancramerdesign/P21/issues/51 So far I haven't come across any characters that need to be translated differently from language to language, but I've been wondering if they are out there. I'm guessing not, considering the relatively small scope of a-z 0-9 ascii. But if so, we will need to move this into a config option as you suggested (though we may do it either way).

If it's possible to create a separate textarea field (with no textformatters) for handling this need, I would suggest doing that. At least, that's what I usually do. Tags like <script> <object> <embed> are kind of like EXE files on a PC in that they are usually legitimate, but can occasionally be malicious. So it's one of those things that I don't like clients pasting into a TinyMCE field because they may not even be able to see that it's there (short of the HTML view, which few know how to use). Using a plain textarea for the specific purpose of handing these tags isn't any better from a security standpoint, but at least it's always done with intention and you always know it's there. As an example, on processwire.com I have a plain textarea called video_embed where I paste in youtube/vimeo embed links. If the page sees the video_embed field is, then it outputs that above the bodycopy. If using a separate field for your object/embed isn't an option, then it should still be possible to make it work with TinyMCE. It seems like your object and param tags are consistent with what's in your valid_elements, so it's not immediately clear to me why those are being stripped. Can you paste in the resulting HTML after it's been stripped? But your embed tag doesn't have any attributes assigned to it, so I can see why that one is getting stripped. If it helps, here is what's in TinyMCE's documentation for valid_elements of these tags: object[classid|width|height|codebase|*],param[name|value|_value],embed[type|width|height|src|*] If that doesn't work, it's also worth trying the object/embed/param from their full XHTML valid_elements set too: http://www.tinymce.com/wiki.php/Configuration:valid_elements

I decided to make the 'forgot password' function optional, and disabled by default. I would say that more than half of all installations simply don't need it. Then there are others that really need it. A good security best practice is to never have any more submittable forms running on your site than you absolutely need. So I figured we'd provide this 'forgot password' function for those that want it, and keep it off for those that don't. I'm not suggesting there are any security concerns with using this function. Only suggesting that every form (especially login/pass-related ones) can be sources of unwanted traffic consuming server resources.

I did a silent soft launch of the PW 2.1 final version on Friday, and changed all the readme files and site copy to reflect v2.1 as the current stable version. So version 2.1 is now officially out as the current/recommended/stable version! I don't yet have the Skyscrapers demo site updated to 2.1 (though it will be the first to use the upgrade script). I also want to get a video done that outlines everything new with 2.1 vs. 2.0. Once those are ready, I figured we would send off a press release to to all the applicable sites and get the momentum going. Beyond the obvious user system updates, template enhancements and ajax uploading, are there any areas that you all think I should cover in the video?

Amazingly these are just the accounts that get through the 1) Captcha image (on most difficult-to-read setting), and 2) email verification. I don't know what the purpose is, but apparently a lot of forums get hit with these same accounts because stopforumspam.com nearly always recognizes them. A large amount of our spam accounts come from China for some reason. I don't think we have any legitimate current ProcessWire users in China (?) right now, but I'm hopeful we'll have lots in the future.