Button to prepend the 'Issue summary standard' template into Issue body.

* The summary-original-report section is not relevant when creating a new issue.

* I don't really like that the template is automatically added for new issues.

--
just my 2 cents

Okay I totally didn't find this issue and hacked it up myself, but here's my version of this functionality. It's probably kinda gross (rather than looking up the template, I just stuck it in an escaped string of barf), but worth a look for comparison? It scrapes for the original poster's username and automatically inserts a profile link; kinda nice.

I don't bother inserting the template in new issues. You can create an issue with a blank body and then just click the edit link. Alternately, could just add the button on the node add form as well.

I'll work on incorporating @clemens.tolboom's functionality into my patch, plus adding buttons to the normal add/edit pages, without the final header on add pages.

I think this functionality is pretty important. I started to write up a slideshow about contributing summaries today and realized the current workflow is actually stupid-complicated. I'd rather be able to say "install dreditor." :)

Much nicer patch parsing from the actual document as in @clemens.tolboom's version. Try it out! The button adds the "original report by" header with a link to the original poster on edit, but on add, it just inputs the other headers. It doesn't do it automatically.

It also doesn't insert the notes in parentheses. If you're using dreditor, you are experienced enough to read the doc or figure it out on your own. :)

I did notice the GET requests are kinda slow sometimes. We might want to cache the template markup somehow. For now, though, I think this is a whole lot better. :)

Edit: aside from the hunk of trailing whitespace. sorry. I'll fix that.

W/o gross whitespace.

+++ b/dreditor.user.jsundefined
@@ -1360,6 +1360,65 @@ Drupal.behaviors.dreditorIssueSummary = function (context) {
+  $('body.logged-in.page-node.node-type-project-issue #edit-body').once('dreditorIssueTemplate', function() {
+      addTemplateButton(1);
+  });
+
+  $('body.logged-in.page-node div.project-issue #edit-body').once('dreditorIssueTemplate', function() {
+    addTemplateButton(0);
+  });

It occurs to me a couple inline comments explaining what's going on here might be helpful, but I'll wait to see what others say about the patch as a whole. :)

how i can computer? why is blue? views? modules? wtf?

With reasonable code documentation.

Changed the injection to prepend instead of append.
Added XRef to sandbox and quick install.

(xjm) Described status with current patch in #16.

Updated issue summary.

I looked; I don't see my patch in your sandbox? And I'd checked earlier and the last commit was back before your remark in #9. So I added that note to the summary as well... please clarify.

Please give the patch a try; it's fully functional. :)

Mmm, just touching up funky indentation. (I think? jQuery indentation gives me brain freeze, and it's not even yummy like ice cream.)

#16 is not in the sandbox?

Updated issue summary.

#22 / #23 -- I removed the feature to automatically insert on new node creation because people above stated that it was annoying, and I'd agree with them; and it takes no additional effort to just click the button. Also, I disagree entirely about the parenthetical instructions, for two reasons:

1. People who use dreditor are savvy enough to learn what to put in each section if they don't know, and it's just an extra annoyance to delete them each time.
2. In my experience in mentoring summary contributors, people tend to leave the parenthetical instructions in and I have to keep telling contributors to delete them.

I guess I did not mean this as a patch against your sandbox, which I gather is something of a feature fork of dreditor; I meant it for inclusion in the main script.

I do think adding a link to the template after the button is a good idea and I will reroll #19 to that end.

Please test against the main branch of dreditor. Let's wait for a third opinion on whether or not the parenthetical lines are included, etc.

But #21 is missing all my comment cleanup and my change to the once() behavior? My patch was already based on your earlier patch.

Edit: I really don't understand; my patch applies cleanly, and is essentially the same thing as #21 but refined. It works without a hitch in my testing and it's easy to read and follow.

What is needs work here? What is not correct about the patch? Do you have any specific patch review? Did you test it?

I'm very sorry; I don't intend to be rude... what I don't understand is that #21 discarded all the changes I'd made in #13 through #19, without any explanation as to why they were discarded. I'm not sure how that's different? Like I said, I already started from your patch earlier in the issue.

Had a possible insight a moment ago... Are you just asking for this?

Edit: If you want, I can explain each "change" as well (though all except the insert template link are changes that you discarded from #21). Like I said in the message I left in IRC, I think we're just not quite communicating. Please just explain what you are asking for. :)

We could replace this argument by just testing for emptyness of the issue body right?

Or change the name to a boolean isNew

Hm, well, the issue body could be empty when you are updating it, or could already have things in it when it is new, but we still don't want it to try to load the node page if it doesn't exist yet. So I think the boolean option is better.

Though, I wonder if maybe we should just check the current URL for node/add/project-issue. It might also be cleaner to parse the issue link from the URL rather than looking for the view tab.

Attached patch simply checks the URL for whether we are adding or editing and for the link to the node page. I think this is more robust than relying on the DOM, and probably more performant as well. The code is also a lot simpler.

Updated issue summary.

Updated issue summary.

Mmm, the image filter is not liking the screeshot for me, so here it is again.

Adding screenshot.

Updated issue summary.

I tried out the patched Dreditor and it works as advertised, in the summary Edit popup and also in node add/edit forms. Great work :)

Unrelated: the Edit popup could use a close button!

Patched code works as advertised.

Code looks solid (though it'll need to be updated quickly if the issue summary template page ever gets reorganized or something - it might be better to edit that page and add a really unique class name to the code block and find it based on the class).

I'd say that's probably of minimal concern though. I'd also say RTBC :)

Updated issue summary.

+++ b/dreditor.user.js
@@ -1360,6 +1360,94 @@ Drupal.behaviors.dreditorIssueSummary = function (context) {
+Drupal.behaviors.dreditorIssueAddEdit = function(context) {

1) dreditorIssueSummaryTemplate

2) [and elsewhere] There should be a space after function and before the opening parenthesis for anonymous functions to make clear that it's not a function with the name function.

+++ b/dreditor.user.js
@@ -1360,6 +1360,94 @@ Drupal.behaviors.dreditorIssueSummary = function (context) {
+   * Fetches the node to retrieve the original poster's name and profile link.
...
+    // Try to find a path to the node from the URL.
+    var node_path = location.href.match(/^.*node\/[0-9]*/);

It's not clear to me why we need to reload the node view page.

+++ b/dreditor.user.js
@@ -1360,6 +1360,94 @@ Drupal.behaviors.dreditorIssueSummary = function (context) {
+  var getPoster = function() {
...
+  var injectTemplate = function() {
...
+  var addTemplateButton = function() {

Abstraction into private/locally defined anonymous functions like this doesn't really make sense. They are not callable from elsewhere. And since they don't take any arguments, they also don't really provide atomic functionality. At minimum, they should take context as an argument; but to make any sense as separate functions, they should take explicit arguments to act on and also possibly return something useful.

In this current form, these functions are merely wrapping chunks of procedural code into code blocks without any purpose, which actually makes it harder to understand what's going on.

Either we turn them into real functions with proper arguments and possibly return values, or we drop them entirely. Personally, I'd rather go with the latter.

+++ b/dreditor.user.js
@@ -1360,6 +1360,94 @@ Drupal.behaviors.dreditorIssueSummary = function (context) {
+        var link = $(data).find('div.node > div.submitted a');
...
+        var new_link = '<a href="' + link.attr('href') + '">' + link.text() + '</a>';

1) [and elsewhere] Variables that are jQuery objects should have a $ prefix; i.e., $link in this case. All other variables without; e.g., $new_link in this case.

2) For the link text, we want to use .html() instead of .text(), because we are inserting the value back into a HTML document.

3) [and elsewhere] The variable names could be a bit more self-descriptive than "link" and "new_link".

4) [and elsewhere] In JavaScript, we use camelCase variable names.

+++ b/dreditor.user.js
@@ -1360,6 +1360,94 @@ Drupal.behaviors.dreditorIssueSummary = function (context) {
+    // Load the issue summary instructions.
+    $.get('http://drupal.org/node/1155816', function(data) {

I wonder whether we can prevent jQuery from sending cookies, so we get the cached version of that page?

+++ b/dreditor.user.js
@@ -1360,6 +1360,94 @@ Drupal.behaviors.dreditorIssueSummary = function (context) {
+      // Insert blank lines and strip parenthetical comments.
+      text = text.replace(/<\/h3>/g, "</h3>\n\n\n").replace(/\(.*\)/g, "").replace(/\/\/.*\./,"");

Would it be possible to have an already prepared issue summary template for pasting on that handbook page or a child page of it?

+++ b/dreditor.user.js
@@ -1360,6 +1360,94 @@ Drupal.behaviors.dreditorIssueSummary = function (context) {
+    // We want to append the button in the label area.
+    var $label = $('label[for="edit-body"]');

This is going to clash with the commit message button, no?

+++ b/dreditor.user.js
@@ -1360,6 +1360,94 @@ Drupal.behaviors.dreditorIssueSummary = function (context) {
+      .text("Insert template")
...
+      .text("Issue summary standards");

Single quotes.

+++ b/dreditor.user.js
@@ -1360,6 +1360,94 @@ Drupal.behaviors.dreditorIssueSummary = function (context) {
+    $action.wrap('<span>&nbsp;&nbsp;</span>');

Wondering whether this is really needed? Thought there were generic CSS classes for aligning Dreditor buttons... but not sure.

+++ b/dreditor.user.js
@@ -1360,6 +1360,94 @@ Drupal.behaviors.dreditorIssueSummary = function (context) {
+    // Add a link to view the issue summary instructions.

It's not clear to me why we're adding this link to the instructions... doesn't that exist already?

+++ b/dreditor.user.js
@@ -1360,6 +1360,94 @@ Drupal.behaviors.dreditorIssueSummary = function (context) {
+    var $instructions = $('<a>')
+      .attr('href', 'http://drupal.org/node/1155816')

1) I think we can simply define the attributes and link text in the HTML string instead of working on the object.

2) target=_blank might make sense, as we don't want to lose potentially existing input.

Yay, thanks for the review! Couple followups to #41:

It's not clear to me why we need to reload the node view page.

This was to scrape the username and profile link for the original poster. This information isn't available on the node edit tab that I could see. Is there a better way to get it?

Would it be possible to have an already prepared issue summary template for pasting on that handbook page or a child page of it?

This is a good point; I'll look into this.

This is going to clash with the commit message button, no?

I don't think so? I'm running my patched version currently, and both the template button and the commit message button seem to work fine. Also, one is on the comment form, whereas the other is on the node edit form.

Wondering whether this is really needed? Thought there were generic CSS classes for aligning Dreditor buttons... but not sure.

I was wondering that as well. I'll try removing it and see if anything breaks.

It's not clear to me why we're adding this link to the instructions... doesn't that exist already?

It's only available on the normal node edit page (and not in the inline editor). It's also kind of hard to see on the normal node add/edit page; we are moving it to a more obvious/intuitive spot. See screenshot:

I'll reroll the patch with the other cleanups from #41.

IIRC, the dreditorIssueSummary "inline editor" behavior explicitly hides the dsm() that contains the link to the issue summary instructions. We might want to reconsider that.

Here is what the node edit tab looks like. The links indicated by red arrows are to the same page:

I don't think we want the whole huge blue box on the inline editor. On the other hand, would it be better to clone the existing link? We're hardcoding the path anyway to fetch the template. I do think the text change to "Issue summary standards" makes more sense here, since the document includes more than just the template itself and it's right next tot the template button.

For comparison, the inline editor with the current patch:

I created http://drupal.org/node/1326662.

Alright, I think I've got all the feedback from #41 covered here. Attached:

• Still adds a static link to the issue summary instructions, but makes it open in a new window/tab with target="_blank".
• Still wraps the button with a span. Without this, it was scrunched up against the label text. (I guess an alternative would be to add a little margin or padding to the button CSS, or perhaps there's some better existing CSS to use that I'm not aware of.)
• Refactors to remove the named lambdas.
• Uses http://drupal.org/node/1326662 to fetch "bare" versions of the template. (Thanks davereid for super cow power help.)
• Cleans up code style and variable naming according to the points in #41.

Er. Ignore that last patch; it's against a previous commit rather than the main branch. This one. :)

#49: Well, the page is also useful for people not using dreditor who don't want to have to remove the comments each time, so it is human-readable.

I changed the markup of the page to be less ugly. However, at some point in cleaning up the code, I broke the user name insertion. Debugging that now.

2) For the link text, we want to use .html() instead of .text(), because we are inserting the value back into a HTML document.

Ah, this was not actually the case (the link markup is being inserted into the input field).

Attached reverts that change so the link markup is inserted and uses the corrected template markup.

I did a bit of reading to see if it were possible to have $.get() not send cookies, but the only suggestions I found were server-side solutions. I don't know much about it, though.

Removed sandbox ref as I cannot follow the speed this patch goes :-) by clemens.tolboom

+++ b/dreditor.user.jsundefined
@@ -1360,6 +1360,77 @@ Drupal.behaviors.dreditorIssueSummary = function (context) {
+    // Add a link to view the issue summary instructions.
+    var $instructions = $('<a href="http://drupal.org/node/1155816" target="_blank">Issue summary standards</a>')
+    .appendTo($label);
+    $instructions.before('(');
+    $instructions.after(')');

tim.plunkett reviewed this for me in IRC. The indentation here is off, and this could probably all be chained in one go.

Revised edit: The patch has a bug with a variable that was not renamed properly, and furthermore has an issue due to the refactoring where the [username] token does not get replaced because the GET request finishes too late. Looking into this.

Also checking to see if it would be better to use .load().

Attached resolves the issues described in #53 and also refactors a little to remove more superfluous variable declarations. I also got rid of the extra markup and   and am just adding a small margin to the button instead. I did check through the dreditor styles available but there didn't seem to be one that fit.

Review of #55:
patch applies, button shows up (Win 7, FF 7), and template is inserted.
Further to me the code looks nice - chaining used, just a few new variables and docs all over the place :)

Same review as #56 (Win 7, FF 7) and everything looks good, from functionality to code style.

Updated http://drupal.org/node/1326662 with some suggestions from sun; rolling the changes into a new patch now.

#112805: JSON menu callback for project issues would significantly reduce the overhead of this functionality.

Attached uses the new template.

Once #112805: JSON menu callback for project issues is fixed, I think it would be best to add the issue JSON data to Drupal.dreditor generally. Then we can fix this feature to use that data instead.

Better add a .first() here? Like $(data).find('div#summary-template > div > code').first().text()

Are you sure that isn't just adding overhead? There won't be multiple instances of this.

This fallback is never happening as the $.get has no failure flow.

Eh? This text will be used if the original node cannot be found by matching the path. See:

+++ b/dreditor.user.jsundefined
@@ -1360,6 +1360,85 @@ Drupal.behaviors.dreditorIssueSummary = function (context) {
+            // Fall back to simply "Original report" for the header text.
+            var profileLinkMarkup = '';
+
+            // To find the original poster, try to find a path to the node
+            // from the URL.  We do this now rather than when adding the
+            // original report header because retrieving the profile link can
+            // be slow, so we want that to happen asynchronously.
+            // @see http://drupal.org/node/112805
+            var nodePath = location.href.match(/^.*node\/[0-9]*/);
+            if (nodePath) {

I don't know how to address the reviews above (which is why I gave up on this and instead just used my patch locally), so if you or anyone who groks JS better wants to fix it that would be awesome. :)

#1803622: Add a create follow-up issue link which fills in values (clone an issue) just a little related.

This issue could use some love.

Ok the button at least works now. I didn't dig in too deep, so let me know what else needs to get worked on or if this is RTBC.

I tried this, it's really neat.

but it has two lines trying to get who has posted the original description.

<h3 id="summary-original-report">Original report by <a href="undefined"></a></h3>

<h3 id="summary-original-report">Original report by [username]</h3>

---
the instructions link opens in another window superly to https://drupal.org/node/1155816
I wonder if we want to use https://drupal.org/issue-summaries though

Working on this a bit to see if I can improve it.

Updated based on feedback and review from @YesCT!

• Addressed the duplicate "Original report by" - now the Original report by gets stripped out on the node/add page instead of another one being added.
• Addressed the possibility of getting <a href="undefined"></a> - I used https://drupal.org/node/1797364 for testing before and after.
• Updated the issue summary standards link to use the aliased URL.
• Bonus: updated one String.replace() to use a string instead of a RegEx. We only have one to replace and this is faster and easier to read. Ref. http://jsperf.com/string-replace-regexp-vs-string for speed claims.

Tested in Chrome 28 and Firefox 23:

• Node add form
• Node edit form
• Dreditor issue summary edit popover thinger

Ok. I refactored a lot of this code to utilize jQuery DOM manipulation and targeting tag IDs instead of raw strings. This will allow more flexiblility if the template gets updated in the future. I also added a warning on the bare issue summary template's edit page to inform anyone (that has dreditor) that a new issue window will appear so a proper review can be done. I'll attach screenshots shortly

Here's the interdiff between #70 -> #72. Guess it eaten by the diff monster :-/

edit: removed images since this implementation wasn't committed.

First of all, you made this much faster @Mark Carver! Very nice. When I was testing #70 it took several seconds to fill in and even longer to fetch the username. I reviewed and tested the patch (other than the automatic new issue thing), here are some comments:

1. @@ -1551,6 +1551,122 @@ Drupal.behaviors.dreditorIssueSummary = function (context) {
   + * Adds a button to insert the issue summary template.
   + */
   +Drupal.behaviors.dreditorIssueSummaryTemplate = function (context) {
   +
   +  // Show a warning on the bare issue summary template edit page.
   

   Should the warning on editing the template be in a different behavior?

2. @@ -1551,6 +1551,122 @@ Drupal.behaviors.dreditorIssueSummary = function (context) {
   +                $doc.find('#edit-assigned').val('501638');
   

   This won't always work (most people won't be able to assign to you) but that's probably okay?

3. @@ -1551,6 +1551,122 @@ Drupal.behaviors.dreditorIssueSummary = function (context) {
   +  }
   +    // Add the template button above the issue summary field.
   +  $('body.logged-in.page-node div.project-issue #edit-body').once('dreditorIssueTemplate', function () {
   

   Alignment of the inline comment is a bit off and if they are staying in the same behaviour there should be a blank line between the two sections IMO.

4. @@ -1551,6 +1551,122 @@ Drupal.behaviors.dreditorIssueSummary = function (context) {
   +          else if (!location.href.match(/^.*node\/[^\/]*\/edit/)) {
   +            var $profileLink = $('div.node > div.submitted a').clone();
   +            $profileLink.text('@' + $profileLink.text());
   +            $template.find('#summary-original-report a').replaceWith($('<div/>').html($profileLink).html());
   +          }
   ...
   +          else {
   +            var nodePath = location.href.match(/^.*node\/[0-9]*/);
   +            if (nodePath) {
   +              $.getJSON(nodePath[0] + '/project-issue/json', function(json){
   +                // Find the link to the original poster's profile.
   +                var $profileLink = $('<a/>').text('@' + json.authorName).attr('href', json.authorUrl);
   +                var $bodyVal = $('<div/>').html($body.val());
   +                $bodyVal.find('#summary-original-report a').replaceWith($('<div/>').html($profileLink).html());
   +                $body.val($bodyVal.html());
   +              });
   +            }
   +          }
   

   Neither of these handle the case of issues posted by Anonymous, leading to some different cases.

   For quick edit, we get this (which is probably fine):

   <h3 id="summary-original-report">Original report by </h3>

   For node edit, we get this (it actually tries to link to Anonymous!):

   <h3 id="summary-original-report">Original report by <a href="https://drupal.org/user/1504084">@</a></h3>

5. @@ -1551,6 +1551,122 @@ Drupal.behaviors.dreditorIssueSummary = function (context) {
   +          // Prepend text to current body.
   +          $body.val($template.html().replace(/<\/em>/g, "</em>\n\n").replace(/<\/h3>/g, "</h3>\n\n") + $body.val());
   +        });
   +        // Take no action other than executing the .click() behavior.
   +        return false;
   +        }
   +    );
   

   Alignment on the closing curly brace (second last line in the code sample) looks off, but I could be wrong.

6. @@ -1551,6 +1551,122 @@ Drupal.behaviors.dreditorIssueSummary = function (context) {
   +  if (!(location.href.search('node/1326662/edit') === -1)) {
   ...
   +          if (!(location.href.search('node/add') === -1)) {
   

   JSHint was not happy with these lines:

   "Confusing use of '!'"

And definitely a nitpick but I think it'd be nice not to rely on dgo.to to link to the Dreditor project, just link directly to the project page.

Hmm, maybe d.o or my machine was just being slower last night, not noticing a big difference between #70 and #72 today as far as speed. Still fast though :)

Addressed the concerns in #74:

1. I'm going to keep this in the same Drupal.behaviors.dreditorIssueSummary behavior. They both pertain to the Issue Summary. I went ahead and moved the warning portion to the bottom of the behavior though since it is really just an extra "gate" mechanism to notify us of changes to the template.
2. Removed. I wasn't thinking (would be nice though).
3. Fixed
4. Fixed. This will keep the will simply replace the templates <a href="#">@username</a> with <a href="#">Anonymous</a>
5. Fixed. Actually both the ending curly and parenthesis should have been together, it's the ending .click() function.
6. Fixed. The way I did that was dumb lol (I was tired)
7. Fixed nitpick too, you're right, we should use the full path (I just like using the shortened URLs :)). I also went ahead and removed the protocol prefixes too, they all start with //drupal.org.

Sigh... here's the interdiff for #72 -> #76 (not sure why my drush_iq isn't auto generating one, maybe because it's on a "master" branch and not a Drupal specific one).

Fixed preventing default event per jQuery coding standards (https://drupal.org/node/1720586#event-delegation)

Fixed issue with author not being set properly on node edit pages

Improved better detection of various different types of anon users

Removed warning, I would rather lock down that page if possible so it is only editable by certain people (with a note saying who people should contact).

Gave the latest patch a test and it seems to be working well, found some very minor touch-ups with the code, leaving at CNR so we can get more manual testing.

1. @@ -1551,6 +1551,84 @@ Drupal.behaviors.dreditorIssueSummary = function (context) {
   +        $.get('//drupal.org/node/1326662', function(data) {
   ...
   +              $.getJSON(nodePath[0] + '/project-issue/json', function(json){
   

   Need spacing here per https://drupal.org/node/172169#functions.

   function (data) {
   function (json) {

2. @@ -1551,6 +1551,84 @@ Drupal.behaviors.dreditorIssueSummary = function (context) {
   +          // Prepend text to current body.
   +          $body.val($template.html().replace(/<\/em>/g, "</em>\n\n").replace(/<\/h3>/g, "</h3>\n\n") + $body.val());
   +        });
   +        // Prevent default "click" event.
   +        e.preventDefault();
   +       });
   

   Double-check indents lining up here please.

3. @@ -1551,6 +1551,84 @@ Drupal.behaviors.dreditorIssueSummary = function (context) {
   +    // Add a link to view the issue summary instructions.
   +    $('<a href="//drupal.org/issue-summaries" target="_blank">Issue summary instructions</a>')
   +      .appendTo($label)
   +      .before('(')
   +      .after(')');
   +  });
   

   Closing indent looks off.

It sounds like #82.3 was pretty much the same as #74.5, so don't mind me. I'll get used to reviewing JavaScript eventually :)

Edit: although a blank line in between might help make it clearer :)

zomg, #81 is going to change my world. No more chrome autocomplete on the word "bare"
RTBC from me :)

I'd like to take a quick look at this before commit, please :)

Addressed issues in #82

Feel free to take a look. Cottser and I have made significant progress on this issue and would like to commit this soon. We have had many reviews and are simply going through some minor coding standards nitpicks now. I doubt we'll have any major changes to actual functionality or logic used here.

edit: a lot of which we've already discussed in the #dreditor irc channel

I realize the issue summary says caching will be handled elsewhere, but I think it's important to implement it here. There's already a localstorage wrapper in dreditor, so I've just used that. There's no way to modify the Cookie header in an XMLHttpRequest (at least, not in the browser context), so there's no possibility of retrieving the cached version of this page from Drupal.org. This implementation only adds a bit of code, and avoids hammering Drupal.org for something that's easily cached.

interdiff against 86

(and for the browsers where localStorage is not supported, nothing will happen - we'll just grab the markup from d.o as normal)

+++ b/dreditor.user.js
@@ -1555,6 +1555,98 @@ Drupal.behaviors.dreditorIssueSummary = function (context) {
+        if (!Drupal.storage.load('issueSummaryTemplate')) {
+          $.get('//drupal.org/node/1326662', function(data){
+            Drupal.storage.save('issueSummaryTemplate', data);
+            dreditorIssueTemplateProcess(data);
+          });
+        }
+        else {
+          var data = Drupal.storage.load('issueSummaryTemplate');
+          dreditorIssueTemplateProcess(data);
+        }
+
+        // Process the issue summary instructions.
+        function dreditorIssueTemplateProcess(data) {

This creates the function after it's called (see the else code block, which isn't asynchronous). It also doesn't timestamp difference these at all, so this would always be cached and the user would never get an updated version if the template were to change.

In all reality and TBCH, I'd really like to make this a whole separate issue. I'm not saying this isn't needed, but it certainly deserves it's own special attention.

FWIW, caching in Dreditor needs to be something more of a "service" so we have better handling of things like this in general (which certainly falls out of the scope of this issue) and before you say "if we don't put it in, then it'll hammer drupal.org" again, everyone already does this... just manually so they can copy and paste it.

Like I said, @Cottser and I have already discussed a lot of this kind of stuff in #dreditor. I suggest following this issue too (which is kinda short ATM) #2061841: [META] Overhaul/New Version

#86 manually tested on contrib and core. that looks ready to go. Lets make a new issue for caching.
I gave a quick read through the code and nothing standards wise jumped out at me.

Thanks @YesCT! Committed d210e57

Great job everyone! I went ahead and created #2063851: Implement a better service for caching data with expirations as a follow-up.