ryan

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.

If there were to be a standard format for importing ProcessWire-to-ProcessWire, I'd probably choose JSON. Like XML, but without unnecessary verbosity for when you don't need it. However, this isn't a great way for going to/from other CMSs because every system is different and there isn't going to be a universal way to reconstruct everything from one CMS into another with 1 click. That is, unless the importer is written specifically for importing from a specific CMS. Given that, I tend to think CSV is a good way to go. CSV is just data and lacks any real metadata (unless you decide to bundle it in). In my experience, when switching platforms (importing data from another CMS), the job is easiest if you can just deal with the data and not the platform-specific metadata. In fact, I find it sometimes easiest to ignore the existing CMS and just screen-scrape the data right off the site. However, the main reason I like CSV is just because I can bring it into a spreadsheet very easily. Once I've got data in a spreadsheet, I know that anything can be done with it. I can modify it, save it, and bring it into ProcessWire. It's not nearly as straightforward trying to bring a JSON or XML into a spreadsheet. CSV is such a stupidly-simple format that there is little question about the scope of it. You know that when you import a CSV, you are going to have to figure out where those fields should go, and create the fields if necessary. I think it creates the right balance of involvement between data and user and leaves out any ambiguity. I wrote the CSV importer primarily because I deal with so much data that comes from spreadsheets. So having a CSV importer was the obvious choice there. Previously I'd always just used the API for doing imports (and still do half the time), as that's also quite easy and you can work with any format there. Ultimately I'd like to expand the importer to support JSON and XML too, but I suspect that CSV will be the most used. As for making safety backups, a MySQL dump file can't be beat for that. I don't think that's what we're talking about here, but just wanted to mention that one should always use mysqldump files for their regular site database backups.

Nice job maruchan. I tried them out yesterday and they were loading slow for me too–though not nearly as slow as Antti and Sinnut mentioned. Must have been a kink in the pipes yesterday. But today everything loads nicely for me at least (in Atlanta).

I think I see what the problem is. In your checkpagestatus() function, at the top, have it abort if it's an ajax request. i.e. if($this->config->ajax) return;

Nice job Soma, just tested out and it seems to work beautifully! I'm amazed how quickly you got this out. This may not matter much, but if you want, I think you can replace the try/catch in ProcessPageEditSoftLock with just this below. That would get rid of the try/catch and condense it down to one more efficient query. Though in this case, I don't expect it would really matter since the query happens once every 20 seconds rather than hundreds of times a second. $this->db->query("INSERT INTO users_editing_page (page_id, user_id, ts) VALUES($page_id, $user_id, $time) ON DUPLICATE KEY UPDATE ts=VALUES(ts), user_id=VALUES(user_id)"); I love that the times are configurable. The only question I had was about why times are in two different formats on the config screen (seconds and milliseconds)? I'm thinking that many non-programmers might not recognize exactly what milliseconds are at first.

I've used base64 encoding in URLs before (though in GET vars) and had to do the same thing, trimming out the equal signs at the end.

It sounds like a great environment for this. Also amazing how convenient that script is, I'd definitely be interested in taking a look at it sometime.

On my dev, I use it primarily for testing stuff out before migrating to live. I don't deploy content or stuff from the database. Usually it's templates, stylesheets, modules or PW upgrades. Then if all is good, I'll mirror the changed files over (for template stuff ) or perform the same install/upgrade actions on live (for modules or PW upgrades). I don't keep the DBs all that up-to-date on my dev server, though I do have daily DB backups running (I just don't import them on my dev unless there is some change I need to test with). I need to keep my dev server completely isolated from my live server so that they aren't sharing anything. If the two are sharing anything then, then technically you are working off the live server to some extent. If something goes haywire, it's feasible it could take down both your dev and live sites at the same time. If you install a module on your dev then it's in the DB and PW is expecting to find it on the file system too. If it's autoload, or if something calls upon it, and it's not there on live, I believe PW would throw an exception on your live server, taking it offline. You could solve this by symlinking your /site/modules/. But you don't have a real staging ground for modules unless you have an isolated database. Another scenario. Lets say you upgrade PW on your dev server (or even some module), and that upgrade involves some change to the DB. The live site is now running an older version of PW on a newer version of the DB, possible data corruption ensues. While this isn't likely at the present time since we rarely change anything in the DB, it's not safe to assume that multiple versions of any CMS (or modules) would run properly off a different version of the database. You can solve this by symlinking the /wire/ dir, so that the DB and PW version are always consistent with each other (maybe you are already doing this). Last scenario. You are now symlinking your /wire/ dir to avoid version mismatches between source and DB. You do a "git pull" to grab the latest PW commit. You are essentially committing this to live without testing. If there's a bug in the commit, you'll see it on both dev and live. But then we're left with the only real difference between dev and live being /site/templates/ ... but that's an important one, and I can see the advantages there. For instance, you could create a new template and new page and have them work on your dev server while live still sees it as a non-viewable page (since there is no template file on live). Push the template to live and then all those pages start working–pretty cool. Maybe not much different than just creating it on live and keeping it unpublished until you are ready to publish it, but using the template lets you do multiple pages or a structure of them in one shot. It should also be reasonably safe to modify most templates on your dev server and be able to test them before migrating to live. A parse error in a template on dev won't affect the live site. Likewise, things like stylesheets, javascript and most front-end dev stuff–your current setup is a fine way to test this stuff out before migrating to live. I'm sure there are other advantages too. But I guess I think that if using this route, you may want to consider another 100% isolated dev machine for doing your more in-depth template development, module development, and testing upgrades/commits or new modules before migrating to your dev-live. Basically all the back-end stuff. Then your current dev site could be kind of a intermediate option and place to work with front-end stuff.

I've just committed and update that will let you remove any system flag/status from Fields, Templates or Pages using this method below. This is how you could delete system fields, templates or pages. The code below is what you would do right before you delete them. Please don't do this on any of PW's system fields, templates or pages. The system flags exist precisely so people can't delete these. This override is provided only for uses like yours and mine where we've created system fields/templates (or pages) with modules but want to be able to uninstall them with the API. So here's how you'd do it: Field: <?php $field = $this->fields->get("discussions_message"); $field->flags = Field::flagSystemOverride; $field->flags = 0; // all flags now removed, can be deleted Template: <?php $template = $this->templates->get("discussions-forum"); $template->flags = Template::flagSystemOverride; $template->flags = 0; // all flags now removed, can be deleted Page: <?php $page = $this->pages->get('some system page'); $page->status = Page::statusSystemOverride; $page->status = 0; // all status removed from page, can be deleted With regard to users adding your fields to other templates, I would just throw an exception on your uninstall if that is the case. That way you can tell them to remove the field from any templates where they may have assigned it. Though if you've made them system fields, chances are people won't be adding them to other templates since one has to be in the $config->advanced system dev mode in order to do that. <?php if($field->getTemplates() as $t) if($t->name != 'discussion-topic') throw new WireException("Please remove {$field->name} from {$t->name} template before uninstalling."); If you want to do a recursive delete of a discussion tree, you could do it like this: <?php foreach($this->pages->find("template=discussion-forum") as $p) { $this->pages->delete($p, true); // true = make it a recursive delete }

Thanks guys, this is definitely appreciated. As it is, the file translation system is largely done and ready for use. This is the part that does the same thing as GNU gettext. But that's just half of it. The other half is making multilingual 'text' fields, inputfield labels and descriptions (stuff that is in the database rather than the file system). So that's what I'm working on next, and working on it literally every day, I'm hoping to have something workable here by mid November. Since these two parts are somewhat independent of one another, I've been wondering if I should put out the file-translating language module sooner, or wait and release it all together.

Anything I change with TinyMCE seems to reveal or introduce new bugs and keep me glued to the computer for days trying to workaround them. Even so, I want to keep up to date with TinyMCE as theoretically things should get better with new versions. Things seem to be reasonably stable with our current TinyMCE version, so it's something I might like to approach once 2.2 is wrapped up. Is there anything specific in the new version that you think might be beneficial in PW? I would assume it improves on what's already there in some aspects, but just wondering if there are any killer features in the 3.4 that we are currently missing out on. If so, we may want to do it sooner rather than later.