ryan

Alan, you don't necessarily need to use PW's MarkupPagerNav module if all you need are next/prev links. Here's how you might do it instead with your own code: $limit = 5; $items = $page->children("limit=$limit"); $prev = $input->pageNum > 1? $input->pageNum-1 : 0; $next = $items->getStart() + $limit < $items->getTotal() ? $input->pageNum+1 : 0; if($prev) echo "<a href='{$page->url}page{$prev}'>Prev</a> "; if($next) echo "<a href='{$page->url}page{$next}'>Next</a> "; If you prefer to use the MarkupPagerNav module instead, then you could always just hide the numbered links with CSS: ul.MarkupPagerNav li { /* hide all the links */ display: none; } ul.MarkupPagerNav li.MarkupPagerNavNext, ul.MarkupPagerNav li.MarkupPagerNavPrevious { /* display just the next/prev items */ display: inline; }

Just to give more explanation behind it, the "a" class is meant to count from the beginning, so "a1" means first item, "a2" means second item, etc., while the "z" class is meant to count from the end so "z1" means last item, "z2" means second to last, etc. It could just as easily be called "from-the-beginning-1" or "from-the-end-1", but just wanted to make sure my extra short class names weren't causing confusion. The purpose of going this route was to keep comparisons to numbers rather than objects. We know that the first item is always going to have a key of 0, and the last item is going to have the key of $page->numChildren-1. So we don't really need to call first() or last(), though there's no harm in it either. The only other real difference here from earlier examples is just that I'm not using the getItemKey() method. It's not necessary to do that because anytime you call foreach() in PHP you have the option of including the $key in the foreach. As a result, this: foreach($page->children as $key => $item) { is the same as this: foreach($page->children as $item) { $key = $item->getItemKey();

Looking good Diogo! The way to identify if something is an image is like this: $image = $page->get("image_field_name"); if($image instanceof Pageimages) { // WireArray of multiple images } else if($image instanceof Pageimage) { // a single Image }

Of course, I'll make it work for Textile before Markdown.

Nice job with the responsiveness too... quite a fun one to drag the window size.

I don't think there's any way for us to tell why $wire isn't working without seeing the code context where it's not working. I have a feeling he's trying to use $wire from within a function or class, and it's out of scope. But I would suggest using the wire() function either way, as that's going to be more portable in most use cases.

Nico, thank you for the update. I have a couple suggestions. First would be to use a more unique fieldname for the 'id' so that this module isn't running every time there is an 'id' field in $_POST. That's used by plenty of things other than page editing, so potential for this module running when it shouldn't. An example would be 'ProcessPreviewID'. So here's how you would add your hook in the init() method: if(isset($_POST['ProcessPreviewID'])) $this->addHook('ProcessPageView::execute', $this, 'changeView'); Now when your changeView function executes, you know there's little chance it's not getting involved when it shouldn't. I also recommend modifying your changeView() function to sanitize the ID and validate that the page is editable, for security. Here's how I rewrote your function (though have not tested): public function changeView(HookEvent $event) { $page = $this->pages->get((int) $_POST['ProcessPreviewID']); if(!$page->editable()) return; foreach($_POST as $key => $value) { if($page->fields->has($key)) $page->setFieldValue($key, $value); } $page->status = Page::statusOn; $event->return = $page->render(); }

This is one of those things that has to do with the inner-workings of PHP's session system. I've not attempted to override PHP's session storage mechanisms with PW (other than where it places the files) so this is probably a question for Rasmus Lerdorf. But I believe they are just placeholder files to track an active session, and they won't contain any significant data in them unless you specifically set it to the $session var. In lieu of tracking data, the filename itself is likely of more importance since it relates the session ID from the user's cookie to the session ID on the server. Of course, once we provide the option of DB session storage, we will be taking over more control from PHP in this area... at least when DB session storage is selected.

You can also do this in newer versions of PW: $newpage->template = 'upload'; $newpage->parent = '/uploader-test/'; I suggest sanitizing the title, and excluding the name (since PW will autogen it from the title). So the above code would be replaced with this: $newpage->title = $sanitizer->text($input->post->title); Here is the current PW implementation for uploaded files. Perhaps there is a way we can populate this to $input->files, but currently I think it's best to be more specific when it comes to file uploads since there are added dangers and overhead. The WireUpload class does make things simpler and more secure. It also provides options for handling known quantities, filename sanitization, overwriting vs. making unique filenames, processing ZIP files, handling ajax uploads, etc. The full class is in /wire/core/WireUpload.php

The example you mentioned "title|headline=value" is a valid selector in PW. http://processwire.com/api/selectors/ I've not tried this particular combination before, but am thinking you may be looking for something like this: "confirmed|owner=1|$user". $items = $pages->find("confirmed|owner=1|$user"); That's assuming that "confirmed" is a checkbox field, and "owner" is a page reference field that you've defined as the owner user you mentioned. For comparison, here's how you might do it with two find()s, which I find a little easier to read: $items = $pages->find("confirmed=1")->import($pages->find("owner=$user"));

Using getItemKey isn't really necessary since you can already get that from the foreach(). I think that CSS is where all this really belongs, but if needed to support legacy browsers without using the ":" options in CSS, here's another approach... I'm writing in the browser without testing, so forgive me if this needs adjustment. foreach($page->children as $key => $item) { $class = 'a' . ($key+1) . ' z' . ($page->numChildren - $key) . ' ' . ($key % 2 ? 'odd' : 'even'); echo "<li class='$class'>{$item->title}</li>"; } From there, you should be able to target any item directly with CSS: li.a1 { /* first item */ } li.z1 { /* last item */ } li.a2 { /* second item */ } li.z3 { /* 3rd from last item, etc... */ } li.even, li.odd { /* self explanatory */ } The "a" class is counting from the beginning while the "z" class is counting from the end. You could substitute any class name, but I'm just using "a" to refer to "from the beginning" and "z" to refer to "from the end" (US alphabet).

Great site Pete! Awesome work.

I like the idea too, but don't think this could be accomplished with a single selector, or even with a single SQL query. At least, not one I can think of, though my mind has been away from SQL queries and such for a week, so I could be missing something. PW's DB structure is pretty non-traditional in that a template (fieldgroup) does not map to a single table of fields that can be compared against each other. So we have to know the value we are comparing against before we attempt a comparison.

The error may look like a general debug error, but there isn't such thing as a debug error in PW that doesn't give clues as to the problem. So go ahead and paste in anyway as it may still help us to track down the problem. But I think that your size() call looks fine. The only issue I see here is that the code is dependent upon that image being populated. So there is the potential to get an error if it encounters a page without an image. I suggest changing it to this: $image = $entry->single_image; if($image) { $image = $image->size(200,150); // display the image } else { // no image to display } Also, I suggest replacing this: if($entry == $page->children->first()) with this: if($entry === $page->children->first()) (or this): if($entry->id == $page->children->id)

I liked Diogo's reply on the other thread. I do plan to add the option for the MarkItUp editor back in ProcessWire, and this will enable the click-selection of images and placement in the copy by way of tagged filenames.

Well done. This could make a nice Textformatter module too.

Peter, go to Modules > Process > Users. In the Users config screen under the heading "What fields should be displayed in the page listing?" it should say: name email roles Are you seeing something different? Double check that you have an 'email' field in your system too. (Setup > Fields)

As far as I know, TinyMCE doesn't have the option of automatically recognizing and converting <br><br> to <p>. I could be wrong, but I don't think it's even possible to identify the user's intention (breaks vs paragraphs) once the software makes an assumption about one or the other. TinyMCE does support making <br><br> where it would do a <p>, but then you end up with non-semantic junk markup as the entire block becomes a paragraph... and no real way to tell what should be a paragraph and what should be two breaks. I think it's best to educate the client that they are creating what ultimately becomes semantic markup, which is fundamentally different from a word document. To create content on the web, the client really needs to understand the very simple distinction here, and it's well worth the 2 minutes to explain it. I usually explain it to the client by demonstrating an address as being one of the few appropriate places to use breaks (shift-enter): 114 Holly Road<br /> Hopkins, MN<br /> USA While you are there, it's also good to explain the difference between bold text and headlines.

Christian, This is something you don't need a hook for, rather this is more about jQuery. You'll use jQuery to take over the submit() event to the form. Create a new template and page to handle your comment posts. Turn on URL segments for the template, as you will use a URL segment to tell the comment template which page comments are being posted for. Here are some code samples on how you might do this, though this is written in the browser off my memory, so you may need to tweak before it works. Template: post-comment.php (used by page /tools/post-comment/) $fieldName = 'comments'; $id = (int) $input->urlSegment1; $p = $pages->find($id)->first(); // using find() rather than get() to ensure access checking if(!$p || !$p->has($fieldName)) throw new WireException("Invalid page"); $form = $p->get($fieldName)->getCommentForm(); $out = $form->render(); if($config->ajax) { echo $out; } else { // handle non-JS submission include("./head.inc"); echo $out; include("./foot.inc"); } Template: basic-page.php (or whatever template(s) are used by your pages with comments): // render the list of comments $comments = $page->comments->render(); // render the comments form, telling it to submit to our /tools/comments/ page instead $comments .= $page->comments->renderForm(array( // tell it not to process comments here 'processInput' => false, // submit to /tools/comments/[page_id] 'attrs' => array('action' => $config->urls->root . 'tools/comments/' . $page->id) )); $comments .= <<< _OUT <script type='text/javascript'> // you may prefer to move this to a separate JS file $(document).ready(function() { var $form = $('#CommentForm'); $form.submit(function() { $.post($form.attr('action'), $form.serialize(), function(data) { $form.prepend(data); }); return false; }); }); </script> _OUT; include("./head.inc"); echo $page->body; // replace with your page output echo $comments; // output the comments and form include("./foot.inc");

Digitex, I've not seen/heard of this issue before, so thinking it may be isolated. I agree it would be good to go ahead and upgrade just in case the version had some side effect. If you can still reproduce the issue after that, let me know what PHP and MySQL version you are running so I can try to setup a similar test environment.

Pete is on the right track, but I think this is what you want instead: $pete = $users->get('name=pete'); or this also works: $pete = $users->get('pete');

You could do it with URL segments on your homepage template: if($input->urlSegment1 == 'search') { echo $pages->get('/tools/search/')->render(); } else { // output your homepage } For me, I guess I've always seen something like "search" as a tool, and being a good fit in /tools/search/. But you can of course structure it however you'd like.

Beautiful work Marc. Love the site and the work. I agree with Charliez that the facebook widget is an eyesore. But take that as a compliment because the site looks so great that it makes the facebook widget seem out of place.

Neil, thanks for posting the JSON solution you used. Regarding PHP versions: not even WordPress will run in PHP prior to 5.2.4. Some big red flags at that web host… run away!

404, 500 and 301 are the only http error status headers PW sends. But of those, the only one you don't really have output control over in the 500. The reason for that is that it indicates a fatal error has occurred, and we need to stop execution asap rather than rendering any other pages and getting into a possible infinite loop. If you wanted to send another header, you could create a page containing the content you want to display and do it like this: if($error) { header('HTTP/1.1 503 Service Unavailable'); echo $pages->get('/tools/http-status/service-unavailable/')->render(); } If there's demand for something like that to be included like it is with a 404 in PW, then we could add it down the road.