ryan

I will look at adding that option. Though this definitely falls into the court of being something I wouldn't ever use on my own sites, and I would question the value of doing it. If it's for maintaining legacy URLs, you are better off using Apache to 301 redirect them away from the legacy URLs. Also, you can always make pages end with .html by making that the page name, i.e. "mypage.html" rather than "mypage", and turning off trailing slashes.

$categoria = $input->post->categoria; $p->parent = $pages->get("/".$categoria."/"); That code snippet above is not safe because $categoria is not validated/sanitized. Someone could really tear up your site using this current code, since you are using that to find the parent. For instance, what if they manipulated the form so that it was '/processwire/' or some prominent page on your site. Since you are using this to save pages, they could then go in and add a million pages to your navigation. I suggest that you do this instead: $valid = array('categoria1', 'categoria2', 'categoria3'); $categoria = $sanitizer->pageName($input->post->categoria); if(!in_array($categoria, $valid)) die('abort'); $p->parent = $pages->get("/$categoria/"); ...and likewise for the other places where you are doing this. Or better yet, only deal with page IDs in your form, rather than page names. That's better because integers are very easy to validate and may be preferable here: $valid = array(10,11,12); $categoria_id = (int) $input->post->categoria; if(!in_array($categoria_id, $valid)) die('abort'); $p->parent = $pages->get($categoria_id); This is also not safe: require_once('functions.php'); The problem with that is that PHP is searching all the include paths for 'functions.php'. It may very well find the wrong one. Instead, you want to ensure it just operates in the current path, so prefix it with a "./": require_once('./functions.php'); I'm also a little concerned about what hidden_path is, and if there any security implications with that, but I just want to reiterate that you should never trust any user-submitted data. Assume that it is tainted. People will eventually exploit these issues. Don't use anything they submit in selectors, in page data, or echo anything back to the screen unless you've sanitized and validated it first. As for why it's generating the error message... I can't immediately tell what the issue is or why you are getting something from comments (there doesn't appear to be any comments code here). It is possibly the include path issue I mentioned above, though I'm not counting on it. Can you paste in the exact error message that you are receiving? Thanks, Ryan

I made the slash configurable by template. If you download the latest commit, you'll see it as a new advanced setting for each template. Adam, I also made the page number prefix configurable now with $config->pageNumUrlPrefix = 'your_prefix'; If not specified, then it defaults to 'page', as before, i.e. 'page1', 'page2', 'page3', ...

If you are wanting to support two different video sizes, I think your best bet is to just create 2 file fields to handle them (or 1 multi-file field, where you always assume the first is the largest/smallest, or something like that). Lets assume you've created 2 file fields, and named them video_hi_mp4 and video_lo_mp4, and you've added these to your template that handles it. Here's how your template code would look: <video controls> <?php if($url = $page->video_hi_mp4->url) { echo "<source src='$url' type='video/mp4; media='(min-device-width: 800px)'>"; } if($url = $page->video_lo_mp4->url) { echo "<source src='$url' type='video/mp4;'>"; } ?> </video> You'd use the same method for your other video formats.

I think we need to get a look at your whole template file. Chances are that your code to look for a form is just checking if there are posted values, rather than checking for posted values from a specific form. If I'm correct about that, you would want to change your form posting code to save only if it detects the name of the submit button. So here is what I'm guessing it looks like now: if($page->editable() && count($input->post)) { // save the form } What'd you want to do is change it to look like this: if($page->editable() && $input->post->submit_form) { // save the form } Replace "submit_form" the the name assigned to your submit button. If it's just "submit", then you may want to change it to something more specific in this case. If this isn't it, please post your template or email it to me and I can get a better look.

I'm not sure why that error was turning up, and am out of time to take an in-depth look, but I was able to fix it easily. And actually I think it's something I should have had in there in the first place (an extra check to make sure that $controller is not null), so thank you for finding it. I have fixed this in the latest commit: https://github.com/ryancramerdesign/ProcessWire/commit/99454cb68b0ccfe287ab82c68c9db7010a6f94be AdminBar is looking great! Would you mind if I tweeted a link to your screencast?

There is. Try this: $total = $page->children("limit=2")->getTotal(); You have to do "limit=2" (or higher) rather than "limit=1" because PW2 doesn't currently count totals on limit=1 selectors. That's just as a matter of efficiency, since all $pages->get() functions use limit=1 internally.

I think it might be better to just override the template rather than putting one in the /templates/ dir (unless you want to encourage them to edit it). I've modified the Template class so that you can change the target filename at runtime, so you'll want to grab the latest commit. https://github.com/ryancramerdesign/ProcessWire/commit/0c8dc7d8e62c9a6a110791e00111c463ff00b01c Next, move that template to the same directory as your module (/site/modules/AdminBar/adminbar.php). Then in your AdminBar.module, add a new "before" page render hook. It will check to see if the page template is "adminbar", and if it is, it'll change the template filename to the one in your /site/modules/AdminBar/ dir. <?php public function beforePageRender($event) { $page = $event->object; if($page->template == 'adminbar') { $page->template->filename = $this->config->paths->AdminBar . "adminbar.php"; } } Also, add this to your init() function in AdminBar.module: $this->addHookBefore('Page::render', $this, 'beforePageRender'); If you do decide you want it to check if the file is in your /site/templates/ first, then just add that check to your beforePageRender method. Now it should work exactly the same as before, except that it'll use the template file in your /site/modules/AdminBar/ dir rather than expecting one to be in /site/templates/.

Apeisa, I tried this out and it works great! Nice work. The site map view is very useful too. Also, I think the code looks good! Here's a few suggestions and notes I've got: The 500 error you got was thrown by ProcessWire. The problem is these lines: return $abFieldGroup->save(); return $abTemplate->save(); All the save functions return a result status, basically true if it was successful, false if not. So to fix the error, you would need to change lines like the above to: $abFieldGroup->save(); return $abFieldGroup; $abTemplate->save(); return $abTemplate; When you are developing in ProcessWire, you may want to enable debug mode, so that errors are echoed to the screen. You can turn this on in /site/config.php. Look for the line that says $config->debug = false; and change it to true. Next, I wanted to mention that the module interface provides install() and uninstall() methods, in case you want them: /** * Perform any installation procedures specific to this module, if needed. * * This method is OPTIONAL * */ public function ___install(); /** * Perform any uninstall procedures specific to this module, if needed. * * This method is OPTIONAL * */ public function ___uninstall(); There may be issues on many installations with your last function, _createAdminBarTemplateFile. The reason is that ProcessWire doesn't usually have write access to the templates dir (it depends on the server). So your installer may be want to look for this, or advise them to copy your template file in there if there isn't write access. Or, we could just make it a blank template (without a file) and then hook into it's render method so that your .module file can render the output instead. Let me know if you want to do that, and I can provide instructions. Lastly, because the site map outputs a full sitemap, it may not scale to large installations. For instance, the site I am working on now has 5k+ pages, and while it renders them all, it takes several seconds. But on large installations, it might just run out of memory too. As a result, I would recommend placing a limit to the number of subpages that the sitemap will display. Maybe a "limit=50" per branch, just to account for the possibility of large sites. And once it reaches that limit, it might have a label that says "Go to the admin to view remaining pages" or something like that. Again nice work on this, I am really enjoying using this module!

I agree with the usefulness of this. The only reason it's not yet implemented is because automatically creating a page is making a lot of assumptions... that's because ProcessWire doesn't have any built-in fields per se. So if we're allowing dynamic adds of pages like that, then it's got to assume that you don't have a bunch of fields on that page that also needs to be populated. But I think as long as we focus on just populating name and title, and people understand they may have to go back and make further edits to any pages they add (depending on the fields) then it'll be okay. This feature won't be particularly difficult to implement. But I'm thinking it'll go best with a auto-completion widget for page selection (which is currently in progress).

I didn't realize that disqus had a REST API. That's cool if it does. I also need to look into those other solutions you mentioned. But regardless of any other solutions, I figure a good built-in comments system is a priority, so I'm going to keep at it. But keep the system so that any other comments systems can be easy to implement too.

I don't know why, I was a little surprised that it flagged them. That's the first time I've seen false positives with Akismet. But I'm guessing you are right about the links.

Thanks for letting me know. I found one of your messages and one of Adam's stuck in the Akismet spam filter (false positives). I identified those as false positives and hopefully they are showing up now. Do you see anything else that is missing? (i.e. you mentioned two of your messages, though I only saw one in the filter).

Does anyone know if there is a screencast or something that demonstrates how this works in EE? I don't currently have access to an EE installation where I can play with it, but am interested in getting a better look at this functionality.

We've got something on the roadmap for providing this alternate view into pages. I think there are a lot of situations where it will be helpful. For instance, seeing a list of the most recently updated pages, regardless of where they are in the site structure. Or viewing all unpublished pages (like you indicated), or viewing all pages that match a given selector, or have a specified field, etc. The list goes on. So just wanted to let you know this is part of the plan. It will be an alternate tab off of the Page List view, where you can choose that channel-type view when it suits your needs better than the map view.

The main reason there isn't an SQLite option right now is because there is no fulltext index type in SQLite. This index type is really important for being able to search text-based fields using selectors. I think we'd be creating headaches for people, having alternate versions of the documentation to support database platforms that don't have this type of index. This is also the main reason why PW2 uses MyISAM rather than InnoDB in MySQL. That's a good question though, and I'm always going to be keeping an eye on ways we can expand the database platform support.

PW2 admin browser support is currently built around recent Webkit and Mozilla browsers (Firefox 3.5+, Chrome 7+, Safari 4+). IE8+ also works just fine, though not running on a PC I haven't spent as much time in that browser... though I consider supporting it always of major importance. I believe the only place where IE8 is a little strange right now is in the TinyMCE image editing functions. It works, but there's some strange overlay issues getting confuse between the windows. Opera support is also on the to-do list. I like the idea of these file upload widgets, and the one you posted seemed to work well when I tested it. I'm particularly interested in an HTML5 widget option where one could drag files into it. But I think the best solution will be to make these options something that the user can select what upload widget they want. For instance, they can use the basic HTML one, or they can choose an alternate via a plugin module, kind of like how they can select "TinyMCE" (and likely others, in the future) with the Textarea fieldtype.

Apeisa, thanks I think that's a great summary and order of things. I agree with everything you've said here. I already have this one partially done and working. I'll be happy to post it before it's done if anyone wants to play with it. I just posted a guide this morning in the forums. At least it's a start for the real documentation. Thanks, Ryan

Regarding the image cleanup. I need to create a "clear image cache" function at some point (perhaps as a button in the FieldtypeImage module configuration). That would just go through and wipe out all the cached images. Since ProcessWire doesn't know which size variations you are actually using, it would have to wipe them all. But of course, any of the ones that were being used would just get re-create automatically the next time the page is viewed. On a big site, this might mean pages take longer to render than usual, but only temporarily.

Sinnut is right. This was a bug! It has been fixed in the latest commit. Thanks Sinnut! https://github.com/ryancramerdesign/ProcessWire/commit/fbb5db8ac46cc94676221a8fe06c058e3ee4e76f

Apeisa's examples are great. You may also sometimes want to pull pages based on their location rather than what template they use. For example, lets say you were on the homepage (or some other page) and wanted to pull the 3 most recent news items from the /company/news/ page. I'm going to assume that the news page is already set to sort it's children by date descending. <?php $latestNews = $pages->get("/company/news/")->children("limit=3"); foreach($latestNews as $item) { echo "<p><a href='{$item->url}'>{$item->title}</a><br />{$item->summary}</a></p>"; }

That's a good question. It is feasible to do this, but I see possible security implications with making this sort of functionality accessible from the front end. When you've got something like this on the front end, you really want to be storing files they add in a non-web accessible location, and you want to make sure they aren't posting hundreds of giant files to fill up your hard drive, and using image resize functions as DDOS entry points, and so on. Lots of implications like that when you consider completely anonymous users. The current file/image tool isn't designed for anonymous/guest users. That's not to say that it's not plenty secure, but that I'm very paranoid about such functions (in any CMS) unless they are specifically designed for guest/anonymous use (like the one included in these forums). Once we have a more thorough users system in place, I think we should make these fieldtypes more accessible outside administrative use.

I wanted to mention that there is something sort of like this. I use it mostly for quick prototyping pages and stuff, but take a look at the Admin > Modules > MarkupPageFields, and click install if it's not already. Then in your template(s), you would do something like this, probably in your main content column: <?php echo $page->renderFields(); ?> That will render all of your fields and values on the page in an HTML definition list. It's a quick way to get a look at all your data in context before you produce your real templates. But I see this as a tool to help with development and prototyping, and not something to use for production sites (though you certainly could if you wanted to).

Here is a quick guide to using the comments system. We start from the simplest usage, and get down into more configuration options further in the post. Making use of the Comments fieldtype 1. Make sure that Comments fieldtype (FieldtypeComments) is installed from the Admin > Modules menu. 2. Now go to Admin > Setup > Fields and create a new field. Select "Comments" as the fieldtype and give it whatever name you wish (I usually call it just "comments", and code snippets here assume it's called that). 3. On the next screen, you'll have several options to configure the comments field. Make sure that you enter a Notification email. This is the email address that gets notified when new comments are submitted. Currently it is the only way you will know when new comments are posted (short of checking the admin page yourself), so using this is important. 4. Now edit the template where you want your comments to appear. Enter this: <?php echo $page->comments->render(); 5. Likewise, in your template, enter this where you want the comments entry form to appear: <?php echo $page->comments->renderForm(); 6. Your comments are now ready to use. Note that any templates that use comments for posting should not use Template caching unless you configure the comments to post to another template/page. You'll see an option for this in the renderForm() options shown further down on this post. Adding the Akismet Spam Filter I highly recommend that you use the Akismet spam filter with your comments. To do so, you'll need an Akismet or Wordpress API key (http://en.wordpress.com/api-keys/). Once you have it, click to Admin > Modules > Akismet (CommentFilterAkismet). Enter your API key in the space provided and Save. Then go to Setup > Fields > and edit the comments field you added. Check the box for "Use Akismet". You'll also see a field that says how many days it will keep spam before deleting it. I usually set this at 1 or 2 days, just in case Akismet identifies something as spam that isn't (though it's yet to happen!). Hit Save, and your comments are now hooked into Akismet. Styling the Comments See the file attached to this message (at the bottom). It is a starting point for styling the comments. It's just pulled from the comments styling at processwire.com, so it should be seen as an optional starting point rather than as a ready-to-go stylesheet. Or, you may prefer to start from scratch on styling the comments, depending on your need. OPTIONAL: Customizing the Comments Output You may want to change some of the basics of the comments output. You can do this by passing arguments to the functions you called above to render the comments list and comments form. Included below are examples with all options. You may specify any one or more of the options -- only specify the ones you want to change: <?php // comments list with all options specified (these are the defaults) echo $page->comments->render(array( 'headline' => '<h3>Comments</h3>', 'commentHeader' => 'Posted by {cite} on {created}', 'dateFormat' => 'm/d/y g:ia', 'encoding' => 'UTF-8', 'admin' => false, // shows unapproved comments if true )); // comments form with all options specified (these are the defaults) echo $page->comments->renderForm(array( 'headline' => "<h3>Post Comment</h3>", 'successMessage' => "<p class='success'>Thank you, your submission has been saved.</p>", 'errorMessage' => "<p class='error'>Your submission was not saved due to one or more errors. Please check that you have completed all fields before submitting again.</p>", 'processInput' => true, 'encoding' => 'UTF-8', 'attrs' => array( 'id' => 'CommentForm', 'action' => './', 'method' => 'post', 'class' => '', 'rows' => 5, 'cols' => 50, ), 'labels' => array( 'cite' => 'Your Name', 'email' => 'Your E-Mail', 'text' => 'Comments', 'submit' => 'Submit', ), // the name of a field that must be set (and have any non-blank value), typically set in Javascript to keep out spammers // to use it, YOU must set this with a <input hidden> field from your own javascript, somewhere in the form 'requireSecurityField' => '', // not used by default )); Lets say that you just wanted to change the headlines for the comments list and comments form. You'd do this: <?php echo $page->comments->render(array( 'headline' => '<h2>Read Comments</h2>', )); echo $page->comments->renderForm(array( 'headline' => '<h2>Join The Discussion</h2>', )); OPTIONAL: Generating your own output If you wanted to generate your own output (rather than use the built in render() methods), you can iterate the $page->comments field: <?php foreach($page->comments as $comment) { if($comment->status < 1) continue; // skip unapproved or spam comments $cite = htmlentities($comment->cite); // make sure output is entity encoded $text = htmlentities($comment->text); $date = date('m/d/y g:ia', $comment->created); // format the date echo "<p><strong>Posted by $cite on $date</strong><br />$text</p>"; } You can likewise do the same for the comment form. But I don't want to get too far into this level yet since this is supposed to be a quick guide. Whats on the Comments roadmap? In my mind the biggest missing part is a central place to manage all your comments. Currently you manage them on a page-by-page basis, consistent with where the comment was posted. This is fine for simple uses, but becomes more challenging on larger sites, where you have to rely upon the notification emails to let you know where comments are posted. I would like to expand this so that comments can optionally be managed in a central place. In addition, I would like to make them as easily API accessible as pages. The comments are also not hooked into the user system. Every time you post, you are essentially posting as a guest. While the comments fieldtype will recognize your email address if you have posted an approved comment before, I would like to make it recognize the user system, and also recognize other user systems (like Twitter, Facebook and Gravatar). There is more needed too, like comments pagination and support for basic markup (comments can only contain text at present). If your needs are relatively simple, the Comments fieldtype is a good way to go. If your needs are more advanced, systems like Disqus and Intense Debate are excellent options to consider. The only issue I would have with those options is that they are javascript-based by default, so comments don't become part of your site's indexable content (to search engines like Google). comments.css.zip

Great! Glad that worked. Like I say it's just a start, but a good proof of concept hopefully.