bernhard

Thanks adrian, I also noticed that but it seems it was too late yesterday... forgot to check if there are any closures to execute so it loaded all the page objects even if there were no closures please check the update: https://gitlab.com/baumrock/RockSqlFinder/blob/master/RockSqlFinder.module.php#L59 Very interesting (and great imho) is also this test using closures: So, of course with closures it is a LOT slower (because we load the page objects in memory), but the additional costs for each closure are less than for the first one. Thats because the page is already available in memory after the first closure: https://gitlab.com/baumrock/RockSqlFinder/blob/master/RockSqlFinder.module.php#L62-63 And finally one with "images:description" syntax: And insanely fast without the closure @all Any ideas wich character to use for image field descriptions (and maybe other fields)? At the moment I'm using the pipe, but that would lead to problems when a user uses the pipe for descriptions (see the above screenshot) For file- and page fields the pipe should be fine because we could use it directly for further selectors and files should not contain any pipes.

made huge progress on this Example query with all the features: $pages->findObjects('template=item, limit=100', [ 'title', // page title field 'field1', // regular textfield '(SELECT #data# FROM field_field1 WHERE pages_id = pages.id) AS `sql`', // custom sql query (multilanguage) 'images:description', // imagefield + description 'pagetest:status:created:templates_id', // pagefield + page status + created time + template id 'pagetitle' => function($page) { return $page->title; // example of a closure }, ]); Explanation: regular textfields can easily be queried just by defining their name as string any custom sql query is possible, even multilanguage when using #data# keyword images:description syntax works for all file fields page:status:created works for all pagefields and last but not least a very nice helper for fast and easy queries and small amounts of data: closures Output (default language): And the same query as datasource for a datatables field: This will be really, really awesome @theo I plan to add a lot of other stuff to my datatables module and that will take some time. I put the new pageFinder in a separate module. You can have a look here: https://gitlab.com/baumrock/RockSqlFinder Maybe you want to test it? Also @adrian might be interested? Currently it supports FieldtypeText, FieldtypePage and FieldtypeFile - but it should be easy to add others... Like Repeaters for example. Any other fields could be queried via custom SQL queries... And for really complex joins there will be another module

thanks for pointing me to the github issue. how do you guys keep track of those issues on github? I subscribed once but it was just too much to follow. Is there a way to search pw issues on github properly? or do you use google to search? btw: it is not fixed for me with ajax loaded fields. I added a comment on github.

Very strange one... I have 2 Fields set to 50% in template context (here a screenshot of the default profile). In the default admin it works as expected (headline + summary side by side), but in the uikit theme they are not the width that they should be Any ideas? I thought this might be AOS but I tried it on a fresh DEV installation and same result.

almost missed that post. thanks, adrian, #360

+1 for selectable default value and yes/no switcher with custom labels

Thanks, would be interesting to see how your example looks like on the frontend. Maybe you have a screenshot?

Yep, that's not the intention. I just asked to see if I missed any culprits. Now I'm offtopic: You know about PW's caching tools? https://processwire.com/api/ref/wire-cache/

array makes two things possible: add custom sql queries as sub-queries (don't know if that would be useful in some cases? or unnecessary?) add pages:status syntax - this makes a lot of sense to me, because I've come over this problem a lot with tables where you want to know the status of the referenced page. you would need joins for that and using a subquery could make it possible to avoid this complexity. have to make performance tests though. Why not? Or what exactly? Jep, can imagine that it shines here

Ok, took some time but now I get your point And I like it! This could definitely speed things up and make things a lot easier. Not sure how to implement this properly, though. We have different table structures for some fields. The first and easiest is for a simple textfield: pages_id | data then we have image/field fields: pages_id | data | sort | description | modified | created then we have option fields: pages_id | data | sort So if I understood you correctly, you are suggesting something like this: $pages->findArray('foo=bar', [ 'mytextfield', 'myimagefield:description', 'myoptionsfield:title', ]); Resulting in an output like this: array (5) mytextfield => "demo page" (9) myimagefield => "foo.jpg|bar.jpg" (15) myimagefield_desc => "my foo image|my bar image" (25) myoptionsfield => "1|2|4" (5) myoptionsfield_title => "option 1|option 2|option 4" (26) Right? What if we changed this a little bit and used arrays. See the examples below: $pages->findArray('foo=bar', [ // examples below ]); // simple textfield // request: 'mytextfield' // return: data column of this field 'this is some text' // image field // request 'myimagefield' // return 'foo.jpg|bar.jpg' // image field with more requested info // request 'myimagefield' => [ 'description', 'sort', 'mycustomsql' => 'SELECT ... FROM ...', ], // return 'myimagefield' => 'foo.jpg|bar.jpg', 'myimagefield_description' => 'foo desc|bar desc', 'myimagefield_sort' => '1|2', 'myimagefield_mycustomsql' => 'x|y' // simple options field // request 'myoptionsfield' // return '1|2|4' // options field more info // request 'myoptionsfield' => [ 'title' ], // return 'myoptionsfield' => '1|2|4', 'myoptionsfield_title' => 'option 1|..2|..4', // custom sql field // request 'mycustomsqlfield' => 'SELECT ... FROM ...', // return 'mycustomsqlfield' => 'some return value', // page field // request 'mypagefield' => [ 'pages:templates_id', 'pages:status', ], // return 'mypagefield' => '1010|1011|1012', 'mypagefield_templates_id' => '44|45|44', 'mypagefield_status' => '1|1|8192', Some notes: If a simple string is requested, the "data" column of this table will be returned (or data1234 for multilang fields) all concatenated fields MUST be sorted via the sort column in order to have a consistant sort order across multiple array items What if image descriptions are empty? Would it still work? If a key => value is requested and the "value" is an array we do sub-queries if the subquery has a colon we query this table instead of the current field's table (pages:status instead of mypagefield:status) This should give us a lot of flexibility, I think. For more complex scenarios we will still need to use joins. I've already started working on a proof of concept SQL editor module: With both tools in our hands I think it will be quite easy to query all the data we need and it will still be quite simple to use. @adrian I would be very interested in your opinion about this

The method could just be another option for find(), just like findIDS and findMany etc. exist. It will be simple for basic usage and offer the option for custom SQL queries for advanced use. I plan to implement it like this (pseudo): $pages->findArray('template=foo, sort=bar', [ 'field1', 'field2', 'url' => 'SELECT GROUP_CONCAT($data SEPARATOR 0x1D) FROM field_$f WHERE pages_id = p.id) AS $f', 'desc' => 'SELECT GROUP_CONCAT(description SEPARATOR 0x1D) FROM field_$f WHERE pages_id = p.id) AS $f_desc', ]); field1 and 2 would be simple, url and desc are an example of advanced use.

Totally fine, I enjoy the discussion (and added this tag to the thread title). Your example shows that the findArray method would be useful not only for the datatables module but also for other scenarios. I think it would be a good addition to the core (as already mentioned by adrian). I'll work on this next week and make a PR ans see what ryan says. For reference, here is info regarding the limit for WHERE IN(...): https://stackoverflow.com/questions/4275640/mysql-in-condition-limit

I plan to do so, yes.

It's still the version linked above. I only added the comment for the early exit if no pages are found. Which fieldtypes do you need support for? It's very easy to add your own Fieldtypes to the switch statement. Any contributions are welcome. I'll start working on the module in the next days and I can start with that function as it is very important for the module. Though, as I said, it's already very easy to modify it to your needs and you don't have to wait for my version..

hi @ukyo thanks for the phpmailer module - I've built one my own since I was not happy with the other options, but it was not polished enough to release it I'm not sure, though, what is the difference between your inputfieldhelper and the default module config? https://processwire.com/blog/posts/new-module-configuration-options/#using-an-array-to-define-module-configuration you can also add fields to a form via array:

Nope, but added a comment in the related thread. I'll start working on the datatables module very soon and implement that check thx @theo what is "a lot"? just curious

glad it helped

I guess you might find my tutorial and blog post useful: https://processwire.com/blog/posts/building-custom-admin-pages-with-process-modules/#handling-user-input-using-forms-amp-inputfields

jep, i guess you already read it, but just to be sure: https://processwire.com/docs/security/file-permissions/

Hi Jester and welcome to the forum, not sure what could be the issue, but I guess it would help if you provided more infos for us. What steps did you take (sometimes writing down the steps already leads to an "aha" moment )? What is working (I guess the admin works just fine as you say you tried changing settings), what is not? Maybe add some screenshots? Maybe look into the error logs of your site (/site/assets/logs/...). And my #1 developer tip: Install Tracy Debugger and see if it shows you anything helpful

Thanks for sharing. I've also worked with vagrant for some time, but then I switched to laragon thanks to a post of lostkobrakai here in the forum and I'm super happy with it. I'm not recommending to switch, but maybe it's also interesting for you

Ah, sorry, didn't know that. I'm not using either one. I thought there was just one search and he missed that sentence.. thanks for clarifying.

@noelboss don't know your exact scenario but you could maybe use something like FEEL or the pw-panel or just an iframe to achieve that?