ryan

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(); } }

This was really easy to fix once I tested with the example posted. Thanks for the excellent examples to test from. The latest commit is updated to reflect the issues identified here, and test.php should now run perfectly. Please let me know if you come across any other issues. Thanks, Ryan

It's a typo, where did you find it? I'd like to correct it. It should be: $users = wire('users')->find("roles=$role,sort=name"); Note "roles=" (plural) above, not "role=". There is no built-in field called "role" in ProcessWire so the error message you got is correct that the field does not exist.

Darn iPhone doesn't let me scroll the code to see all of that error, but I just saw the query in my email. It's missing a template_id in the query. That's why it's failing. So the two issues seem related. And this will be easier to find now that I can see what's going on here. Thanks for these great examples and all this help testing.

Interesting, it's definitely not cached if getting a DB error. The template thing sounds like a bug, but the page thing is perplexing. Almost wonder if were hitting a MySQL query cache here. Will be able to track it down tomorrow.

Will take a closer look when I'm at the computer tomorrow, but wanted to mention that when importing data where you need to maintain the previous systems unique id, create new field(s) for it (like an integer field) and name it something like source_id, old_id, old_parent_id, etc. Then use that where needed to create your structure. PW won't be happy if you try to tell it what numbers it should use for it's own unique IDs, in part because it reserves several number ranges for internal use.

Seeing that code, I believe the $pages->get("/holding-page"); selector is cached, if its returning null the second time around. Try adding $pages->uncacheAll() after saving holding page. Like I say, save() should have done it already, but just curious if that helps.

I'm not near the computer till tomorrow otherwise I'd be able to troubleshoot. The iPhone tells me it cant download a zip file . I was creating templates and assigning them to pages I'm the same request as recently as yesterday when working on the language installer. But I suspect I've not done it in the way it sounds like you are here. Make sure you have saved the template before attempting to add to a page. The way you describe it sounds like the newly created template isn't yet in the $templates var (assuming you saved it). If that's the case it would be a bug. As a temporary solution, just give the page the template object you made rather than a template name. That's more efficient anyway. It's the way I've always done it, which may be why the issue hasn't turned up earlier. But if it's a bug I can fix it tomorrow. Also there was a question that made me think $pages->uncacheAll() might help. That just clears out the current memory and selector cache, and can be helpful when you are dealing with large imports. Though PW should automatically do that when you save a page. Edit: also, if you are dealing with 30k items you may very well run out of memory. You'll want to paginate the import or do it with multiple executions. 500-1000 page chunks is what I usually limit to, but it depends entirely on how heavy the data you are dealing with. But since you are dealing with large numbers of pages, you'll have to take more care when working with the API. For instance, $page->children() will load all children. So you need to consider limits like $page->children("limit=100"), and the like... Things that you don't usually need to think about on smaller scale use. There is a thread in the FAQ forum that covers this better. I'd link to it but I'm on a cell phone

Yes, but PW already has users setup as pages, so that's what you'd want to use for the property owner. If you only wanted them to be able to edit specific pages, you could create a page reference field (using PageListSelectMultiple Inputfield), add it to the 'user' template. Then for the template used by the pages you want them to be able to edit, you could check if the page being displayed is in their list of editable pages you defined, and let them modify it if so. (This idea is from Soma and something that I know he's done before). I'm late to the conversation, but if I understand correctly, you are on the right track!

That's what the PW API is for. I think you will really enjoy how easy it makes more complex import tasks. Post examples of the data you need to import and we can get you started.

I agree, I think I will do that then. The only thing is that I feel like I need to figure out a few things with the multilingual text fieldtype/inputfield and field label/descriptions first, just in case it requires any changes to what's already been coded. I don't want to put it out there and then ask everyone to start over with anything. So I'll get a little more figured out on this end and then plan on releasing it in two parts if possible.