ryan

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.

Thanks guys, it was a great trip. Thanks to everyone for keeping an eye on things here. Finally back on land and just need to get back home and unpacked. There was so much to do onboard, I didn't end up even turning on the computer the whole time. Though I checked my email a couple times from the internet cafe just to keep an eye out for any emergencies. It may take me a couple days to get all caught up with messages here, but I'm going to start chipping away at them now and should be back to a regular day in my office tomorrow.

I'm leaving tomorrow for vacation and going to be offline all next week. I've got friends staying at my place to keep the business running and cats happy, but during that time you may not see any posts, tweets or commits from me. Just wanted to explain ahead of time so nobody thinks I've disappeared. Though if internet access presents itself, then this will be the first place I'll check in, but just wanted to provide adequate notice if that didn't happen. I'm taking the laptop with me and hope to get some PW updates done on the road as well. If you don't mind, please keep an eye on this place while I'm gone. If any new users drop by here, make them feel at home. Hope you all have a great week next week. Thanks, Ryan

FieldtypeRepeater was added after 2.2 was initially released. The current version number should read 2.2.0.1. It is true that all you need to do is replace your /wire/ directory with the new one. But rename or backup up the old one, and backup your DB to be safe. It is also recommended that you replace your /index.php and /.htaccess files with the new ones, though I don't think that will be necessary for going from 2.2.0 to 2.2.0.1. After you replace your /wire/ dir, the first pageview will produce an error. Just hit reload in your browser and then it should be back.

Thanks for posting the full thing. But I'm confused because I can't relate it back to the original post. There's no $event argument in the hook. To me this looks like something that would be suitable as a LazyCron hook? At least, if it's not using anything about the current $page from Page::render, then you may not want to saddle it with this on every request. What's the exact error message you are getting? And is it the $currPage->save(); line that is throwing it? You might want to enable debug mode to see the debug trace to be sure.

I found that codemagic wouldn't work anywhere other than in TinyMCE's main plugins dir because it has hard references to some TinyMCE file in the parent dir. I know that can be fixed by making a copy of that file it is referencing, but that's not desirable and perhaps could cause bugs elsewhere. I've left codemagic in the TinyMCE code for now, but just not including it in the default TinyMCE config. So if someone wants to add it, they can do so by adding codemagic to their plugins list and and not have to worry about it being overwritten on upgrades. Still, only being able to use it with 3 languages is a shame. I can't believe TinyMCE has no fallback for language support other than a JS error. The other thing is that codemagic's list of words to translate is pretty short. It wouldn't be hard to add all the translations that TinyMCE supports. Google Translate told me she would help me out with this if I wanted.

The only dir that needs to be writable to ProcessWire is /site/assets/. If you migrate files to a live server, and PW can't write to that dir, it probably won't let you login because it can't create a session. Here's the chmod command (executed from site root) that would fix that: chmod -R og+rw ./site/assets That means make it readable and writable to "other" and "group" which includes everyone, so certainly going to include Apache. Depending on your hosting environment, you may not want that quite as open-ended, in which case you'd need to use different permissions... probably giving permission just to apache via its group. Something like this, though going to depend what group apache uses: chgrp -R apache ./site/assets chmod -R g+rw ./site/assets Many hosts have Apache running as you, in which case none of this matters so long as you yourself have read/write permission.

Forgot to add, of() is the same thing as setOutputFormatting(). I just added that as an alias recently because it's easier to type.

I had a Page::render hook handy to test with, but can't duplicate this one. The code you originally posted wouldn't work because it was calling setOutputFormatting on a non-object (before you had $page), but you indicated that the order was corrected, so sounds like that's not it. Here is my working version if it helps: public function example2($event) { $page = $event->object; // make sure you exit if it's not the $page you want if($page->template != 'basic-page') return; $page->of(false); $page->summary .= " test"; $page->save(); $page->of(true); } Please paste in the full code to your function again if it still won't work and I can copy/paste into mine.

Good questions. I'm not sure I can add anything to this since I've not had to deal with this particular issue before (I only know English, unfortunately). But thinking that anything that relates back to a function/property/class name that you would use in PW should probably use the same term, or repeat it in parenthesis or something? Just to avoid API confusion.