ryan

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.

I don't think sharing one database for multiple pieces of software is a good idea. Lots of concerns there whether PW is part of it or not. A vulnerability in one piece of software suddenly becomes a vulnerability in all. Table prefixes have been intentionally left out of PW, and I'm of the opinion that this is something other software should phase out as well (especially WordPress). I'm guessing this is from a legacy hosting platform or a free web hosting account, and so would say it doesn't meet PW's minimum requirements in that regard. I understand the hosting part is out of your hands, but would probably suggest kindly encouraging your friend to get a $3/month web hosting account from HostGator or something, so they can have more than one database. Though it surprises me even a free host would still be enforcing that limitation as it's a magnet for security problems and tech support.

Another approach you could use would be to use PW's WireUpload class: $ul = new WireUpload($field_name); The rest here:

<p>Pete this should be enabled as a configuration option by default in your /site/config.php. Though I don't know why the server in your case is using different permissions. But take a look at these lines in /site/config.php just in case: </p> <p> </p> <p> </p> <div><span> </span> <div><span>/** </span></div> <div><span> * chmodDir: octal string permissions assigned to directories created by ProcessWire</span></div> <div><span> *</span></div> <div><span> */</span></div> <div><span>$config->chmodDir = "0777";</span></div> <div> </div> <div><span>/**</span></div> <div><span> * chmodFile: octal string permissions assigned to files created by ProcessWire</span></div> <div><span> *</span></div> <div><span> */</span></div> <div><span>$config->chmodFile = "0666";</span></div> <span> </span></div> <div> </div>

This error can be ignored as it's just a PHP strict notice, but I've gone ahead and updated the functions in those modules so you won't get notices when in strict/debug mode. I recently added a flags param to the error() and message() functions, and hadn't updated the 3rd party modules that implement that function. Thanks for letting me know -- now fixed.

I still plan to go the tags route, at least when it comes to version numbers like 2.2.1, 2.2.2, etc. Just haven't gotten to it yet, but will soon. I don't think this is what you are looking for, but also wanted to mention how you can access the version number from the API. $config->version; holds the version number in a string, like '2.2.0'. You can also access the individual components as integers from ProcessWire::versionMajor; ProcessWire::versionMinor; and ProcessWire::versionRevision;

I'm going to be adding an option to store sessions in the DB soon too, so this will be another alternative option for those that want it.