Increase the value for items_per_page used by installer_manager_install_form_validate()

[docwilmot]

Description of the bug

I thought there was an existing issue but I cant find it.

There is a line of code in installer.manager.inc that explains that we have no way for the Project Installer server to query and return all project nodes on the main site, so we query with a large project number (999).

We're now at 991 projects total and growing, so at some point soon, that tactic will start to fail.

Steps To Reproduce

See link above. I'm filing as a bug, though it currently isn't really, because eventually it will fail, and currently it is a bit of a kludge.

[avpaderno]

installer_manager_install_form_validate() first queries for 999 modules, then 999 themes, and last for 999 layouts. There are 734 modules, 38 themes, and 10 layouts.

If the number of modules is going to grow fast, that limit could be increased to 9999.

[avpaderno]

Actually, that isn't necessary, since https://projects.backdropcms.org/query/module/1?method=query&items_per_page=2 returns the total number of modules, and it accepts a page number, as in https://projects.backdropcms.org/query/module/1?method=query&items_per_page=2&page=2. Still, the code to query for 9999 modules is simpler than the code to query for 999 modules until all the modules are queried.

[docwilmot]

I think the original issue title was more accurate to describe my intention: create a way to retrieve all projects, optionally of a certain type. We can do this by skipping the query filter in borg_pbs_project_browser_server_query(). So:

  if ($items_per_page != 'all') {
    // Only send back the requested amount unless all projects were requested.
    $start = $filters['page'] * $filters['items_per_page'];
    $count_query = $query;
    $count_result = $count_query->execute();
    $query->range($start, $filters['items_per_page']);
  }

And optionally skipping the type query:

  if ($type != 'all') {
    // Filter out projects based on type unless all types were requested.
    if (isset($filters['type'])) {
    $query->condition('n.type', 'project_' . $filters['type']);
  }
}

[avpaderno]

The title didn't match what the issue reports. The title was Add function to get all projects on BackdropCMS.org, but the issue is about installer_manager_install_form_validate() that queries for 999 modules assuming there aren't more than 999 modules.
If then the code is refactored and a new function created, that is secondary.

[docwilmot]

Apologies then, the issue was misnamed. Maybe "Add a way to get all projects..." The reference to installer_manager_install_form_validate() was meant to be an example of the shortcut we need to do to get all projects.

[avpaderno]

I apologize: Given where the issue was posted and the link to the Backdrop code, I took this was a issue posted for Backdrop code. It seems you meant to post an issue for the code running on backdropcms.org, which should be posted on the other project.

[avpaderno]

Actually, there are two issues: the impossibility to query all the projects at once (instead of querying for modules, themes, and layouts), and the assumption that there aren't more than 999 projects (or modules, themes, and layouts).

I think that both the issues should be addressed. We can keep this issue for the 999 limit to change the Installer module code.

[docwilmot]

Ahah I forgot to check backdropcms.org issue queue. This had been mentioned before there backdrop-ops/backdropcms.org#870. I'll create a proper issue there. Thanks.

[docwilmot]

Theoretically we are way past the number of projects that would make this a significant issue. We're approaching 1200 total repositories and the Installer only fetches now 999 at a time. I think the fix at backdrop-ops/backdropcms.org#947 is a better fix than keeping the awful code at https://github.com/backdrop/backdrop/blob/1.x/core/modules/installer/installer.manager.inc#L677. I'm happy to advocate this so it gets moving.