ryan

No UML diagrams at present. I'll use UML when a client project calls for it, but don't personally find it helpful in my own (or others) work unless I don't know the language the code is written in. Too much of a code thinker I guess. Though I'm certainly not opposed to it and it it helps others then I'm sure it'll see a place in the code docs someday. Ultimately, understanding the class structure of PW is not necessary to use the API in full or develop modules for it. PW is really focused on delivering an external interface that doesn't require inside system knowledge. However, if you are interested, understanding the Wire, WireData and WireArray classes gives a solid foundation for understanding how everything in PW works.

The advanced mode is meant for PW system development, so it'll let you do things that aren't reversible in the API. However, advanced mode won't let you start removing permanent/system fields because then you really could break the system in a way that would be difficult to fix, even from the DB. In your case, you've added a system field, which is something different from changing the fieldgroup of a template. I think this will fix it: <?php $name = "name-of-template-you-want-to-fix"; $field = $fields->get("process"); // or substitute name of field you want to remove $fieldgroup = $fieldgroups->get($name); $db->query("DELETE FROM fieldgroups_fields WHERE fieldgroups_id={$fieldgroup->id} AND fields_id={$field->id} LIMIT 1"); With regard to advanced mode, I don't personally use it (or recommend using it) unless you are developing an addon module and need some advanced feature in a template or field that comes with your module. Advanced mode isn't meant for site development. I may need to clarify that more in the docs.

Like you said, the problem is that the database table is lowercase "_end" and the system thinks it's uppercase "_END". The question is where the lowercase version same from. I just tried creating some fieldsets but the tables are all ending up with uppercase _END as they should. Can you think of any other factors that might have resulted in the database table ending up with a lowercase version of the field? Thanks, Ryan

Okay I see what you mean and think that makes sense. Though I still don't want the core taking any actions on this, as I just don't think there's any way for the core to know the developers intentions here. But I have no problem coding options into the MarkupPagerNav module. It does make for a more complex API, but it's also one of those things that's optional so not concerned about adding it. I'm thinking the options should be: MarkupPagerNav::outOfBoundsNone = 0; MarkupPagerNav::outOfBounds404 = 1; MarkupPagerNav::outOfBoundsRedirectFirst = 2; MarkupPagerNav::outOfBoundsRedirectLast = 3; Example: <?php $matches = $pages->find("..."); $pager = $matches->renderPager(array('outOfBounds' => MarkupPagerNav::outOfBounds404)); if(count($matches)) { echo $matches->render(); // or however you want to output echo $pager; // note $pager has to be generated before output since it may send 404 or redirect headers. } else { echo "<p>Sorry no matches</p>"; } Until we have such options, here is how you are supposed to do it now: <?php $matches = $pages->find("..."); if(count($matches)) { echo $matches->render(); // or however you want to output echo $matches->renderPager(); } else { if($input->pageNum > 1) throw new Wire404Exception(); echo "<p>Sorry no matches.</p>"; } Or if you are lazy like me and don't care too much about out of bounds: <?php $matches = $pages->find("..."); echo $matches->render() . $matches->renderPager(); if(!count($matches)) echo "<p>Sorry no matches.</p>";

I got it–understand now. I think that's a good idea, will plan on doing this.

I don't mind adding some more markup or container(s) if it helps with theming. I'm not sure I follow exactly what's needed here, but it should be easy enough for me to add–just let me know where.

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?