adrian

You might also find the AdminActions module useful if you get in this situation again. The "Page Active Languages Batcher" to the rescue:

I am actually wondering if you might be better off not relying on ajax calls for each filter step. Have you considered storing all the details of all trees in a wireCache'd JSON object that you load up when the page originally loads and then filter through that in memory? I have done this before - I have 3MB of data in JSON which is cached, I make sure that data is transferred compressed (so it's only a couple of hundred KBs). The initially page load takes a couple of seconds, but after that, the filtering is instant. I think so long as you know that the data will not expand to an outrageous size, this might be a good approach. PS - Great looking site!

Hey @bernhard - I love what I see here, but I am curious how the data is stored? I assume it links to a custom db table that you create manually? As an aside in my pre-PW life I used SigmaGrid (which was ahead of its time) in the admin of my custom CMS to handle display/editing of purchases from an online store, so I am excited to play around with this when it's ready.

I would say that it's been many years since developers had to worry about a site not working without JS. Back in the early 2000's it was considered evil and we did all sorts of things to avoid using it (and to make sure we used graceful degradation techniques), but these days there aren't many sites that you can use without it even on the frontend, so expecting it for the backend of a site shouldn't be an issue at all anymore. Facebook does this: but you guys should take a look at the old "m.facebook.com" site with javascript disabled - it looks ancient

Nice approach indeed!

Just a quick note here - I have seen the same "Fieldtype does not exist" error in other circumstances also, so it's not just to do with ProcessExportProfile. I didn't read thoroughly through this thread, so maybe you guys already figured that out.

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