adrian

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

@tpr - glad it works and that Migrator helped to save your *ss too Firstly, I do have a working solution for you, but first a little background It is weird that nothing is getting exported - it is definitely exporting a valid CSV file for me. The only problem I am seeing is that I can't control the fields that are exported - it is defaulting to: Set Password, Email Address, Roles The problem is that if you allow the Home > Admin > Access > Users to be separately configurable you should be able to specify the required fields, but the settings don't save, because that page is locked for editing by PW so we are out of luck with that. BUT, here is my working solution, which I think is cleaner than making users navigate to that deep page anyway: Grab the latest master version (there is one critical change to make this work). Create a new page somewhere in the main page tree (not inside the Admin tree) - maybe called "User CSV Export". Make this new page separately configurable in the BCE "Where editing tools are available and separately configurable" settings section. Go to the Settings tab of this new page and configure it to enable Export mode. In the Content / Deletion / Protection section, set the Parent Page to: Home > Admin > Access > Users In the CSV Export Settings, set up the fields to export. You will likely want Name, Email Address, and any custom fields you may have set up. Save settings and then go to where you have BCE displayed (maybe an Inline Fieldset would be a good idea in this case) and click Export. Works great here, so please test and let me know.

Thanks for reporting @tpr - I have fixed this on the master branch. I have some uncommitted changes to the dev branch at the moment, so the fix won't be on that branch just yet.

Just so you are aware, the InputfieldSelect that soma mentioned has nothing to do with the third party FieldtypeSelect module from Hani which is what I think you are talking about in your first post. If you want to specify optgroups with InputfieldSelect, you want to use a Page field, or the Options field type (which is in the core, but not installed by default).

Ah yes - perhaps I should have said: "populate blank rows" vs "overwrite all existing rows", instead of append/overwrite. Sorry for all the confusion, but I think we are on the same wavelength now Yes - creating a new blank row for each year is easy - I have a "Years" parent page and they simply create a new year under that as required - well actually it is done using Batch Child Editor and the child pages are hidden to avoid confusion. Thanks again!

I hate CSS too - not my strong point, that's for sure! Given that the PW core uses the brower's alert box, I wouldn't bother struggling with it too much. It might be nice if PW had it's own consistent alert (like the pw-modal that we have for modals), but I don't think you should put too much effort into overriding the browser in this case. For my purposes, I don't think I would want what you are suggesting because an incorrectly prepared CSV file could damage my site by adding additional years and indicators (nitrogen etc). The indicators are actual pages that have their own content, so I think it is important that site editors make a conscious decision first to add a new indicator which will then automatically appear in the Matrix field. This is the reason I am using Matrix and not Table - the automatic population and new indicators and years. Yes, I didn't see your initial point - sorry, but I also think that trying to deal with that is getting too complicated

Kongondo - you raise some good points around the issue of appending when importing. I don't think I really thought it through myself when I mentioned it in the first place - of course this is not a normal field type where you can just append new rows. The row must already be part of the matrix. I was talking about appending new rows. In my current use case, each year there will be a new "year" row that will appear in the matrix. I would like users to potentially be able to import a CSV of the data for that row. Of course importing for one row may not be worth the effort, but in some cases I can have up to 20 columns, so it might just be worth it. In that case, I would want "import" to just append the new row to the blank year that is in the matrix table. Here's my matrix so you can see what I am talking about: I am not sure I agree with this - if I had a dataset in excel I would definitely have the years in the first column. I agree that there are issues around how to structure the CSV to be imported - my initial thought is that it would be nice if it could (or must) contain the year in the first "column". I think it is a bit weird that you can't export from a matrix field and then import the same CSV file back into the matrix field, because of that first column issue. Maybe "ignore first column" and while you are at it, "ignore first row" options would be good - make sense? I am concerned about the current behaviour though, because at the moment, any import completely wipes the existing data - I don't think this is a good situation. Some other thoughts on your recent dev additions: my initial thought is that checking rows would mean that only those rows would be exported - I didn't realized that I had to enter row numbers - could this be changed to respect checked rows as well? It would be nice if Matrix supported Shift+Click for selecting a block of rows like the PW does. I think your new modal alert box needs some css tweaks - might be on your list, but thought I'd mention anyways. This is getting better all the time - really super useful for my needs - thanks again!

Glad you like it! Are you talking about from Access > Users, or Home > Admin > Access > Users ? The former uses Lister, so I assume you are talking about the latter. If you have ListerPro you can use the export to CSV action from the former. If you don't, then go into the BCE module code and comment out this line: // don't even consider system templates if($this->editedPage->template->flags & Template::flagSystem) return; On the master branch it is line#159 and on dev it is 166. Let me know if that works for you. I wouldn't recommend leaving this commented though - I haven't though through it too much, but the Replace mode could cause some major damage pretty quickly Do you need this to be available regularly, or is it a one off need? If you need it regularly I could add any exception for the user page - let me know and we'll work something out.

Hi Robguy - any chance you could check with the latest dev version of PW - it should be release at 2.7 in the next couple of weeks. Would be nice to know if this is still a problem. Thanks!

I actually really like ImageExtra (http://modules.processwire.com/modules/image-extra/) for Slider details - you can easily specify all sorts of "subfields" to contain info for each image in the slider.