adrian

Personally I have just alway felt more comfortable with JOINS so I totally understand where the OP in that SO thread is coming from Don't forget about: $rows = $result->fetchAll(PDO::FETCH_ASSOC); That will save the time required to loop through all 10,000 results to populate an array Also, you should probably be using $database (PDO), rather than $db (mysqli)

http://blog.zend.com/2017/01/10/the-state-of-php-in-2017/ Yes definitely go for 7.x

Hey @bernhard - I just quickly hacked together a new $pages->findArray() method that you can use like this: $pages->findArray("parent=12593", array('title', 'integer'), 'object'); It takes 3 arguments: selector array of fields to return return an array or object It needs to be cleaned up (eg properly bind values etc), but as you can see in the screenshot below that it returns an array of the requested fields for 5000 pages in 66ms. I wonder whether there is justification for something like this in the core? It seems like a pretty efficient way to get just the fields you're interested in without the overhead of page objects. You can obviously then do: Object foreach($pages->findArray("parent=12593", array('title', 'integer'), 'object') as $p) { d($p->title.':'.$p->integer); } OR Array foreach($pages->findArray("parent=12593", array('title', 'integer'), 'array') as $p) { d($p['title'].':'.$p['integer']); } This certainly isn't specific to your module - I am definitely going to be making use of this in the future for my sites when I need data for tables / charts, etc. Here is the hook code: BTW - the "title" field in the results below is correct to be a number - these were 5000 API generated pages with numeric titles.

Great - thanks for testing. It all seemed right here too, but it's nice to have another pair of eyes on it.

The same way Lister does - with an ASM field that lets them select fields and sort the order they will be displayed in.

If the selector is that simple, then sure SQL is easy to write. Maybe I am missing something, but my assumption is that currently the user will have to write an SQL query themselves to get the pages they want. Is that correct? If it is, then my thought was that using findIDs would let you take a selector (generated from InputfieldSelector) and then pass those IDs into an SQL that is generated by your module. That way the user wouldn't have to code anything - all GUI via the InputfieldSelector (what is used by Lister/ListerPro etc). Does that make sense, or am I still just confused about how this module works? PS - in my example above there is not actually any reason to even get the id from the pages table because you already have that (obviously). So you probably just need to get from the db tables for each of the fields that you need to present.

@Lutz Heckelmann - just realized that I should also exclude trying to insert any additional columns in case the users has copied more columns than the table has. Would you mind doing another check at your end to make sure everything still look ok? Thanks!

I completely agree - I do think it's going to be a very nice improvement for many users - thanks for the suggestions!

Hey @bernhard - glad you're going to offer both. On the use of findIDs() - I don't think I explained properly. My ideas was to take the returned IDs and build up a manual SQL query using those. Here is what it might look like this. It's rough, but it's running on 5000 pages and this returns the id and the title in 47ms and all that is needed is a simple selector - in this case: parent_id=xxxx Does this suit your needs?

Yeah, I could possibly refactor a little, but this approach seemed the simplest without messing with anything else. If you feel like optimizing things though, I always like PRs

@Lutz Heckelmann - please try the latest version - it now supports any number of missing columns on the end of the CSV/TSV

@Lutz Heckelmann - I never planned on supporting importing of CSV or TSV where the number of columns for each row is different to the table it's being imported into. I should probably have added a warning that they didn't match and not import anything. That said, maybe I should just support what you are looking for - I don't suppose there is any harm in it. I'll sort it out shortly.

@bernhard - I love the flexibility of pure SQL as well, but for those less familiar with it, I was wondering if you have experimented with findMany() ? The other option might be findIDs() - could you perhaps build an SQL query from the returned IDs to get the other requested fields? Maybe one of these options would still be performant enough and a little more user friendly? Maybe the option for SQL or a selector so users have the choice depending on their needs an skills? Just some random thoughts that might not be useful at all

The new version is great - thank you for the quick fix!

Thank you for that - I wasn't quite getting the scenario correct, so that helped a lot. I have fixed it although a little differently - turns out I can't see a need to keep rows when the value is blank, so removed that check and everything seems fine. I have committed a new version. Would you mind checking at your end also please?

Thanks for the report @Macrura - I have a fix in place here and I'll commit later today or tomorrow - just in the middle of some much larger changes.

Hi @Lutz Heckelmann - welcome to the forums! Thanks for a useful first post I have taken care of the first two thing locally (slightly different solution for #2), but I am having trouble reproducing #3. Any chance you could do a field export on the table field and also send me an example file to import so I can test. I understand what you are getting at, but I thought that the if($fieldValue != '') check was taking care of it. I can kinda see why it wouldn't but I'd still really like to reproduce the problem so I can be certain of the solution. Thanks.

PS - I decided to see what Ryan thinks: https://github.com/processwire/processwire-issues/issues/459

Hi @matjazp - I discovered a bug when you have blank lines at the top of your file. Because you are using a PW InputfieldTextarea, the blank lines at the top are trimmed, here: https://github.com/processwire/processwire/blob/aa1f7dbd4718532896e209d694db0340c2d30067/wire/modules/Inputfield/InputfieldTextarea.module#L119 The problem is that when you save, these lines are removed. This probably won't ever cause any issues, but I don't think it's polite behavior for this to happen unexpectedly. The other issue relates to my new feature in Tracy which allows opening up errors/files to an exact line number - the line number can be off because of this bug. I actually wonder whether maybe the PW textarea shouldn't do that in the first place. What do you think? I think blank lines at the top should be valid? If you think this is a PW bug, or if you think there should be an option to not remove them, I'll file it with Ryan. Otherwise, maybe ProcessFileEdit needs to use a standard manually coded textarea. Any thoughts?

I think it's an oversight that should be fixed - I think you should post a Github issue for Ryan to think about. He may not agree but I think that is the best way forward.

I agree that it should sort this out itself, but just so you know, a Modules > Refresh is the correct way to fix this. As for clearing caches in general, take a look at: https://github.com/somatonic/ClearCacheAdmin - much more elegant than just deleting that table.

Do you have the config setting for the snippet runner pointing to the correct folder - remember there are two options?

Hey @tpr - I just noticed that AOS removes the 3px border radius on Page List Action buttons. Is there a particular reason for this? Is it just a stylistic choice on your part, or a remnant of some old code? No big deal, just thought I'd ask

I am tempted to add this to Tracy

I know this post is ancient, but I went to use Migrator today and experienced the same problem. I have committed a fix that seems to be working fine. If you or anyone else is still interested in this module, please let me know how the new version goes. I am still not certain about the future of this module, especially now that the PW core has template, field, and page export/import, but to be honest I think Migrator currently handles more field types and of course has the added benefit of dealing with field, templates, and pages as one entity and takes care of them all for you. I am curious if others have used the core import/export features and how successful they've been and whether you'd still prefer and all-in-one solution like Migrator and whether you'd consider paying for it. I think I would want to do a considerable rewrite if I went this route, but I am really not sure what the demand is.