ryan

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.

Custom admin themes go in /site/templates-admin/. The /site/ structure is never touched during an upgrade, so it should be impossible to overwrite an admin theme during an upgrade. http://processwire.com/download/admin-themes/ I'm guessing you had your custom admin theme in /wire/templates-admin/ instead? Just remember that /site/ is all your stuff, and /wire/ is all ProcessWire's stuff. The reason upgrades are easy is because you can just replace your entire /wire/ directory with the new version and you are set. But that also means it's a bad idea to put any of your own stuff in /wire/. Btw, a good practice when upgrading is to bring in the new /wire/ directory under a name like /wire.new/. Then once it's there, rename your old /wire/ directory to /wire.old/, and then /wire.new/ to /wire/. Test that everything is working well. Once comfortable, delete /wire.old/. But if for some reason you noticed a problem after putting in the new /wire/ then, you can simply rename the /wire.old/ dir back to /wire/ so that you aren't suddenly in a bind and unable to revert.

Sorry, I should have noticed this the first time, but here's the problem: $results = $page->children->find("limit=8, sort=title"); The $page->children call is actually causing all the children to be loaded, and then you are post filtering in memory. Since all the children are already loaded, it's not attempting to do any pagination. Replace it with this and it should start to work: $results = $page->children("limit=8, sort=title");

Thanks, I've fixed that. That particular post was written before the new user system was, so those code examples were approximations but still want to keep them correct.

Check the template where the pagination is and click on the URLs tab. Check the box for "allow page numbers" – Let me know if that's it?

I think that it'll be hard for us to tell you exactly what to do without having all the data and doing it ourselves, but I'm going to try my best to give you an applicable example that should roughly fall in with the approach you'll want to take. Things like setting a different template based on parent or the like are going to be very case specific, so I've kept it simple here. Also, I'm doing this as a command line script, but the same example should translate to populating in a template or bootstrapping the API from another web script. Lastly, I've assumed you already have a template in your system called 'example-template' that has the fields 'typo3_uid' and 'typo3_pid' (FieldtypeInteger) added to it, and that you already have a page in your system called '/example/' which will serve as the root parent where we start populating your imported pages and build the structure from. #!/usr/local/bin/php -q <?php // change the line above to reflect your system path or remove if not command-line include("./index.php"); // bootstrap ProcessWire's API, if applicable // the example template and parent we will be using, change for your use $template = wire('templates')->get('example-template'); $parent = wire('pages')->get('/example/'); // open the CSV file with the data in it $fp = fopen('your-csv-file.csv', 'r'); $n = 0; // we'll keep track of the CSV labels on line 1 so we can use those labels to make an associative array $labels = array(); // loop through each line in the CSV while(($data = fgetcsv($fp)) !== false) { if(++$n == 1) { // if we're on the first line, save the CSV labels and skip over the line $labels = $data; continue; } // use the labels we found from line 1 to make the $data array associative foreach($data as $key => $value) { $label = $labels[$key]; $data[$label] = $value; // now $data[1] is $data[pid], for example unset($data[$key]); // don't need the numbered index anymore } // create the new page to import $page = new Page(); $page->template = $template; $page->parent = $parent; $page->typo3_uid = $data['uid']; $page->typo3_pid = $data['pid'] $page->name = "typo3-$data[uid]"; // i.e. typo3-123, you may find a better field for this $page->title = $data['title']; // add any other fields you want to import from the CSV here $page->save(); } // with all the pages imported, now lets give them structure according to the typo3 'pid' field. // we didn't do this before just in case the children imported before the parent, which may or may // not be the case in your CSV, but I didn't want to risk it... // locate all the typo3 pages that have a parent greater than 1 (i.e. greater than /example/, our import root) $matches = wire('pages')->find("parent=$parent, typo3_pid>1"); // loop through the pages that were found foreach($matches as $page) { // find the parent they are supposed to have $newParent = wire('pages')->get("typo3_uid=" . $page->typo3_pid); if($newParent->id) { // give them the proper parent and then save $page->parent = $newParent; $page->save(); } }