adrian

Hi all, I have just committed a major new version (2.0.0) on the dev branch (https://github.com/adrianbj/TableCsvImportExport/tree/dev). This version has breaking changes to the frontend export/import API methods!! Changes include: changed API methods - please see ReadMe for details: https://github.com/adrianbj/TableCsvImportExport/blob/dev/README.md module config settings to: set defaults for import and export parameters (delimiter, enclosure, etc) can users override the default parameters can users can select columns/order in exported CSV can users use an InputfieldSelector interface to filter table rows (this is an enhanced version of the built-in Table "Find" interface available when you have pagination enabled) I would like to make this the stable (master) version as soon as possible because the old API methods were not well constructed so I would really appreciate testing of this new version if you have any time. Thanks! PS - has anyone out there actually been using the API methods?

Thanks for the report @szabesz - I have now overwritten the PHP time limit for these actions, so that should take care of your timeout issues. Regarding the duplicate names problem - I have committed a new version which adds logic to check for duplicate usernames and also checks against users already in the system. This all occurs before it adds any users, so it should make for a much nicer experience. If you have a chance to test, please let me know how it goes. Screenshot showing when duplicates are detected Screenshot showing when existing users are detected

Taken care of with this commit: https://github.com/adrianbj/ProcessAdminActions/commit/da1fa616a9c921488c0639e944dd255bb9f2e21b

Glad it worked so well for you! The profile-edit permission I guess is not critical if you don't have the "Password Force Change" module installed, or if you are not relying on the "Email New User" module to automatically generate the user passwords. The thinking here is that you probably don't (or shouldn't) know the passwords of the users, so you use EmailNewUser to generate a password, but then you want to ensure they change it quickly because the password was included in an email (hence the use of PasswordForceChange). And to be able to change their password on first login, they need to be able to edit their profile. I guess that wording needs to change to explain things better. Any thoughts?

That's basically how I have handles it in the past: path/to/myajaxtemplatefile.php?lang=portugues Then in the myajaxtemplatefile.php file add this to set the language: $user->language = $languages->get($sanitizer->selectorValue($input->get->lang));

Hi @cjrobe - I am glad you are finding the module useful. Unfortunately I think what you are looking for is beyond the scope of this module. Changing the paths to files/images is an entirely different problem to changing their filenames. I honestly think you should ask why you really want them stored under the title of the page - what if you change the title of a page at some point - then the file will be in an incorrectly named folder. Page IDs (which is how it works now) will always be the same. If you really want to go down this road, have a read here: https://processwire.com/talk/topic/9544-how-to-change-imagefiletemplate-path/

@elabx - thought I'd take a quick look into what is actually required and this seems to work well: $this->addHookAfter('ProcessPageSearch::executeFor', function($event) { $response = $event->return; $responseArray = json_decode($response, true); $matches = $responseArray['matches']; $i=0; foreach($matches as $match) { if($match['type'] == 'Pages' && strpos($match['path'], $this->config->urls->admin) === false) $matches[$i]['editUrl'] = $match['path']; $i++; } $responseArray['matches'] = $matches; $event->return = json_encode($responseArray); }); Note that it only changes the link if the match has type of "Pages" and also doesn't point to an admin url. Let me know if this works at your end ok.

$this->addHookAfter('ProcessPageSearch::executeFor You can see here: https://github.com/adrianbj/AdminRestrictBranch/blob/838858fd36a78df808b7690b4cddcb3a6c25ffa3/AdminRestrictBranch.module#L167-L180 where I have removed items from the search results, but you could easily use array_map to search and replace edit with view links in the returned array of matches. Hopefully this will help to get you going.

Just in case someone else arrives in this thread, this is now implemented in Batch Child Editor: https://processwire.com/talk/topic/6102-batch-child-editor/?do=findComment&comment=149975

Hi everyone, For those of you running the core SessionHandlerDB module, I just committed an experimental fix for the problem of the "Redirect" bar not showing. The redirect bar can be very handy in debugging many things that may otherwise be lost when there is a redirect, so it's been a real shame for those who haven't had it all this time. I discussed the approach of my fix with Ryan and long time ago (I was hoping he might include it in the core) and this was his response to me: Basically what the fix does is when a $session->redirect is called, it now makes the header() call before closing down ProcessPageView. The current PW core behavior is to close it down before the redirect. I don't think it should be an issue for your sites to use this new version because it only makes this change if: 1) SessionHandlerDB is installed 2) The debug bar is enabled #2 in particular means that regular users won't be impacted by this at all - only users with Tracy permission (typically just superusers). However if you notice any problems at all, just add this line to your config.php file to disable it. $config->disableTracySHDBRedirectFix = true; And, of course let me know if you have problems so I can revisit my decision on incorporating this fix.

That's not a PW function, so it must be custom. You could search files for "function e(" or you could install Tracy Debugger and enable the "Template Resources" panel which shows you all custom functions (and variables) and where they are defined.

I have actually used it on an old site that I upgraded to PW 3 and it seemed to work fine. The site isn't really active anymore unfortunately (government budgets and all mean that the program is no longer active), so I haven't checked in a year, but I think you'll be ok. It's a pretty simple module.

From what it looks like, $user is the currently logged in user - this check is outside your functions, so I don't see that this is actually doing anything. The email check looks fine This should also be ok, but remember the issue I mentioned with the first line. This turns off output formatting which is important when saving fields to a page - consider a datetime - you want to save a unix timestamp, and not a formatted string like 14 September, 2017 7:17:11 am Really your call - there are arguments for both approaches. You might actually find things simpler if you try this approach to user pages: https://processwire.com/blog/posts/processwire-core-updates-2.5.14/#multiple-templates-or-parents-for-users which lets you set up users with URL accessible pages directly. BTW - a great writeup of your approach here - I am sure others will learn lots!

No problem at all - glad it got things sorted for you!

I really would try upgrading to latest dev first - that wireInstanceOf function adds a lot of extra logic that I assume will take care of things when $type is null.

It looks to me like you are running 3.0.62 (or thereabouts) as line 374 of that file looks like: } else if(strpos($type->className(), 'FieldtypeRepeater') !== false) { I would suggest upgrading to the latest dev and see if that fixes it. The new version uses this instead: } else if(wireInstanceOf($type, 'FieldtypeRepeater')) { Otherwise, we'll need to debug $field (type and name) to see what field is causing it to hang up.

Very nice!

I think you are looking for something like this. You need to be making use of the names of the repeater fields and also referencing the repeater field relative to it's containing page. foreach($l->{$f->name} as $repeater_item) { foreach($repeater_item->fields as $rf) { echo $repeater_item->{$rf->name}; } }

Yep, the old version is linked to in this post: https://processwire.com/talk/topic/7905-profields-table-csv-importer-exporter/?do=findComment&comment=150953

We already have a delete permission: Is that what you are looking for, or referring to something else?

Actually, I just noticed that Ryan is now up to v17 / v18beta - hopefully both of those should also work though. EDIT: just did a quick check with v18 and it looks to be working fine!

@Macrura Sorry about that - I should have a check in there regarding the required version of Table. When Ryan introduced pagination I had to make a lot of changes to support it and decided to no longer support older versions. This commit (https://github.com/adrianbj/TableCsvImportExport/tree/b83df4d13fd18fcb6c4bc8ac467e6ae35cba9711) was the last version to support the older version of Table, so you should hopefully be ok with that one, although please note that I have added some new features (like the ability to select the columns to export) and also some bug fixes to newer versions. I would suggest that you instead upgrade to v15 of Table.

Sorry, I mean a web dev outfit.

@SamC - depending on your needs/preferences, you might also look at these: http://modules.processwire.com/modules/front-end-edit-lightbox/ http://modules.processwire.com/modules/fredi/ https://processwire.com/blog/posts/front-end-editing-now-in-processwire-3.0-alpha-4/#now-all-fields-can-be-front-end-editable and also, Tracy comes with a "User Bar" which you can skin that links to the backend to edit the current page: https://processwire.com/talk/topic/12208-tracy-debugger/?do=findComment&comment=127824

@SoccerGuy3 - I wonder if a Modules > Refresh would help with that on your local machine - perhaps the Language Support Page Names modules didn't initialize properly?