Problem/Motivation

Right now focal_point_install() and focal_point_update_7001() create a test drive image in the public files directory. This breaks on sites whose file default scheme is remote (such as amazons3.module's s3://).

Proposed resolution

Move focal_point_update_7001()'s code to a new parameterized helper function, called from both focal_point_update_7001() (so old functionality remains the same), and also add a new update hook calling the same function with the file_default_scheme variable.

Remaining tasks

  • Patch
  • Review
  • Test

User interface changes

The test image should now appear on sites with remote stream wrappers and multiple webs.

API changes

None.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

scottrigby’s picture

Assigned: scottrigby » Unassigned
Issue summary: View changes
Status: Active » Needs review
FileSize
1.79 KB

Patch attached. Tested the update locally, on a site configured with amazons3.module and file_default_scheme set to s3. Did not go back and re-test focal_point_update_7001() but the actual code has not changed (since 'public is passed').

scottrigby’s picture

Whoops I didn't change to the new update in hook_install(). Updated patch and interdiff attached.

bleen’s picture

+++ b/focal_point.install
@@ -129,7 +132,13 @@ function focal_point_update_7001() {
+  focal_point_create_test_image('public');

is this change needed, given 7004?

scottrigby’s picture

@bleen nah, I was just following the protocol of never changing update hook history (I did change the code itself, putting DRY over that rule of thumb… the result is the same). I agree though it's kinda useless given 7004.

Also note new org attribution :)

scottrigby’s picture

@bleen18 if you want me to kill it, we could just keep 7001 with a code comment explaining the reasoning for the change? Or we could leave it. Up to you

bleen’s picture

@scottrigby ... yeah, I feel dirty changing an old update (except for comments)

tklawsuc’s picture

I want to add that this is also preventing an install profile from loading up. When focal_point is added as a dependency in the profile, the installation fails (using drush si):

WD php: EntityMalformedException: Missing bundle property on entity of type file. in entity_extract_ids() (line 7839 of      [error]
[SITEROOT]/includes/common.inc).

The bundle that it's looking for is "type".

When I comment out the logic in focal_point_update_7001(), the installation works fine. Can you consider maybe adding the test image when the test page is accessed for the first time instead of on install?

FYI using v 7.x-1.0-beta4 and drupal 7.37.

bleen’s picture

@tklawsuc... I think you are describing a different issue. Are you saying that the patch in #2 solves your issue or just that killing 7001 (without introducing 7004) solves your issue. If its the former, would you please open a separate issue? If it's the later I'll be really surprised.

bleen’s picture

Status: Needs review » Fixed
FileSize
1.93 KB

@scottrigby ... I've reconsidered my comment in #3 after looking at how updates like this are handled in the system module (at least in D7). This patch, which i committed, simply removes update_7001 completely.

The substance of this patch is a good fix. Thanks!!

  • bleen18 committed 391a2ed on 7.x-1.x authored by scottrigby
    Issue #2453429 by scottrigby: Update test drive image to use file...
tklawsuc’s picture

I tried the patch and it still fails so there is a different issue. I will create a separate ticket...in the meantime I just removed the call to focal_point_create_test_image on install. Thanks.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

Daniel Korte’s picture

I can confirm this patch fails if the module is already installed and uses the public:// scheme. Here's the error:

Failed: PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'public://focal_point/test-drive.jpg' for key 'uri': INSERT INTO {file_managed} (uid, filename, uri, filemime, filesize, status, timestamp, type) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7); Array ( [:db_insert_placeholder_0] => 1 [:db_insert_placeholder_1] => test-drive.jpg [:db_insert_placeholder_2] => public://focal_point/test-drive.jpg [:db_insert_placeholder_3] => image/jpeg [:db_insert_placeholder_4] => 497845 [:db_insert_placeholder_5] => 1 [:db_insert_placeholder_6] => 1442523358 [:db_insert_placeholder_7] => image ) in drupal_write_record()

So basically the update is trying to create a duplicate of the test image with the same URI. The update function should probably delete the previous test image or check that the same one doesn't already exist.

muschpusch’s picture

+ 1 having the same issue as Daniel Korte. The release of today brings this patch in. There doesn't seem to be an issue created by tklawsuc. Should we re-open this one or create a follow up?

bleen’s picture

@muschpusch .. please create a followup (thats why I missed it before todays release :( )

scottrigby’s picture

@Daniel Korte & @muschpusch That makes sense. Can you relate the new issue to this one once created so people can follow the trail? Thanks

muschpusch’s picture