ryan

Are you sure this is from FieldtypeComments? That module doesn't override the formatValue() function. Also the comments on that function refer to renderMapMarkup? This is different than how formatValue is meant to be used, but it is still okay. But there is a major component missing, and that is how the value goes from user input into your fieldtype? Fieldtypes aren't meant to handle user input (Inputfields are), so we have to come up with another way to get front-end user input into here. Before we go further, I just mention how FieldtypeComments works: It has no formatValue() function because it doesn't need one. formatValue is an optional method to convert a runtime value into one ready for presentation on the site... the best example is taking a string of text and encoding the entities in it (i.e. '&' becomes '&'). FieldtypeComments doesn't need a formatValue() function because its wakeupValue() returns an object (of type CommentArray). That CommentArray has some built in helper methods that you can use on your site to render comments or render the form for them. So here's how you render comments: echo $page->comments->render(); And the form for inputting comments is rendered like this: echo $page->comments->renderForm(); That renderForm() method actually loads up another class called CommentForm(), and that class is looking for posted comments. This is different from other Fieldtypes because it's something designed to accept input from the frontend rather than the admin. Admin input is handled with Inputfields. So in your case, you are trying to achieve the same result at FieldtypeComments. I think it may be okay to let your formatValue() function take this role. But your formatValue function will need to detect when a up/down has been submitted, in addition to outputting the form that it is now. At least for now, I would suggest making your Fieldtype a regular Fieldtype and not a FieldtypeMulti. I don't think a FieldtypeMulti isn't necessary here and might even make it more difficult to implement. Instead, I would use a schema that increments a single counter for every up vote. Probably the same schema as FieldtypeInteger. If you wanted to maintain separate up and down counters, then you would expand your Fieldtype schema to have two counters. But I would suggest just starting with one to get things going, and then expand. Likewise, if you determine you need a FieldtypeMulti, than no problem, but since that evolves from a regular Fieldtype, it's good to understand the workings of a regular Fieldtype first. Assuming the stuff in the paragraph above, your formatValue would do something like this: <?php public function formatValue(Page $page, Field $field, $value) { if($input->post->vote) { // a vote was submitted // turns off outputFormatting so we can save a raw value $page->setOutputFormatting(false); // now increment and save the value $name = $field->name; $value++; // increment the counter $page->set($name, $value); $page->save($name); // turn outputFormatting back on, so we're leaving everything as it was $page->setOutputFormatting(true); $out = "<p>Thank you for voting. Current votes: $value</p>"; } else { // no vote submitted, display the form $out = "<form action='./' method='post'>" . "<p>Current votes: $value</p>" . "<p><input type='submit' name='vote' value='Vote' /></p>" . "</form>"; } return $out; } Note that there is no security or validation to ensure the user doesn't double vote or hasn't already voted for that page, etc. So it's just for demonstration purposes, but I think gets across the part I was talking about: something to identify the vote submission and save the vote.

Trash is tricky because if a page inherits it's access, then that association is lost once moved to the trash. The trash is undefined in terms of access control–a no-mans land. Some pages in there may be using templates with access settings and some not. It becomes a can of worms if we let non superusers in there. We'll find a way around it down the road, but in the short term I think it's safest to lock that part down to superusers. Others experience may be different, but I've only ever had a client delete something they weren't supposed to just once, and that's over several years. But that may also be because a lot of the sites I deal with rarely need stuff to be deleted, so it doesn't come up often.

Here's another way you could do it too. Though I'd probably use Soma's more straightforward approach unless you are dealing with a large quantity of categories. The reason for that is that this approach (below) is technically a little faster since it's one samples query to cover all categories rather than one samples query per category. But I think Soma's method is easier to follow with more straightforward logic. <?php $cats = $pages->find("parent=/categories/"); $samples = $pages->find("parent=/music-samples/, category=$cats, sort=category.name, sort=name"); $last = null; foreach($samples as $s) { if($s->category !== $last) { if($last) echo "</ul>"; echo "<h2>{$s->category->title}</h2><ul>"; } echo "<li>{$s->title}</li>"; $last = $s->category; } echo "</ul>";

Usually you'd handle this with two roles. One role that has page-edit and page-delete permissions to be assigned to the template used by the child pages. And another role that has page-edit and page-add permissions, to be assigned to the parent's template. By "assigned" I mean, check the box for it to be "editable" to each of those roles in the template's access tab. Then you'd give the user both of those roles. But I realized after trying it myself that it wasn't quite working as intended. I committed an update to the dev branch so that it should work now. Btw, your client won't be able to actually delete anything either way. The definition of "delete" to non-superuser roles is just to move to the trash. So if you don't want to move to the PW 2.2 dev branch just yet, at least take comfort that if your client happens to delete something you don't want them to, you can always go back and undelete it.

Linebreaks are now supported in the field descriptions (dev branch). It just runs the description text through PHP's nl2br() before outputting it. While I was there, I also made it so that you can use markdown style links in field descriptions as well. i.e. [ProcessWire](http://processwire.com)

The speed of the animations seems alright here, but I think it's going to depend on what computer and browser one is using. I'm generally indifferent about animations too. They seem nice here, but I'm not experiencing a slowdown either. If they are slow for lots of people, maybe better to get rid of them or whatever Soma thinks is best. Animation or not, I just really like the functionality of being able to expand one section like this, as well as the "+" sign to do it. While I think visually it might fit nicely in the top and make closing easier, I also think it would be easier to miss at first glance. I like it at the end because it's very clear about what that "+" is for. If it were at the top of each section, people might think that it means "make sticky" or "open in new window" or something like that. Whereas at the end of the list, the placement context becomes part of the message – its hard to confuse it with anything other than "show more". But ultimately I love the functionality of it regardless of where it's placed.

Thanks for all of your feedback. Great ideas Maruchan! Based on our conversation here, I'm now feeling that perhaps we should test the waters first with a ready-to-go site profile. I'm going to do more thinking here over the holidays and try to identify some areas of need that might be good to pursue.

Nice work statestreet! Great site. I'm using some script in Firefox that makes me enable JS on a site-by-site basis, so when I first arrived the site thought JS was off. It told me: "You need Javascript to view this site. At least it's not Flash, right?" – got a good laugh out of that.

Evan, I'm not sure we can tell much from the code snippet you posted. Because a Fieldtype is a system with various components involved, I think we might need to see the broader context here (full Fieldtype and Inputfield).

The typing of "images" in a <p> was just an example of using a little template file code to automate some specific runtime output. It's not a standard or even a recommendation, just a little code snippet I found handy in a couple cases. Unless I've misunderstood, now you are asking for exactly what the built-in functionality does– Click on the photo icon in TinyMCE and add a photo. If you then want to link it to something, then click on the photo to highlight it and then click on the link icon to select what you want it to link to.

Thanks for all of your feedback on these. Glad that you find them to be pretty good. I know Jim spent a lot of time on them. But I don't think he'll ever get back to them because I think they are keeping him super busy at his new job. Since it sounds like they are going in the right direction, we'll keep updating and adding to these. If anyone is interested in working on them just let me know. One of the main things about these is that they were written a year ago, back when PW was brand new and before version 2.1. The other thing is that you'll see some of the Quick Start tutorials in there are just notes he had made to himself– some aren't finished and some aren't started. So one of the things we need to do is determine if the unfinished ones should be deleted or finished. Thanks, that would be great if you have time to take a look. If you find anything that you don't think is right, feel free to change it too. Thanks, Ryan

I hadn't really considered this particular Fieldtype as one that would be used for searching, so that's something we may need to upgrade in FieldtypeModule. However, I think that this should work right now: <?php $id = wire('modules')->getModuleID('SettingItem'); $this->pages->get("template=admin, process=$id, name=completed");

I'd forgotten those tutorials were there. The only way to get to them is through the search engine (I think). These were written by my brother-in-law back when PW 2.0 was new (nearly a year ago). He never was able to finish them because he got a new job that takes all his time. These tutorials may not be totally applicable anymore (I haven't read them all yet). But I'd be interested to hear if you guys think they are helpful and if we should update and finish them. Now that they've turned up again, I'm going to read through them in more detail here.

Here's how to do it: $page->addStatus(Page::statusUnpublished); Note that $page->status is a bitmask, so it can contain several different statuses at once (for instance, hidden and unpublished). It can be set directly. But because bitwise arithmetic isn't always fresh on my mind, I think it's safer and easier to use $page->addStatus() and $page->removeStatus() for dealing with it.

This was actually in early versions of 2.1 as the page-add permission (and it's probably still there just commented out). I took it out because I was worried about providing too many options and resulting confusion with so much crossover between that and the family settings. I like having lots of choices, but access control is one area where I think it's better to just have one way of achieving something. Though I do think we could add page-add permission back as an option, but something we'd probably want to do with an optional module. I understand what you mean. The action you described is also the way family options are supposed to be used. Set things up where you need them, an then lock it down the way you want it. It's meant to be something to direct the flow after you've set the structure and determined who can edit, not at the same time. If everything is working and you are happy then I wouldn't suggest changing it. There's nothing inherently good or bad about having lots of templates–it's generally adds more flexibility, but with the tradeoff of being more to manage. But if you want me to take a look and suggest ways you can do it with fewer templates, I'll be glad to. Though you may be right that you have exactly as many templates as you need too– I'm not familiar with the site or scope of it so can't speak to it.

Thanks Pete, this looks great.

I agree with all this. Here are the curent module naming conventions (first word in module name): Export - any module that provides site data export capabilities, especially where there may be a related Import module. Fieldtype - any module that extends the 'Fieldtype' class. Represents a data type used by ProcessWire fields. Form - any module that deals with creating/processing web forms (some crossover potential with Markup). Inputfield - any module that extends the 'Inputfield' class. Represents an HTML input widget used to collect data in the admin. Import - any module that imports data to create new data in a PW site. Jquery - any module that adds something related to jQuery/Javascript. Language - any module that provides support for other languages Process - any module that extends the 'Process' class. Typically attached to a page for handling admin actions. If it's related to another Process module (core or 3rd party) it's name should start with that module, i.e. ProcessPageEditLink is related to ProcessPageEdit. Markup - any module designed for creating or parsing markup Page - any module designed to add capabilities to PW's Page class. Textformatter - any module that extends the 'Textformatter' class, for runtime output formatting of text fields. Some of the naming conventions are based on the root class that they extend, though not all. New additions to this list likely won't be based on extending some built-in class, since there aren't any others. Though I would suggest that when a module doesn't fit in the above, it should start with the class name of the core class or module it is hooking into (not unlike the 'Page' one above). So if you are adding hooks to the Pages class, then start your module with 'Pages'. Likewise if you are adding hooks to the Session class, then start your module with 'Session'. Beyond this, the naming conventions are open ended. I guess the first thing we have to determine is: what are the major classes of modules that aren't covered above? I can't think of any at the moment, but I know they are there.

We'll let this one marinate for awhile and see if new posts separate from this one turn up where people think it's a bug. It'll be on probation.

I like MarkItUp. Actually I used that in PW1 as an option in addition to TinyMCE. Would be good to bring back at some point.

Thanks for the update Jasper. Looks like we've got a double encoding issue there–thanks for pointing this out, I'll implement a fix. For security, I have everything coming out of the translator as pre-encoded – prevents those JSON files from ever being used for anything malicious. But there are some instances (like that breadcrumb) that may be doing their own encoding (resulting in double encoding). Please let me know if you come across any others. Thanks, Ryan

Okay glad you guys like it. But if anyone thinks it looks like a mistake, then it may need more tweaks. And as always please be honest.

Soma, just wanted to let you know I haven't forgotten this, but wanted to reply when I had time to put some more thought into it (early next week). If you want to send over the access that'd be great too.

I agree, we'll get there. This needs to accompany the larger module documentation, something that I'm hoping to get in place shortly after the 2.2 release.

I agree, though also think it's a delicate balance. I'd like people to perceive ProcessWire as something like Google (in terms of simplicity) – they can start using it without really having to know anything. They can discover the depth of it as their needs grow. If the depth is out in front, they might be overwhelmed. So I like to keep lots of surface simplicity and let PW grow with them. Most of what you use PHP for in a template is no different than how you would use some other template engine, except in syntax. So something like: <p>$somevar</p> is probably not a good example because there is no logic there, it's just pure output generation. You have to connect your variable to the markup at some point, and it doesn't get any simpler than that. I do think the point is valid when you get down into code that isn't geared towards output generation. But the nature of PW's API is that all the data is put at your fingertips so your template code can focus on output generation. The logic (or lack of it) that one uses in PHP at this level isn't really any different than that provided by something like Smarty, EE or another template engine. What is different is that PW puts all of the site's data at close reach, rather than some specific subset of it. That kind of resembles working in Javascript with the DOM. As you start working at a larger scale, using some discipline in how you do things can help you in the long run. I'm not talking so much about whether something is in a <p> or <li> tag, but about stuff that would create major obstacles if you wanted to completely re-skin your site tomorrow. An example of something that does go beyond output generation a little is a search engine. This is one of the reasons why I like the approaches we've been talking about, because it does a good job of isolating logic where it matters. This particular example doesn't have any real logic of the sort I'm thinking of, but pretend for a moment that it was a much bigger/more complex search engine: search.php <?php $q = $sanitizer->selectorValue($input->post->q); $results = $pages->find("title|body|sidebar*=$q"); $page->body .= $results->render(); include("./main.php"); Or using something like your guys method, where a separate view file generates output separately: search.php <?php $q = $sanitizer->selectorValue($input->post->q); $page->searchResults = $pages->find("title|body|sidebar*=$q"); /* then the output file /includes/search.inc knows to output results from $page->searchResults */ include("./main.php"); Another thing I've found that works well is to put reusable output generation in modules and attach it to PageArrays, not unlike $results->render(). For example, on those villa sites, I have a PageArray::renderVillas hook that can be called anywhere in the site and it always renders villas the same way, provides a sort select at the top, and knows to handle pagination. Likewise, I added a Pages::villas() hook that only finds villas and automatically plugins in the proper limit=n for consistent site-wide pagination. So if I needed to re-skin the site tomorrow, I could update all the site's villa lists in one shot (and there are hundreds of them). As time goes on, I think it'll be good for us to document best practices for large scale use. Like with PHP itself, I'm glad PW doesn't force us into one way of doing things. But I think it'll be helpful to lots of others if we outline what we've found helps to maximize scalability, longevity, etc. At the same time, when it comes to teaching people how to use ProcessWire with examples, I think some of these best practices can confuse the message. I wouldn't suggest that someone learning ProcessWire should use it in pure MVC mode until that is appropriate for their scale and need. It's only when you go bigger and more complex that your template code starts to become something more than a 'view', and it's at that point where you need to start considering the long term. I think this is only worthwhile if you are dealing with some other group of people that is creating the output files, and that group refuses to get anywhere near PHP. Ultimately they just need to be told that there's no difference between <?=$somevar?> and {{$somevar}} except for a lot of unnecessary overhead for the {{$somevar}} version. More here: http://processwire.com/api/why-php-syntax/ It would be easy possible within PW to create markup-generating type of modules. Not sure If that should be done, as It's a little against PW's philosophie. Markup generating modules are fine I think, but I just don't want PW's core to generate any markup. I figure it should always be markup neutral. But markup generating modules can be very handy. Though my preference is for markup generating modules to provide options for customizing that markup. Me too. Though when providing these as something beyond a basic example, I think it invites an audience that is interested in turn-key solutions and not web development. Such things require good support. Thats why I think there is a good fit for paid solutions in this (like Maruchan brought up).

Here are the fields you can set with a Page field: <?php $f = $fields->get("some_page_field"); // InputfieldPage settings $f->parent_id = 123; // ID of allowed parent page $f->template_id = 4; // ID of allowed template $f->findPagesCode = 'return $page->parent->children();'; // alternate code to use for included pages $f->labelFieldName = 'title'; // name of field to use as label (default is title) $f->inputfield = 'InputfieldSelect'; // class name of inputfield you want to delegate selection to // FieldtypePage settings $f->derefAsPage = FieldtypePage::derefAsPageArray; // Multiple pages (PageArray) $f->derefAsPage = FieldtypePage::derefAsPageOrFalse; // Single page (Page) or boolean false when none selected $f->derefAsPage = FieldtypePage::derefAsPageOrNullPage; // Single page (Page) or empty page (NullPage) when non selected The Inputfield settings only affect what is displayed in the admin (i.e. for locating what pages it should display as selectable).