backdrop-ops / backdropcms.org

Issue tracker for the BackdropCMS.org website
https://backdropcms.org
25 stars 20 forks source link

Project recommended release not reflected in updates.backdropcms.org #474

Open herbdool opened 5 years ago

herbdool commented 5 years ago

The recommended major version on https://backdropcms.org/project/webform is set properly but the URL used by the project installer https://updates.backdropcms.org/release-history/webform/1.x has the wrong major version for the recommended release.

I took a look at the Views on backdropcms.org and they are set correctly, so there is something not getting to updates.backdropcms.org.

herbdool commented 5 years ago

I discovered that the project installer is getting the recommended major version from the default branch on github. I'm not clear on where in the code but when I switched the default branch from 1.x-1.x to 1.x-4.x then the recommended version showed up as "4" in the XML feed.

So the settings on backdropcms.org will affect the recommended release as shown on the website, but it doesn't change it for the XML feed.

We should add some guidelines for module developers for when they want to switch major versions. But I wonder if an additional solution would have github also update the project node so that part doesn't need to be done manually.

herbdool commented 5 years ago

So, I'm not entirely sure if changing the default branch in github was the trick. I'm wondering if just creating a new release after changing the settings on the project node fixed it. Perhaps that was the only way to regenerate the release history XML file. I haven't been able to find code to confirm my initial suspicion so can't be sure.

herbdool commented 5 years ago

Here are the steps that I think helped fix the issue in order to ensure the right major version is used in the XML file and in the project node:

1) Create a new branch and release. 2) Make the new branch the default branch in github. 3) Create a new release from the new default branch. 4) Update the project node on backdropcms.org to select the new major version. (Currently developers don't have permission for this).

I'm hoping that @quicksketch can confirm if github is actually updating the XML file or if it's just a fluke: perhaps after I changed the settings in the project node the XML file only got updated when a new release was created.

quicksketch commented 5 years ago

I looked through the PHP code in Project module and I couldn't find anything that would update the default branch. I think it may have been updated manually(?)

Here's the page for updating the default branch on backdropcms.org: https://backdropcms.org/node/149/edit/releases

image

Looks like there is also a bug in the UI that the sub-tab for Releases is not shown, so you have to type in /releases after the URL to get to that page.

herbdool commented 5 years ago

Actually I had updated the "Recommended Major Version" manually but it didn't change what showed up in the installer. The XML release history file was still the old major version

quicksketch commented 5 years ago

Looks like a bug in project module. The release XML is updated on cron jobs, but only if a release has been modified since last cron run. Updating the project itself does not seem to trigger a rebuild of the XML. See _project_release_node_save() in project_release.module:


/**
 * Shared callback for hook_node_insert() and hook_node_update().
 */
function _project_release_node_save(Node $node) {
  if (project_release_node_is_release($node)) {
    // Determine the download file size if not provided.
    $is_new = empty($node->original);
    $update_download_size = FALSE;
    if (is_null($node->project_release['download_size']) || $node->project_release['download_size'] === '') {
      $update_download_size = TRUE;
    }
    if (!$is_new && $node->original->project_release['download_link'] !== $node->project_release['download_link']) {
      $update_download_size = TRUE;
    }
    if ($update_download_size) {
      $node->project_release['download_size'] = project_release_get_download_size($node->project_release['download_link']);
    }

    // Write the project release record to the database.
    $record = array('nid' => $node->nid) + $node->project_release;
    $update_keys = !empty($node->original->project_release['project_nid']) ? array('nid') : array();
    backdrop_write_record('project_release', $record, $update_keys);

    // Update supported versions on shutdown.
    backdrop_register_shutdown_function('project_release_check_supported_versions', $node->project_release['project_nid'], $node->project_release['version_api'], $node->project_release['version_major']);

    // Queue release XML generation for update status module.
    $queue = BackdropQueue::get('project_release_xml');
    $queue->createItem(array('project_nid' => project_release_get_release_project_nid($node)));
  }
}

Seems like we should probably move that last portion about adding to a queue to refresh the XML under a new IF condition that changes if either the release node or the project itself are updated.

herbdool commented 5 years ago

That makes sense. I can work on a PR to fix this.

herbdool commented 5 years ago

@quicksketch I've created a PR https://github.com/backdrop-contrib/project/pull/24. I had to also trigger the XML regeneration when the releases sub-tab is submitted: node/%project/edit/releases since that doesn't go through the hook node update/insert.

herbdool commented 5 years ago

@quicksketch Can you take a look at this when you have a chance? Project maintainers are still having problems with this.

jackaponte commented 4 years ago

@quicksketch Can you take a look at this when you have a chance? Project maintainers are still having problems with this.

Indeed, I think I've run into this problem myself with webform_civicrm!