bernhard

Just pushed a little update that makes the definition of recipes easier, see this sample: <?php $password = $this->randomPassword(); return [ 'pw' =>'https://github.com/processwire/processwire/archive/dev.zip', 'profile' => 'site-default', 'settings' => [ 'timezone' => 368, // vienna 'dbName' => 'yourdbname', 'dbUser' => 'root', 'dbPass' => $this->randomPassword(), 'admin_name' => 'youradminurl', 'username' => 'youradminusername', 'userpass' => $password, 'userpass_confirm' => $password, //'dbTablesAction' => 'remove', // overwrite existing tables? ], 'recipes' => [ function() { $this->msg('Installing RockMockup...'); $this->installModule('RockMockup', 'https://gitlab.com/baumrock/RockMockup/repository/master/archive.zip'); $this->succ('RockMockup installation completed'); }, ], ]; I also added this video to the first post to demonstrate how easy it is to use (I think all the screenshots may have made the impression that it is complicated)!

and finally this one: As you can see I was not able to fix this... Maybe you find some helpful informations in those posts though.

@Pixrael the summary is basically: Do a really bad job before with lots of foreach etc and then refactor everything to proper sql statements that join the related data together in a fraction of the time At least I'm on step two of "make it work, make it fast, make it pretty" Jokes aside: The background is that I have quite some performance issues with my CRM - there is an admin page that lists all projects and all their revenues. The revenues are themselfes pages with additional informations (like type of revenue (internal/external/etc), date and so on). This way it is possible to do all kinds of great stuff with that data (fake data here): Listing all those related items is not so easy, thats why I used regular PW api before, looping all projects, summing up all related revenues etc.; And of course that is terribly inefficient. But a lot easier than setting up SQL queries with joins, sum(), concat() etc... Since all the joins etc. are quite complex I created a little ProcessModule that will be part of my Datatables module (planned for this year) that lists the queries instantly, makes it possible to combine different views and - what stants out from regular sql tools - can interpret PHP. So you can for example create custom db views with variable setups: Resulting in this PS: Just realized that this topic went quite far from the initial title (best query for pages->find() ), so I'll change it. @adrian 's suggestion was of course on spot of the old thread title

@Gideon So very interesting topic, maybe you want to share your learnings in a post in the tutorials board?

@adrian thanks I was aware of that but I don't think it is of big help in my case. @SamC thanks, looks interesting I've always worked with PhpMyAdmin (on most hostings) and HeidiSQL (for local dev with laragon). The visual explain analyzer looks interesting though. Seems that HeidiSQL should also have this feature but it didn't work here on my first try... I'll play around with that in the future - for now I'm happy with my results since I decreased the time for the query from terrible 90s to 900ms (uncached) Thanks for all your input!

Thanks! Didn't know about that. This worked to turn it off: SET GLOBAL query_cache_size = 0; No, never heard about such tools My experience with SQL is quite limited so I'd be very thankful for some helpful links in this regard, thanks Thank you both for your helpful answers!

Great post @StanLindsey I had exactly the same thoughts... Regarding slack - I'm also not a fan, but it seems that many are... there was also one try to get a pw slack channel running two years ago: https://processwire.com/talk/topic/11475-processwire-slack-channel/

Ok today I hit a very strange problem regarding those mentioned sql queries. I built a little processmodule that shows the result of my queries. The queries themselves are stored in a PHP file which makes it possible to create different VIEWS (just like DB views) and include them easily via php's include(). Simple example: // file allpages.php return "SELECT * FROM pages"; // file publishedpages.php $allpages = include(__DIR__ . '/allpages.php'); return "SELECT * FROM ($allpages) AS allpages WHERE allpages.status = 1"; This seemed to work great, so I continued to create some more complex queries like the ones mentioned above: SELECT effort.id AS id ,effort.status as status ,(SELECT data FROM field_rockprojecteffort_date WHERE pages_id = effort.id) AS date ,(SELECT pages_id FROM field_rockproject_efforts WHERE data = effort.id) AS projectid FROM pages AS effort WHERE templates_id = 95 Template id 95 is for "rockprojectefforts", thats items for all kind of actions related to a project. So far, so good. Now the strange part: I want to create a combined listing of all projects and all efforts ( project, firsteffortdate (=when the project started), lasteffortdate (=when it ends), etc )... <?php $projects = include(__DIR__ . '/allprojects.php'); $efforts = include(__DIR__ . '/allefforts-slow.php'); return "SELECT * ,(SELECT `date` FROM ($efforts) as `efforts` WHERE `projectid` = `projects`.`id` LIMIT 1) as `fromdate` FROM ($projects) as `projects` WHERE `projects`.`status` = 1 "; This works, but it is terribly slow (3,6 seconds)! The included SLOW file looks like this: <?php // old non-performant query return "SELECT `effort`.`id` AS `id` ,`effort`.`status` as `status` /* data for the effort */ ,(SELECT `data` FROM `field_title` WHERE `pages_id` = `effort`.`id`) AS `title` ,(SELECT `data` FROM `field_rockprojecteffort_date` WHERE `pages_id` = `effort`.`id`) AS `date` ,(SELECT `data` FROM `field_rockprojecteffort_price` WHERE `pages_id` = `effort`.`id`) AS `price` ,(SELECT `data` FROM `field_rockprojecteffort_vat` WHERE `pages_id` = `effort`.`id`) AS `vat` ,(SELECT `data` FROM `field_rockprojecteffort_amount` WHERE `pages_id` = `effort`.`id`) AS `amount` /* data for the corresponding project */ ,(SELECT `pages_id` FROM `field_rockproject_efforts` WHERE `data` = `effort`.`id`) AS `projectid` ,(SELECT `data` FROM `field_title` WHERE `pages_id` = `projectid`) AS `projecttitle` ,(SELECT `data` FROM `field_rockproject_status` WHERE `pages_id` = `projectid`) AS `projectstatus` /* we also need the clientid to search for the first effort of a client */ ,(SELECT `data` FROM `field_rockproject_client` WHERE `pages_id` = `projectid`) AS `clientid` FROM `pages` AS `effort` WHERE `templates_id` = 95 "; Whereas this file works just fine (0,03 seconds): <?php return "SELECT pages.id as id ,pages.status as status ,date.data as date ,efforts.pages_id as projectid ,title.data as title FROM pages JOIN field_rockprojecteffort_date AS date ON date.pages_id = pages.id JOIN field_rockproject_efforts AS efforts ON efforts.data = pages.id JOIN field_title AS title ON title.pages_id = pages.id WHERE templates_id = 95 "; another strange thing is that both queries as single queries work just fine (one needs 0,07 seconds, the slower one 0,11 seconds - but I don't think that is the issue): I can live with the JOIN even though it is a little less readable and more complicated to setup, but I would really love to know what is going on and why this is the case. BTW: On the second reload everything is even quicker so I guess there is some caching in the background. I did not find any options for disabling the cache in the WireDatabasePDO class - could this be a mysql internal cache? Thanks for your time!

it will create a default name (database name). or are you talking about a configurable default name?

Agree - I just redirected them where I needed If it is a custom logout template you don't even need the GET variable since all it does is logging out the user...

I wanted to mention custom frontend logins... don't know why I didn't. Maybe because this would have answered my own question... Ok, that count is 0 here maybe that's why it took me a little long to get your point ^^ since the pw admin is so easy I've just not had the need to build a custom login/logout/admin for my users... Last time I did it was when I was using Joomla and this was fortunately long, long time ago

This "might" be true. But since the user is already logged in he "might" already know the admin url - where else would he have logged himself in?! But you are right, if one wants to hide the admin url for whatever reason a dedicated template or a get variable as flydev posted would be a solution. usually? sounds like you need that often?! may i ask for which purposes? I've never needed that so I'm curious thanks

I would not call it a hack if you found it in the official admintheme It's totally fine. What happens is that you execute the executeLogout() method in the ProcessLogin module: https://github.com/processwire/processwire/blob/master/wire/modules/Process/ProcessLogin/ProcessLogin.module#L195-L210 This is from the admin: echo "<li><a href='{$config->urls->admin}login/logout/'><i class='fa fa-fw fa-power-off'></i> " . $this->_('Logout') . "</a></li>";

see this example: the key is the entityEncodeText option: https://processwire.com/api/ref/inputfield/

Sorry no experience in this sector - I've had a look at https://www.mollie.com/ but never had the possibility to try it out but they seem to offer easy recurring payments.

hey jmartsch thanks for your interest and help I found the problem and did a quickfix. Seems to work now inside the root directory and also in a subdirectory: https://gitlab.com/baumrock/kickstart/commit/a68ba04c53e144ee1255faea704ab9c350b7fbe8 I have to leave now so I could not do more testing - could you please check if the recipes folder gets deleted after installation? Think I have to fix that. Also it should have thrown an error during installation, have to fix that too. But it should work now Thanks

I can highly recommend Laragon: https://laragon.org/download/migrate-from-xampp.html

Hi anyway, in my link (and the sublink) you can see two possible solutions: Open the dropdown on 1st click, open the link on the 2nd Show some additional link via javascript on 1st click In both cases you don't need to change the page structure (2 pages in the tree for 1 page would theoretically be possible with hooking/redirecting, but definitely not a good idea). Other options would be to add the parent as sub-item like you showed (parent trigger + parent). You could do this via javascript or via php. The point is that you don't modify the pagetree in the backend but you define what happens on the frontend (display). See https://github.com/processwire/processwire/blob/master/site-default/templates/_func.php#L61-L118 for an example of a custom pagetree render function.

Sorry for my delay The problem is that the touch device I am talking about is my Laptop with a standard sized screen Somehow this device behaves a little different than a regular non-touch device and it does not trigger hover actions even when a mouse is connected. Also here in the forum I have to click twice for the like-button...

Hi anyway, I think I read your post in the other thread but didn't get your point. The problem you are describing here is not processwire specific - it's a general problem related to touch and non touch devices. you can find some possibilities here (and in the linked thread):

hi thuijzer, would you mind adding a screenshot to get an instant first impression of how it looks like?

great idea, thx! needed that several times and maxLength=>... was a pain would it be hard to have the shortcut bdb() for bd($page, [6,999]) ? i think it would totally be fine to have that shortcut with fixed values since we have the other option of defining it manually like you showed above. but i think in 99% of the cases the bdb() would work just well and it is less to write and a lot easier to remember

looks interesting! so @kongondo don't you use vscode git at all or do you use vscode git for simple tasks (like shown in my screenshot) and sourcetreeapp for more complex ones? thx

wow! thank you for all your work! loving the logo - just updated my signature

Making future website upgrades more error prone and time consuming, I agree. I don't have this feeling. One of the things I like most about PW is that I don't really have to care about updates. But I agree that it would be better to have less new features pushed out every week and have a little more conversation upfront to make the result as good as possible. Yes, we should get more organized somehow. yep, my vote for better community managment here I'd be happy to help in this regard as much as I can.