Add download buttons for Drupal

Here is an indented and commented example:

<div class="download-links">
  <!-- Change 'title' and 'href'. -->
  <a class="download-link download-latest" title="Download Drupal 6.3" href="drupal.tar.gz">
    <span>
      <!-- Change 'strong' tag content -->
      <strong>Drupal 6.3</strong>
      <!-- Change '1' to the actual file size, Megabytes, MB and .tar.gz according, if needed -->
      <em>(1<abbr title="Megabytes">MB</abbr>, .tar.gz)</em>
    </span>
  </a>
</div>

It's important to remove line breaks, spaces and comments to prevent html filter from introducing <p> and <br /> tags, so the above code would look like:

<div class="download-links"><a class="download-link download-latest" title="Download Drupal 6.3" href="drupal.tar.gz"><span><strong>Drupal 6.3</strong><em>(1<abbr title="Megabytes">MB</abbr>, .tar.gz)</em></span></a></div>

Add this to the first line of node body, so the button will float to the right.

Also it's important to reset css aggregator cache. To do so, disable and re-enabled css aggregation on admin/settings/performance.

This is for the release announcement nodes, such as http://drupal.org/drupal-6.3 ?

"This is for the release announcement nodes, such as http://drupal.org/drupal-6.3 ?"

This is for http://drupal.org/project/drupal for now. In the long run, I guess, it's better to patch project_* modules to make them generate buttons markup of latest project releases.

By the way, it's missing the button image on bluebeach folder. Someone need to copy download-button.png supplied on this issue to bluebeach theme folder. And it should be accessible as http://drupal.org/themes/bluebeach/download-button.png.

Attached is a screenshot of how the buttons should look.

In that case, I'm tempted to "won't fix" this issue...

A) There's already a table of download links. If you don't like how that looks, there are plenty of theme functions involved that let you customize it at various levels: theme_project_release_project_download_table(), theme_project_release_download_table_row(), etc.

B) There are many reasons why a single download button doesn't make sense. Even on Drupal core, it's not obvious that new users want to start with the 6.x version right now, as lots of contrib still isn't ported and stable yet. In contrib, there's not only the question of different versions of core available, but different branches for each version of core. Once upon a time, there was a notion of the "default release" to download, but that was insufficient and was replaced. Lots and lots of thought and effort went into the current download UI, and nothing here takes any of that into account. This is a step backwards.

C) Manually updating this HTML is additional maintainer work and highly error prone. These download buttons shouldn't be the N+1th thing that Dries/Gabor/Drumm et al have to remember when they cut a new core release.

All that said, I don't want to stomp out anyone's initiative to improve things, so I'll leave this issue open for further comment. If Dries/Gabor/Drumm/etc want to manually maintain this on the Drupal project node, I won't stop them. But, I think this is headed in the wrong direction...

Nice analysis. The browsing pages are indeed weird and confusing, especially the "Drupal" project type. That's not what I'm talking about. Before you get hostile and defensive about my comments, please read them for the content they contain. If you want "actionable tasks" to make the download UI better, don't just cobble together something stupid that requires manual effort. I didn't say "you can't change this because the project module doesn't want you to". I explained why this particular attempt at improving things is a step in the wrong direction. Feel free to ignore my input. Knock yourselves out.

I am committing what is in the drupal.org checkout to the private CVS repo.

I think this issue needs revised attention based on the new redesign.

In the prototype some of the green download buttons say just 'download drupal' others reference the actual version number inside the button, and in some cases the links doen't go anywhere, so its open to interpretation on how to implement it in various places. On the existing site, it looks like the download links on the sticky node on the homepage are just hardcoded into a node when a new release is cut.

With the advent of the many new dynamically-updating pages like Get Started, About, Download & Extend, I'd say the "green button" could also be generated dynamically.

I think we need a usability expert's decision here, is it better to link directly to the latest download? or link to the download page? if the former, should the text be standardized across all implementations (Eg. 'Download Drupal' or 'Download Latest Version')

How can we standardize on the download link to ensure everyone's page sees the same link? This sounds like prime candidate for a very simple block. The block might have the option for 'simple' or 'complete' mode, where simple gives you just the green button, and complete mode gives you the \ button plus other small links below to other releases (seen in some places on the prototype but not others).

Also, while on the subject, what about introducing the quite useful and long-standing software download tradition of a dynamically updating download link alias to latest stable eg 'http://drupal.org/drupal-stable.tar.gz'... If we make that url the address of the green button, I guarantee people will notice it and start using it and linking to it directly.

Granted, it may not be obvious what version power users are going to need, but the same power users also already know exactly where to go to find the version they need. So providing the most "recommended" version as drupal-stable.tar.gz makes perfect sense.

Can we simply re-implement a prettier version what's seen on the front page of Drupal.org (see attached)? This could be done programatically so that the text and links are automatically updated. Markup would be handled using a .tpl file defined by the appropriate module.

If automatic updates are difficult because the notion of the "most recent" version of Drupal requires human intervention, we can provide a tool to change this information in all instances throughout Drupal.org.

I wasn't present for the earlier debates regarding the download UI. According to dww, "lots and lots of thought and effort went into the current download UI," and I certainly don't mean to discount that effort. However, a single download button for the most recent release of each branch (6.x, 5.x) is a necessity. Anyone thinking more deeply than "I wanna download Drupal quick" can be sent to the Drupal project page or some other resource that can help them weigh their options.

Have we come to a consensus on how to implement this? This feature will affect various implementers working on the redesign effort.

Also, should keep this issue #371959: Download drupal button & input format in mind (regarding an input filter that might take advantage of the same code to render its 'replacement text' to generate the download links).

The redesign explicitly omitted download buttons on the front page and Mark and Leisa provided extensive feedback on why is that the case (executive summary: let people know the flow of how they can make use of Drupal => see http://drupal.markboultondesign.com/iteration11/getstarted.html). The download button appears at multiple places (about page, getting started page), but is not supposed to appear on the front page. The front page is supposed to direct people to the getting started page, which explains that there is stuff beyond the bits downloaded and if they are lost, there are plenty of opportunities to continue.

as it stands the download button (including drupal version number) is hardcoded into the template page (see drupalorg-about.tpl.php @ line 105), but elsewhere (drupalorg-start.tpl.php @ line 10) its partially 'automated'.

From what I can gather based on the preprocess variables being exposed in drupalorg module (see drupalorg.module @ line238), the idea would be to replace template files instances of the Download Drupal link (like in the the tpl referenced above) with something like:

<a href="#" class="link-button"><span>Download Drupal <?php print $version; ?></span></a> 

The question though is, since this button will be used throughout the site, on various different redesign pages, doesn't it make sense to encapsule the generation of the button link in a hook_theme() function instead, and automate the generation of latest_stable_version from project release module information?

<?php
function theme_download_drupal_link() {
   $version = drupalorg_get_latest_stable_version();
   return l(t('Download Drupal @version', array('@version' -> $version)), 'download', array('class' -> 'link-button'));
}

function drupalorg_get_latest_stable_version() {
  $project_nid = XX; //nid of drupal project
  $api_tid = XX; // project_release api tid
  $recommended_major = 6;
  return project_release_get_current_recommended($project_nid, $api_tid, $recommended_major);
}
?>

is this valuable? is this a valid solution?

This seems like a fine solution from a theming standpoint. My only suggestion would be to provide a configuration page that allows a Drupal.org webmaster to change the latest version number and download link through the UI instead of editing and committing code. This call should be made by the webmaster and/or infrastructure teams, of course.

Automating that is the way to go. We have all the information we need in the project database already, there is no added value in doing that manually.

The correct status is actually "Need work", because we need to implement this now :)

I like the idea of a config page in admin UI.

Should then the $recommended_major version (ie, 6) be exposed, and let project module handle the updating of the minor versions as they get cut, following the code sample in #14?

crap, sorry...

dang it.

Reassigning out of webmasters.

Tagging.

As the code is going to be in the custom module used for Drupal, I don't see any reason for a settings page; it could make sense, though, if the version schema is changed in the future (in the same way it has been changed from version 4.7 to version 5.x, where the first used version numbers like 4.7.3).

I was offline for about 2 weeks, just catching up on issues now. Yes, the skeleton code in #14 is on the right track. It'd be dumb to have an admin UI for the latest version from a given branch. However, it would make sense to have an admin UI (or at least a value to place in settings.php) to select which branch is used by default (e.g. currently 6.x, in a few months, 7.x, eventually 8.x, etc). A "recommended core release" variable might come in handy in other places on the site, too...

Some other issues seem to have solved this.