adrian

Once you have installed Migrator and MigratorWordpress you will use the XML from WP and upload it. It will create all the pages, templates, and fields required. It will even create users in PW based on the names of the authors of the blogs in WP. Hope that helps.

Be sure to check "Import Created / Modified Dates" when running the import.

What about adding a Font Awesome plugin to Ckeditor: http://ckeditor.com/addon/ckeditor-font-awesome

Hey kongondo - small bug for you. When editing a page in a modal window - eg through Lister, the Export Data button is ending up at the bottom of the modal. The PW modal code grabs some buttons and forces them to be in the footer, but I am not sure why "export data" is ending up there, but "clear data" isn't - likely a class that has been applied to the export button - but I haven't investigated. Thanks!

Is the WP site still being updated? If you are closing it down and would prefer to move all the posts into PW, we have an importer: https://github.com/NicoKnoll/MigratorWordpress If not, you might try using the RSS feed from the WP site and use this module to render it: http://modules.processwire.com/modules/rss-feed-loader/ - not sure about this - just a quick idea

Module Toolkit does exactly this, and more! https://processwire.com/talk/topic/8410-module-toolkit/ It's still not in a release worthy state - some functionality needs some tweaking - it's on my list, but you know how it goes Still worth checking out though as I think it should handle your needs very well. PS Welcome to PW and the forums!

Seems like a very possible scenario!

HTTrack (at least how I have used it) just downloads the served HTML pages - it doesn't need any access to your server for this - it just grabs the pages that any browser can view. How do you know that the copy isn't just serving static HTML pages? If that is the case, then there really isn't anything that can be done. Even if they have duplicated some dynamic functionality from your site, that doesn't necessarily mean anything was hacked. This does seem a bit weird though. I assume you mean the same IP CIDR block, rather than the exact same IP address?

Beautiful work! I think I might have said this just recently to some of your other new features, but it is true - this has become one of my favourite field types. Now go spend some time on some of those commercial modules you have cooking

No problem - it looks like that approach of setting to false, doing something, and then setting to true is used in several places in the PW core. Interestingly, the cheatsheet mentions setting to false, but doesn't show true as an option - maybe just meant to be assumed - weird it doesn't show: $a->setTrackChanges(true|false) That would be consistent with others.

Great - just committed a new version of BCE (master branch) with those changes - thanks for figuring this out!

I think that setting TrackChanges to false seems like a great idea - I will happily implement that in BCE - do you want to suggest it to Ryan for the core version of that method? Just to clarify - this is PW core changes you are talking about and not something caused by BCE - correct?

Yeah, I was talking about the ability to import a CSV via the API - perhaps like I did with the TableCSVImportExport: http://modules.processwire.com/modules/table-csv-import-export/ $modules->get('TableCsvImportExport'); // load module // data, delimiter, enclosure, convert decimals, ignore first row, multiple values separator, append or overwrite $page->fields->tablefield->importCsv($csvData, ',', '"', false, true, ',', 'append');

Thanks for spotting Soma - it seems to come from this code: // temporarily put the parent in an unpublished status so that we can check it from // the proper context: when page-publish permission exists, a page not not editable // if a user doesn't have page-publish permission to it, even though it may still // be editable if it was unpublished. $parent->addStatus(Page::statusUnpublished); $parentEditable = $parent->editable(); $parent->removeStatus(Page::statusUnpublished); This is part of a method called getAllowedTemplatesAdd that determines whether the user is allowed to add a template to this parent. It is a modified version of this method: https://github.com/ryancramerdesign/ProcessWire/blob/cffb682836517065d7dd7acf187545a4a80f1769/wire/modules/Process/ProcessPageAdd/ProcessPageAdd.module#L191 I am not sure how to avoid this check. Do you think it is a major concern? I guess it's not ideal that there is a recorded change to a page when saved, even though there are effectively no changes. Any thoughts?

Or you could build a module like MigratorWordpress: https://github.com/NicoKnoll/MigratorWordpress that gets the Textpattern content and creates JSON that can be imported into PW. While it might be a little more work to build, it would be useful for other future users coming from TextPattern.

Are these new settings? I am running the latest from the dev branch and don't see these settings - am I being dumb? It's been a long week!

Ok, I just committed a new version (master branch again) that will grab the fields from the selected alternate page (you need to save the page after selecting an alternate parent page to refresh the field list), so you should now be able to set those in the config settings and not rely on doing it at export. Does this work for you like this? As for why your override checkbox is not saving, I am completely baffled - do you have debug mode on? Any errors? It looks like all the other settings on that page are saving - correct?

Ah - sorry - at the moment you will need to check the "User override CSV settings" and then choose the fields to export when going to actually export - does that make sense. I'll see what I can do about getting the correct fields to also appear in the config settings based on the selected alternate parent page.

No you can't make those changes - $config is not available in ready.php Please just try the code exactly as I had it, except for the name of the log file. Is "tfdupdates" definitely the name of the log file that you are saving, eg: $log->save('tfdupdates', 'log file content');

I think it is important that the user knows what is about to happen regarding appending vs overwriting for sure. Are you going to make the behaviour configurable in the import section settings?

Sorry, I don't understand - the code I posted works here without errors. What error are you getting? Make sure you have debug mode on.

There might be a better way - this is a bit of a rush, but put the following in site/ready.php wire('config')->initialLogPath = wire('config')->paths->logs; $this->addHookBefore('WireLog::save', function($event) { if($event->arguments[0] == 'test') { // where "test" is the name of the log to go into the tfdencoding subfolder wire('config')->paths->logs = wire('config')->paths->assets.'/logs/tfdencoding/'; } else { wire('config')->paths->logs = wire('config')->initialLogPath; } });

It's going to affect all log files, but you could do this in your config.php file: $config->paths->logs = $config->paths->assets.'/logs/tfdencoding/';

Just a quick thought on the "Note: Empty values will be saved" message - I am not sure that this is helpful to site editors, and may even be confusing! Maybe it is something that doesn't need to be displayed, or maybe just for superusers? Thanks!

Firstly, to clarify - what you are talking about is core functionality now, but you have posted in the support thread for Nico's "old" module. Just use the $options array like this: $options = array('limit' => 100); $items = $this->wire('log'); $items = $items->getEntries('animalabc_logs', $options);