bernhard

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?

I think you would need a login for the clients then. You can do shopping history with cookies - but I doubt how useful that would be... as dragan already mentioned users can switch devices and the history would be lost... true, thx

I've done something like this using cookies: https://www.grafikgesellen.at/textilien/textilien-mit-wunschdesign/t-shirts/ I'll showcase the site as soon as they've launched it. Any feedback already welcome (don't want to intercept this thread though ). This one sounds a little more challenging. I think you would need a login for the clients then.

don't know if this site was already posted or where they get their data from, but maybe it is interesting for someone: https://trends.builtwith.com/cms/ProcessWire/Market-Share

At the moment I have loads of other things to do that have priority, sorry. Maybe if you implemented the save/open feature it would already be usable? Should not be that hard..

no "ironic" tags... and not even in the pub... *uff

@tpr seems he is already using it

Fixing the error is no option? I can imagine there are situations where fixing is not the best option, for example I just created a filter for my mailbox that deletes warning emails about AIOM warning In this case fixing the issue would mean hacking this module, what I do not want to do. On the other side those warning e-mails are annoying, so I came up with the filter solution (deleting e-mails containing "AllInOneMinify.module:713"). So I still get other warnings but don't get annoyed by this special one. Maybe that's also an option for you? Fatal error sounds a little more serious though than my php warning