ryan

For me the biggest problem with no trailing slash is that the relative linking strategy isn't logical in a tree structure. No trailing slash is fine for bucket-based, non-hierarchal systems, but is problematic in a tree structure. Compare these relative linking strategies. When there is no trailing slash, you are always in the context of the parent rather than the current page: No trailing slash: <a href="./">Link to parent</a> <a href="this-page-name/child-page-name">Link to child</a> With trailing slash: <a href="../">Link to parent</a> <a href="child-page-name/">Link to child</a>

Not sure that I understand where it would return to. Can you provide more detail? Textformatter modules happen behind the scenes and manipulate the text directly, rather than returning anything. That's why I'm not sure I understand the question. ---Edit: Thinking more, it does have the video ID at one point in the module, so you could modify the module to make it insert thumbnails as part of the text formatting it does. This is probably the way I would approach it at least.

Not at present, but I do plan to add a 'website' field in 2.3, which is coming very soon.

This is where it's usually set: /site/config.php - most of these options are meant for system/core development (some not that safe for everyday), so remember to turn it back off when done. For the most part I prefer to extend Page via autoload modules or delegation rather than by inheritance, but the pageClass option is there when you need to enforce a type derived from Page. Examples are User, Role, Permission types.

It should all be in /wire/modules/Process/ProcessPageAdd/ProcessPageAdd.module

Ah you beat me to it. I'm on a cell phone, about to cook dinner so have to come back a bit later. But sounds like we're thinking the same thing here

Okay, I must be confusing with a PW1 behavior, which I still do when I don't have the code in front of me. But I can say it's definitely feasible. Probably need to assign a random name on first save, before changing it to id since id wouldn't be known prior to save. Name is a unique key (when combined with parent id) so don't think it can be undefined.

I think it'd be feasible to make such an option available. I'm not at a place where I can check the code, but I think this may be how we have the API set (default to the 'id' as name when no name set). So it'll most likely be fairly simple front-end stuff to make it support that. I'll experiment on the dev branch here to see what we could implement.

ProcessWire considers the 'name' a very important component of a page (perhaps the most important). This is what people see in the URL and how the page is represented to the outside world. The reason you have to create a page before you start populating it is because we don't really know what fields we'll be dealing with in the page editor. Some fieldtypes require that a page has a dedicated place to store files, especially with ajax uploads, for instance. Some fieldtypes like repeaters need to know the page's ID. We want to keep things predictable for Fieldtype/Inputfield module developers, so want to make sure they've got a tangible page to work with. The page "name" is all that we really need to know in order to create a page. A page's name (and thereby URL) play a big role in ProcessWire. It's the primary means of a page's identification, as well as source of the path/URL. In order to ensure uniqueness in any path, the 'name' (under a given parent) is enforced as unique at the DB schema level. For all these reasons, you have to choose a name to create a page, and it's supposed to be a good thing. This is a different approach than I've seen before, but can't think of any reason why it wouldn't work. However, I do think life might be simpler just to re-purpose it since PW lets you change field context by template. If you are building a company directory, and don't want to have a "full name" field, something like "job title" might be a good one (it even has the word 'title' in it).

Man you guys are fast, you beat me to it. Anyway, I think having a global "title" field is a good idea, just from the standpoint of having something that is consistent on all your pages. This greatly simplifies your job when creating something like a site-wide search engine, for instance. I also like my "title" field to play the role of the HTML <title> tag. For the same reason, I often have a global "summary" field that is also useful when creating site-wide search engines, and meta descriptions.

While you can un-global that title field (which I don't think I've personally done), I think it's not a bad idea to keep it around as a standard when possible. I've setup things like you are talking about before (company directory), and I'll usually re-purpose the title field on the "person" template to contain the "full name" or "last name". You can change the labels for the fields so that it identifies itself as something else by changing the field context in the template editor. You might also want to make use of the template "family" settings to define that when adding a page to say /company-directory/ it will only accept children using your "person" template. That way you aren't selecting a template when adding a page there.

I agree I think this does seem like a nice optimization, as you can perform an action on a page separately from having to open its children, so this ultimately saves time/resources. However, I also agree with Netcarver about the issue with hovering in the whitespace, though experimented a bit and not really sure how to solve this.

For the most part, I usually prefer more functions to more arguments. This is one reason why I've never been too happy with that second $alwaysArray argument to the current getRandom() function. I should have had just getRandom() that always returns 1, and findRandom() that always returns a WireArray/PageArray. So while it could be added to getRandom(); I think the value of it might be easy for people to miss, because it'd be a 3rd argument. So here's what I did instead: https://github.com/r...329a491e9d77b0a See the new functions added: findRandom() and findRandomTimed(). Adding the findRandom() function helps to get the API clarity it was missing before, and gives findRandomTimed() more context. Of course, getRandom() will still return more than 1 if you tell it to, as I wouldn't want to break compatibility. But if I could go back in time, I would make getRandom() always return 1 and have no arguments.

Are there any other textformatters enabled on this 'body' field? Where was it copied/pasted from? If you copy and paste something that is an HTML link from one window and paste it into a TinyMCE field, then the link will be retained. It's possible that IE7 inserts the <a> tag around an URL copied from its address bar? If that's the case, she could either click the 'remove link' icon after pasting it on, or paste the link into Notepad, and then copy it out of there before pasting into TinyMCE (which should render it plain text).

One thing we could do is make the field creation step be directly on the fields list page, like in Form Builder. I think this would be a nice optimization and would be pretty simple to do.

The iframe embed method is optional with Form Builder. But if you want to add a form to your site in the simplest/fastest way, then it's the best way to go. However, many still use embed option C, which outputs the form markup directly on your page without any iframe and leaves you in full control of how you want the markup to be styled (whether using Form Builder's stylesheets or your own). Personally, I only use embed option C if I'm creating a one-off form that needs to be styled to a particular page, unique from others on a site, like this one. The page is required by Form Builder, but you can move it somewhere else if you want to. It doesn't have to be at the root level, but it should remain publicly accessible.

Great tutorial Soma! This is the best summary of using PW's Inputfields that I've seen. I noticed you did $field->attr('id+name', 'email') so just wanted to explain what that is for those that may be unsure of the syntax. That syntax is basically saying to set the 'id' and 'name' attribute to have the 'email'. While every field needs a 'name' attribute (like in HTML) the 'id' attribute is optional… if you don't assign an id attribute, PW will make one up. If you intend to custom style a field with CSS or target it from javascript, then it's best to assign your own 'id' attribute. Otherwise, it doesn't matter. // this… $field->attr('id+name', 'email'); // …is the same as: $field->attr('id', 'email'); $field->attr('name', 'email'); // …as is this (direct reference): $field->id = 'email'; $field->name = 'email'; The advantage of using the attr() function over direct reference is that attr() can't ever collide with other Inputfield properties that might have the same name as a field attribute. It's basically your way of saying "this should definitely be an HTML attribute and not anything else." For recognized attributes like 'name' or 'value' it doesn't matter what syntax you use because an Inputfield already knows 'name' and 'value' are standard HTML attributes. But if you needed to add a custom attribute like "data-something", well then you'd definitely want to use the attr() method of setting. That attr() method should only be used for things that would actually be HTML attributes of the <input>, because they will literally end up there. So if you do an $field->attr('label', 'Hello'); you'll end up with an <input label='Hello'> in the markup, which is obviously not something that you want. That's why you assign a non-attribute property like 'label' or 'description' directly, like: $field->label = 'Something'; Last note about $attr() is that it can be used for both setting and getting attributes: $field->attr('value', 'something'); echo "The field's value is: " . $field->attr('value'); // same as: $field->value = 'something'; echo "The field's value is $field->value"; To extend your example, lets say that you wanted the 'email' and 'password' fields in a fieldset titled "About You". You would create the fieldset, and then add/append the fields to the $fieldset rather than the $form. Then you'd add the $fieldset to the $form: $fieldset = $modules->get('InputfieldFieldset'); $fieldset->label = 'About You'; $field = $modules->get("InputfieldEmail"); $field->label = "E-Mail"; $field->attr('id+name','email'); $field->required = 1; $fieldset->append($field); // append the field $field = $modules->get("InputfieldPassword"); $field->label = "Password"; $field->attr("id+name","pass"); $field->required = 1; $fieldset->append($field); $form->append($fieldset); Or lets say that you wanted those 'email' and 'password' fields to be each in their own column so that are next to each other horizontally rather than vertically. You would assign the 'columnWidth' property to both the email and password fields. In this case, we'd give them both a value of 50 to say that we want them to be a 50% width column: $field->columnWidth = 50; To jump out of tutorial mode and into idea mode: lately I've been thinking that PW should have a YAML to Inputfields conversion tool in the core (something that would be pretty easy to build), so that one could define a form like this: And create it like this (where $yaml is the string above above): $form = $modules->get('InputfieldForm'); $form->load($yaml); echo $form->render();

To make it even shorter, you can also do this (specify path to category): $posts = $pages->find("parent=/posts/, category=/category/events/"); Or this (specify title of category): $posts = $pages->find("parent=/posts/, category.title=Events"); To take it further, you could replace "title" above with any field present on the category template and match based on that. But I think 'title' or 'name' are probably the most common ones. If your 'category' field only exists on your posts, then technically, you could leave out the "parent=" part. Though a more specific selector tends to scale better than a less specific one (like if you re-use your category field in another template). So I do think it's worthwhile to keep it, or use $pages->get('/posts/')->children('...') like in your example. In PW 2.3 (dev branch), you can now do this as well, which would be the shortest possible alternative: $posts = $pages->find("category=events"); The above is matching the page's name field. Since there is no slash in the value "events", it assumes you are talking about the page's name rather than path or ID.

This is the most likely case. My memory has never been great... I'm almost as old as VI itself, heh. But I'm looking forward to giving this debug combo a try.

This has been kept as a per-template setting. I opted not to make it a system wide setting because I thought it would create some support burden and make it more difficult for people to use. Every time we post an example that includes some kind of link, we'd have to qualify it with "depending on your slashes setting". I recommend sticking to slashes with your pages (defined pages) and optionally omitting slashes with non-defined pages: URL segments or page numbers. Another thing to mention is that Process modules actually require use of trailing slashes for defined pages, so don't disable trailing slashes on your 'admin' template.

How about: $page->images->removeAll(); $page->save();

I didn't realize you were a VIM user too. That makes at least two of us here. I need to get setup with this debugger plugin too.

Thanks for getting Form Builder! You should have access to the Form Builder support board now. It doesn't actually create pages for each form, as they are all handled via URL segments. I'm not aware of any major downsides to using embed method A or B, and there are whole lot of upsides. I much prefer these iframe based embed methods because it makes the forms bulletproof -- they are fully isolated and immune to any unwanted effects from other stylesheets or scripts. The only [minor] downside I can think of is that if someone uses it without javascript, they will either see some extra whitespace at the bottom of the form, or have to use a scroll bar, depending on the form length.

Like you found, that function only operates on one comments field. But you can search multiple comments field using the PW 2.3 dev branch with this syntax, where a, b, c are the names of different comments fields: $pages->find("a|b|c%=some text"); This isn't supported in the current 2.2.9 stable branch. But you could always take the wire/modules/FieldtypeComments/* files from the 2.3 dev branch, to avoid moving the whole system to it yet.

"git clone" takes about 3 seconds from the GitHub to whatever server I install it to. No idea how it can be that fast, but it always amazes me. Doing an rsync from my localhost to a web server usually takes 20 seconds or so. And that's with all the files (not an archive). With regular old FTP, I have seen it take a long time, but it was always due to a slow FTP client or host.