I got error on D7 with error below

Notice: Undefined index: host in _filefield_paths_replace_path() (row 285 von C:\wamp\www\drupal\sites\all\modules\filefield_paths\filefield_paths.module).

Notice: Undefined index: scheme in _filefield_paths_replace_path() (row 287 von C:\wamp\www\drupal\sites\all\modules\filefield_paths\filefield_paths.module).

I use:

  • Drupal: 7.12
  • Plup: 7.x-1.0-alpha1
  • File (Field) Paths: 7.x-1.0-beta3

and the image on the server gets a strange name --> p16nsnqa5e12o0134d1t951mbmmq94.jpg

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Bernsch’s picture

Issue summary: View changes

image name

sw3b’s picture

I got the same thing on my side with the same modules ! Except for the name, my file are getting rename correctly. I'm using the token as below.

[node:author:uid]_[node:nid]_[random:hash:md5].[file:ffp-extension-original]
Bernsch’s picture

Apparently there is a plup issues
--> link to Plup Issues

Deciphered’s picture

Status: Needs review » Closed (duplicate)

Going to mark this as a duplicate for the moment, unless someone is able to confirm that this issue is reproducable without the Plup module in the mix, or with a fixed version of Plup.

carajito’s picture

Note: The mistake was mine at the token name

Hi, I have the same error and I not use Plup or any other module

Drupal: 7.14
File (Field) Paths: 7.x-1.0-beta3

In the content type is ok but on the taxonomy have the error:

  1. Warning: parse_url(public:///block_name_icon.png) [function.parse-url]: Unable to parse URL in _filefield_paths_replace_path() (line 290
  2. Notice: Undefined index: host in _filefield_paths_replace_path() (line 292 of
  3. Warning: parse_url(public:///block-image.png) [function.parse-url]: Unable to parse URL in _filefield_paths_replace_path() (line 290
  4. Notice: Undefined index: host in _filefield_paths_replace_path() (line 292

The error be show when I use more than one image
File path = [term:url:unaliased:args:first]/[term:url:path]
File name = [file:ffp-name-only-original].[file:ffp-extension-original]

Thanks for the module

skizzo’s picture

Status: Closed (duplicate) » Active

I am re-opening the issue as I see the error when saving a node with a single imagefield and multiple image instances.
I am not running Plup and for testing purposes I am using the default file name configuration for the image field.
I believe that the error is generated only when "File path" is left blank.

Notice: Undefined index: host in _filefield_paths_replace_path() (line 292 of /var/www/drupal/sites/all/modules/filefield_paths/filefield_paths.module).

BrightBold’s picture

I can confirm that like @skizzo in #9, I was getting this error without Plup installed and setting a file path, which had previously been blank, resolved it.

im_lex’s picture

I also can confirm it. I was getting this error without Plup installed...

HansKuiters’s picture

Confirmed without the Plup module. Setting the filepath in the image field solves this issue, but the final filepath might get a bit messy. It is related to the path the image cache sets, so my final image path becomes http://localhost:8888/sitename.nl/sites/default/files/styles/thumb-news/...

John Bickar’s picture

Status: Active » Patch (to be ported)
FileSize
878 bytes

Patchy attachy.

yannickoo’s picture

I'm getting even an error with this patch attached:

Notice: Undefined index: host in _filefield_paths_replace_path() (line 287 of /sites/all/modules/contrib/filefield_paths/filefield_paths.module).

As I mentioned in this issue I tried it with file_create_url() and I no more got notices but no I've public:/// in the uri column.

a.mikheychik’s picture

To fix this issue, you need to set "File path" option. If it isn't set, the path won't be parsed correctly by parse_url function.

Renee S’s picture

John Bickar, the patch just pushes the problem a few lines down when the module looks for $replacement and can't find it, since the if condition wasn't met...

jaydub’s picture

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

In my testing with a simple core imagefield the issue with the calls to parse_url() in _filefield_paths_replace_path($old, $new, $entity) is that the paths that are passed ($old and $new) to parse_url() are using Drupal's file stream wrappers so in this case $old and $new are using the public:// scheme and so the code that attempts to parse the uri that follows incorrectly parses 'host', 'path', etc.

The attached patch uses file_create_url to convert the stream wrapper uri into something the parse_url() call can use.

torrance123’s picture

Status: Needs review » Reviewed & tested by the community

The patch in #13 works correctly.

In my case the value of $new in _filefield_paths_replace_path() is public:///test_file.txt.

Once it is passed through parse_url() on line 290, the variable $info is set to empty.

Using the patch in #13, the value of $info becomes:

$info => Array
(
    [scheme] => http
    [host] => localhost
    [port] => 8888
    [path] => /drupal/sites/default/files/test_file.txt
)

There are no ill side effects in my testing.

[Edit: corrected the code examples.]

torrance123’s picture

This bug only appears when there is no path set. With no path the value of $new is:

public:///test_file.txt

With a path set, in this case 'mycustompath', the value of $new is:

public://mycustompath/test_file.txt

So it looks like the triple forward slash is confusing parse_url().

Anonymous’s picture

I couldn't apply the the patch from #13, it is not applicable. The code in 7.x-1.0-beta3 seems different than what the patch expects.

ssllav’s picture

hi all.
I do not use Plop and have Notice about host too.
But version 7.x-1.x-dev work excellent.

yannickoo’s picture

I can apply the patch against the dev version.

Renee S’s picture

Works for me.

toomanypets’s picture

The patch in #13 also resolves the problem I reported in comment 1 on #1830392: Bug triggered by files with space in the filename where the Insert module was inserting the incorrect path when the uploaded file contained spaces in the filename.

Jeffrey C.’s picture

Priority: Normal » Critical

It's been three months and a RTBC patch is available, I suppose we should escalate this issue to critical since this module is currently in an unusable state right now.

Deciphered’s picture

Priority: Critical » Normal
Status: Reviewed & tested by the community » Postponed (maintainer needs more info)

Reducing this from critical, it's far from critical, a critical issue implies the module breaks stuff, however this is just throwing a warning.

I'm also removing this issue as RTBC, because it's a bandaid patch, it doesn't resolve the real underlying issue. That, and I am unable to reproduce this issue.

If someone can give me a step-by-step guide on how to reproduce this issue I'd be extremely grateful and will get this issue resolved ASAP.

Jeffrey C.’s picture

It only renames the file if you submit the node creation form directly. Doesn't work if you click the upload button when creating a new node.

Deciphered’s picture

@Jeffrey C.,

File (Field) Paths doesn't do any renaming until the node is save, because how can it replace Node tokens if there is not yet a Node to provide the tokens? That's the whole point of the module. I assume I'm taking your comment out of context however, because it doesn't necessarily seem to be related to my last comment.

Jeffrey C.’s picture

Hmm... That makes sense. Weird thing though, like a couple weeks ago the file doesn't get renamed without the patch in #13. But just tested it out again and everything seems to work just fine. But any idea how the PHP notice is generated?

Deciphered’s picture

As I said, I can't reproduce the issue, I don't get the message, I've gone through all the comments in the issues searching for information on what may have caused it for others, and attempted everything that's been said, but I am still unable to reproduce.

If you are able to get the message, tell me exactly what you are doing from the point of a fresh install of Drupal and then I might be able to get to the bottom of the issue.

Jeffrey C.’s picture

Deciphered’s picture

Status: Postponed (maintainer needs more info) » Fixed

Ok, so I did that, and I tested both with 7.x-1.0-beta3 and 7.x-1.x, it was an issue in 7.x-1.0-beta3 but worked fine in 7.x-1.x.

Therefore this issue is fixed and closed.

claudiuv’s picture

This bug is still active with 7.x-1.0-beta3 and the latest drupal core.

Deciphered’s picture

Caludiv,

The issue is fixed in 7.x-1.x-dev, it will be part of the next beta release or stable release.

Status: Fixed » Closed (fixed)

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

miamitops’s picture

i just changed the configuration in drupal admin logging and errors not to display those errors

miamitops’s picture

Issue summary: View changes

text correction