Update checks fail for modules that have a defined 'project status url' in their .info file containing a question mark. This is caused by the _update_build_fetch_url function in update.fetch.inc incorrectly inserting a question mark instead of an ampersand when adding get parameters to a url. The current code incorrectly uses the 'strpos' php function to check for an existing question mark in the url.
$url .= (strpos($url, '?') === TRUE) ? '&' : '?';
strops() will never return TRUE; if the 'needle' was found in the 'haystack' then its position (integer) would be returned.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

RadioActiv’s picture

RadioActiv’s picture

Version: 7.12 » 7.x-dev
RadioActiv’s picture

Status: Needs review » Patch (to be ported)
Issue tags: +Quick fix, +Novice
filijonka’s picture

Version: 7.x-dev » 8.x-dev
Status: Patch (to be ported) » Needs review
Issue tags: -Quick fix +Needs backport to D7

we need to test this before.

lucascaro’s picture

Just tried to apply this to D8 and it won't work because:
error: modules/update/update.fetch.inc: No such file or directory

re-created to work against D8.
Tested using junk_test_module and manually changing the "project status url".
It breaks before patching, It works after patching.

The patch in #1 should work for D7 (the only change was the path to the update module).
Edit, just tested the patch #1 agains D7 and it works.

lucascaro’s picture

I'm writing tests for this issue and I think the problem might be deeper than we think.
If we in fact are supporting urls with a ? in them for "project status url" what is the desired behavior of _update_build_fetch_url?

let's say we have

$project['info']['project status url'] = 'http://www.example.com/?test=1';
$project['name'] = 'update_test';
$project['project_type'] = '';
$site_key = 'site_key';

then the function (with the patch) will generate the url:
http://www.example.com/?test=1/update_test/8.x&site_key=site_key
is that correct?
are we looking for something like:
http://www.example.com/update_test/8.x?test=1&site_key=site_key
or the first url should work?

lucascaro’s picture

I'll just assume that the url needs to be of the form http://www.example.com/?project= so we can append the project name. let me know if I'm wrong.

lucascaro’s picture

Ok, here is the test case and the patch that solves it.
Please take time to review the test case as well since it's my first for core. I will gladly accept any suggestions you have to improve it.
The patch is the same as #5 re rolled to be tested with the new test.

lucascaro’s picture

re rolling the patch including both the fix and the test.

RadioActiv’s picture

To clarify what caused me to find the bug in the first place; I had a site that couldn't use clean urls that was acting going to act as a 'Feature Server' (fserver module).

The "project status url" ended up being something like
http://example.com/drupal_sites/feature_server/index.php?q=fserver

This caused the url generated by _update_build_fetch_url to be
http://example.com/drupal_sites/feature_server/index.php?q=fserver/MODULE_NAME/6.x?site_key=key&version=6.x-1.x

Since there were two question marks in the url returned, update checks always fail.

RadioActiv’s picture

Patch from #1 backported to D6. Adding tag for backport to D6.

Status: Needs review » Needs work

The last submitted patch, update-custom_url_parse-1481156-11.patch, failed testing.

RadioActiv’s picture

Update of patch for D6.

RadioActiv’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, update-custom_url_parse-1481156-13.patch, failed testing.

RadioActiv’s picture

Status: Needs work » Needs review
FileSize
717 bytes

Re-uploading D6 patch with 'do-not-test', since it doesn't apply to 8.x codebase.

valthebald’s picture

Status: Needs review » Reviewed & tested by the community

Patch from #9 worked just fine with the latest 8.x-dev
Seems pretty much straightforward

lucascaro’s picture

Status: Reviewed & tested by the community » Needs review

also, as @timmillwood made me notice, the D6 and D7 patches are missing the tests. Since it's a unit test they might be ported from the patch #9?

lucascaro’s picture

Status: Needs review » Reviewed & tested by the community

sorry, changed status unintentionally. Marking as RTBC as per #17

Dries’s picture

Version: 8.x-dev » 7.x-dev

Good catch. Committed to 8.x. Moving to 7.x. Thanks!

lucascaro’s picture

Status: Reviewed & tested by the community » Patch (to be ported)

marking as Patch (to be ported) for D7, patch #1 should do and the tests should backport easily from #9.

lucascaro’s picture

Status: Patch (to be ported) » Needs review
FileSize
3.77 KB
3.07 KB

here are the patches, the first is the test only and the second is the backport of the patch.

Status: Needs review » Needs work

The last submitted patch, update-custom_url_parse_D7-1481156-22.patch, failed testing.

lucascaro’s picture

Status: Needs work » Needs review
FileSize
3.77 KB

Oops! the second patch again:

valthebald’s picture

Status: Needs review » Reviewed & tested by the community

No difference from D8, so RTBC

webchick’s picture

Version: 7.x-dev » 8.x-dev
Status: Reviewed & tested by the community » Needs work

Committed and pushed to 7.x for parity with 8.x, thanks! This is a good catch, and I love that it comes with a test!

However, there are a few things that could use some clean-up, so bumping back to 8.x and "needs work" for that. Trying to be thorough so you learn best practices. :)

Specifically:

+++ b/modules/update/update.testundefined
@@ -697,3 +697,57 @@ class UpdateTestUploadCase extends UpdateTestHelper {
+class UpdateCoreUnitTestCase extends DrupalUnitTestCase {

This needs a line of PHPDoc to explain what it's doing.

+++ b/modules/update/update.testundefined
@@ -697,3 +697,57 @@ class UpdateTestUploadCase extends UpdateTestHelper {
+      'name' => "Unit tests",

Single quotes, since we're not interpolating any variables here.

+++ b/modules/update/update.testundefined
@@ -697,3 +697,57 @@ class UpdateTestUploadCase extends UpdateTestHelper {
+   * Tests _update_build_fetch_url according to issue 1481156

Typically, we don't put issue IDs and the like in comments, because you can find that information via git blame. This should instead be changed to a description that would make sense to someone who'd never seen this issue before.

+++ b/modules/update/update.testundefined
@@ -697,3 +697,57 @@ class UpdateTestUploadCase extends UpdateTestHelper {
+    //first test that we didn't break the trivial case
...
+    //For disabled projects it shouldn't add the site key either.
...
+    //for enabled projects, adding the site key
...
+    // http://drupal.org/node/1481156 test incorrect logic when url contains
+    // a question mark.

Comments should follow this format:

// Space before full sentence, starts with capital letter and ends in period,
// wraps at 80 characters.

On the last one, once again don't bother referencing the issue node ID. Describe the functionality to someone who is coming across this test 6 months from now.

jurgenhaas’s picture

Hi, I'm a newbe to core contribution and just joined in on the core sprint at DrupalCon Munich. Picked this ticket as my first issue and wanted to cleanup the code but unfortunately can't find the file modules/update/update.test which is referred to in the patch from #24. To top part of the patch is already rolled into the latest D8 dev release but I wonder how to go about with the second part.

Can someone please point me in the right direction?

taubeta’s picture

Status: Needs work » Needs review

#22: update-custom_url_parse_D7-1481156-22.patch queued for re-testing.

Sorry, ignore that. I just wanted to see what happens by clicking re-test...

spicerpa’s picture

spicerpa’s picture

+++ b/modules/update/update.testundefined
@@ -697,3 +697,57 @@ class UpdateTestUploadCase extends UpdateTestHelper {
+
+class UpdateCoreUnitTestCase extends DrupalUnitTestCase {
+

Does this need a doc block explaining this class?

Status: Needs review » Needs work

The last submitted patch, update-custom_url_parse_D7-1481156-24.patch, failed testing.

xjm’s picture

Status: Needs work » Active

Oops, sorry for the confusion. This patch has already been committed to D8 and D7, so the task now is to make a new patch against D8 with the changes described in #26. #30 is also correct.

chrisjlee’s picture

Status: Active » Needs review
FileSize
2.6 KB

Changes are followup work as recommended by #26.

Also, No changes are needed for the class docblocks. They're actually already been committed to core:

Patch:

@@ -697,3 +697,57 @@ class UpdateTestUploadCase extends UpdateTestHelper {
   }
 
 }
+
+class UpdateCoreUnitTestCase extends DrupalUnitTestCase {
+

HEAD:

/**
 * Tests update functionality unrelated to the database.
 */
class UpdateCoreUnitTest extends UnitTestBase {
YesCT’s picture

Status: Needs review » Needs work

The last submitted patch, 33: 1481156-documentation-followup-33.patch, failed testing.

YesCT’s picture

Version: 8.0.x-dev » 7.x-dev
Issue summary: View changes
Status: Needs work » Closed (fixed)

We are not doing followups in the same issues anymore, so we need a new issue. here it is: #2374201: Docs and quote coding standard follow-up from: Incorrect logic in creating url to fetch information about project updates