ryan

I agree with all this. Though the languages module lets you specify date formats, and I was thinking the InputfieldDate would be able to pick up the date formats from the language definitions. But still thinking about this one. I didn't want to put a lot of work into the date Fieldtype until we had the multi language stuff down because it seems like the two would ideally go together.

Thanks for your work in testing this stuff. The way it works is that a checkbox label is supposed to toggle the on/off state of the checkbox. So when you've got something like <label><input type='checkbox' value='1'> Click Me</label>, clicking "Click Me" is supposed to toggle the checked state. So in the case of that trash icon, the icon itself is the label, while the checkbox is hidden.

Can you try adding this right before your save? I'm wondering if this makes it save: $page->trackChange($field); // where $field is the name of the field, 'images' or whatever it is

Thanks for posting this Sevarf2, it's good and interesting to see one approach to this. One thing I wanted to mention in your code for checking existing email, it's preferable to sanitize the value before including it in a selector. Less important, but it's also preferable to get it from wire('input') rather than from something like $_GET, $_POST or $_REQUEST since it will account for annoying server-side settings like magic_quotes. So here would be an update to that script: <?php require_once('../index.php'); $email = wire('sanitizer')->email(wire('input')->post->email)); $sql_check = wire('users')->find("email=$email"); if(count($sql_check)) { echo 'false'; } else { echo 'true'; } Also I recommend leaving the closing PHP tag "?>" out if it's the end of the file. The reason is that it's unnecessary, and causes problems if any whitespace happens to end up after it. Of course the whitespace is invisible, so it leads to difficult to find bugs. Best just to skip the ?> at the end of the file.

Nice job Jasper, thanks for posting! Makes me want to take a trip to Stockholm.

Just wanted to mention that the default for $session->redirect($url) in PW is a 301 (permanent) redirect. If you want a 302 redirect then give it a second param of false, i.e. <?php $this->session->redirect('http://processwire.com'); // 301 permanent redirect $this->session->redirect('http://processwire.com', false); // 302 temporary redirect http://processwire.com/api/variables/session/

What error message are you getting? If you export the structure of the field_$name table using your field, what does the structure look like? (can you paste in)? Since you are keeping $img->crop as an array, do you have something in your sleepValue that converts it to a string (like the CSV one I mentioned) or something to keep it consistent with the format needed in the DB?

For your new Fieldtype, I'm assuming you are extending FieldtypeImage or FieldtypeFile. There are a few methods you'll want to override to provide your new cropping fields. I'm using CSV rather than JSON here just because it seems like it would take up less space in this case, and be almost as simple. Though you could also take the approach of just making each of the cropping fields individual parts of the DB schema, but I'll go with CSV for this example. <?php public function getDatabaseSchema(Field $field) { // use the existing parent schema $schema = parent::getDatabaseSchema($field); // and add new field with CSV cropping info (x1, y1, x2, y2, w, h) $schema['crop'] = 'varchar(60) NOT NULL DEFAULT '''; return $schema; } // function called to convert values from DB to Pagefile/Pageimage public function ___wakeupValue(Page $page, Field $field, $value) { if($value instanceof Pagefiles) return $value; $pagefiles = $this->getBlankValue($page, $field); if(empty($value)) return $pagefiles; if(!is_array($value) || array_key_exists('data', $value)) $value = array($value); foreach($value as $v) { if(empty($v['data'])) continue; $pagefile = $this->getBlankPagefile($pagefiles, $v['data']); $pagefile->description = $v['description']; if(!empty($v['crop'])) { list($crop['x1'], $crop['y1'], $crop['x2'], $crop['y2'], $crop['w'], $crop['h']) = explode(',', $v['crop']); } else { $crop = array('x1' => 0, 'y1' => 0, 'x2' => 0, 'y2' => 0, 'w' => 0, 'h' => 0); } $pagefile->crop = $crop; $pagefile->setTrackChanges(true); $pagefiles->add($pagefile); } $pagefiles->resetTrackChanges(true); return $pagefiles; } // function called to convert the pagefiles to array ready for DB storage public function ___sleepValue(Page $page, Field $field, $value) { $sleepValue = array(); if(!$value instanceof Pagefiles) return $sleepValue; foreach($value as $pagefile) { $sleepValue[] = array( 'data' => $pagefile->basename, 'description' => $pagefile->description, 'crop' => implode(',', $pagefile->crop), ); } return $sleepValue; }

First thing to try is to edit /site/config.php and locate this line near the bottom: $config->dbLowercaseTables = true; Change it to false. Then see if it starts working. If that doesn't do it, change it back to true and lets see if we can rename the table manually. If you don't have easy access to PhpMyAdmin I can post a quick PW code bit that'll do it for you. But lets wait and see if that is even necessary first.

Not sure how you had it before, but I think that the script would have to be added before ProcessPageEdit::execute rather than after. I'm not sure I understand about the level of the page–and can't think of any reason it would matter. But if you find it's doing this in a before(execute) hook, let me know and I'm sure we can track it down.

Did contactname have any uppercase characters in it? I'm just wondering if it's a database upper vs. lowercase thing that didn't translate through the upgrade.

I think what you are looking for is the Page fieldtype, which is the one used by ProcessWire for handling single and multiple selection. With this fieldtype, you can utilize selects, checkboxes, radio buttons, asmSelect, PageList select, etc.

To add something to the settings tab, hook into ProcessPageEdit::buildFormSettings It returns an InputfieldWrapper that you can append() or prepend() fields, or you can even do something like this: <?php $wrapper = $event->return; $templateField = $wrapper->get('template'); $myField = wire('modules')->get('InputfieldText'); $myField->attr('name', 'hello'); $myField->label = "Hello there"; $wrapper->insertAfter($myField, $templateField); $event->return = $wrapper; But I think it's better to just append or prepend to the the wrapper, because you don't really know for sure which fields will be active on the settings tab. Also note that on some pages, there is no settings tab.

This is relatively minor, but I realized a lot of us were repeatedly using the same code to populate a required 'name' field when creating new pages via the API. As a result, I figured I'd build it in. Here's the commit note: Previously if you tried to save a page without a 'name' field it would throw an exception. Now it won't, as long as the page has a title. This should not affect any existing code. But it does mean that future page imports may be a little simpler since you don't have to consider the 'name' field.

Great solution! This is a far superior solution to using the module.

Last I checked we were fully IE8 compatible, except for the TinyMCE issues. So I think you are right that it's not that big of a deal. But the TinyMCE one is a little bit more of an unknown.. I've already clocked in a day trying to make it work with IE8 without breaking it in other browsers and struck out there.

I definitely wouldn't want to drop IE support. Before I inadvertently wiped out all my virtual machines during a recent OS X upgrade, I found everything in PW to work just fine in IE8 (minus TinyMCE image/link dialogs). Though I did spend days trying to get IE8 working with the TinyMCE dialogs and never figured it out. Perhaps we should officially support IE9 and newer as you guys mentioned. I had always thought that most clients used IE so I've always put a lot of effort into supporting it. I always ask clients what browser they are using, and quite surprisingly it's been long time since one has said they are using IE. But it wasn't that many years ago that almost all used IE. Still I prefer to err on the side of expecting that someone is using IE until they say otherwise.

I haven't looked at this in a long time. But I'm hopeful that we can get TinyMCE working in at least IE9 (if it doesn't already). I think the issue was primarily bleed through on dialog boxes (in IE8). Otherwise it generally worked pretty well in IE8. Switching to CKEditor seemed like a possibile alternative, but TinyMCE is in such widespread use (even WordPress) that it seems like maybe it's just a matter of making some yet unknown adjustments in our usage of TinyMCE to make IE happy. So I guess right now I'm feeling like we should stick with TinyMCE and just keep at it unless there's a really compelling reason to pursue CKEditor instead.

Good idea, I'll add this to the main source as well. I should be able to test with IE9 later this week. I can understand IE6 or IE7, but am a little surprised IE8 and above would have the issue.

Good tip! Here's another way to do the same thing (using the slice method to trim off home): <title><?php foreach($page->parents()->append($page)->slice(1)->reverse() as $parent) { echo "{$parent->title} - "; } echo "COMPANY NAME"; ?></title>

There is no built-in support for pagination of comments at present. Though it's certainly possible to paginate them, but not without doing the pagination yourself. The $page->comments value is a CommentsArray, which is a WireArray. You can see all the WireArray methods here: http://processwire.com/api/arrays/ So your comments pagination would probably be something like this: <?php $limit = 10; $start = ($input->pageNum - 1) * $limit; $comments = $page->comments->slice($start, $limit); echo $comments->render(); if($input->pageNum > 1) { echo "<a href='./page" . ($input->pageNum - 1) . "'>Previous Page</a> "; } if($start + $limit < count($page->comments)) { echo "<a href='./page" . ($input->pageNum + 1) . "'>Next Page</a> "; } The above is an approximation written in the browser, so may not be a working example, but should be close.

I haven't had time to take a close look at this yet. What you've done here has been a great help and I will mark this unread so that I don't forget! Thanks, Ryan

Consistent with jQuery syntax, $pages->get() returns one item, whereas $pages->find() returns multiple. So your original code would only ever return 1 page. Soma is right on this, though just want to mention that you probably want the second one (using children), because like with jQuery, calling find() on a page will return not just children but anything in that branch of the tree. Whereas children() will just return direct children of that page. Also, you can use your original syntax too if you prefer, but substitute $pages->get() with $pages->find(), so that you are aren't asking for just one item, i.e. $news = $pages->find('parent=/news/, sort=date, limit=6');

Can you double check that it's not a cache problem in IE (perhaps an older version of JS file cached). Since I don't use it often, I'm not exactly sure how force IE to refresh everything short of actually clearing it's cache. If after double checking it's not a cache problem, let me know which version of IE. Btw, I'm temporarily without an IE test machine. My OS X upgrade wiped out my virtual machines somehow, otherwise I'd test it now. Just need to take a day to get all the virtual machines going again.

It's pretty easy if you are doing a before hook because the page's 'id' will be 0. But I'm guessing you need an after hook. ProcessWire doesn't populate the page's 'created' date until after it's been loaded from the database the first time. As a result, your after save hook can check the $page->created property. If it's empty, then the page is new.