PHP Fatal error: Cannot use object of type stdClass as array in /../sites/all/modules/filefield_paths.inc on line 33

I downgraded to beta 1 from beta 3. Unfortunately, beta 2 or 3 removes the filefield_paths table required by beta 1. Restoring that was a real bear. I wish I had made a db backup. This is the first time in 4 years of drupal I've experienced a module update for which I should have made a db backup.

Hi,

Is there a patch for this, I'm still getting this error? Wouldn't allow me to publish an Article for some reason. I do have "Display Suite" layout configured, but when I removed "File Aliase" I was able to publish.

Thanks!...

For me, replacing the file with the code above did work well so far on my test site. There were a number of errors because the files weren't actually there, but it seemed to work, yeah. I'll try to roll a patch sometime.

Hi,

I also applied the patch above and so far I have not found any problems!

Thanks mrister!..

The code attached to #0 does not seem to match the description in #0. The parameters for hook_filefield_paths_process_file does appear to be as described ($function($type, $entity, $field, $instance, $langcode, $files);), but the provided fix does not use the same parameter list, leaving me wondering what the intention was. The purpose of the hook seems to be to call path_save to map from filefield_paths/alias/{$value['fid']}, but the code above maps it to an empty string.

I started to work on this, but $settings is no longer passed in to the function, so I could not find a couple of needed values.

/**
 * Implements hook_filefield_paths_process_file().
 */
function file_aliases_filefield_paths_process_file($type, $entity, $field, $instance, $langcode, $files) {
  foreach($files as $file) {
    if (!empty($file['filename'])) {
      $token_data = array('file' => file_load($value['fid']),'node' => $file, $type => $entity);
      // where do $settings come from?
      $token_alias_value = $settings['filealias']['value'];
      $token_alias_options = $settings['filealias'];
      $file['filealias'] = filefield_paths_process_string($token_alias_value, $token_data, $token_alias_options);
      $path = "filefield_paths/alias/{$file['fid']}";
      $alias = drupal_get_path_alias($path);
      if ($alias !== $path) {
        path_delete(array('source' => $path));
      }
      path_save($path = array(
        'source' => $path,
        'alias' => $file['filealias']
      ));
    }
  }
}

Oddly enough, the URL for my objects came out correctly, even though this function seems to be a no-op at the moment.

Here is a patch against 1.x-dev that I believe correctly conforms to the new API for hook_filefield_paths_process_file.

#6 works, but not as intended. It pulls the tokens/settings from the Field Path and Field Name boxes that come with the filefield_paths module, not from the File Alias box that comes with this module.

I have mucked around with the /file_aliases/modules/filefield_paths.inc and got it to work properly. Unfortunately, creating patch files is beyond my skills, so if someone else could. This is the whole contents of that file (as part of the current dev).

/**
 * @file
 * FileField Paths module integration.
 */

/**
 * Implements hook_filefield_paths_field_settings().
 */
function file_aliases_filefield_paths_field_settings() {
  return array(
    'file_alias' => array(
      'title' => 'File alias',
      'sql' => 'filealias',

      'form' => array(
        'value' => array(
          '#type' => 'textfield',
          '#title' => t('File alias'),
          '#default_value' => drupal_substr(parse_url(file_create_url(file_default_scheme() . '://'), PHP_URL_PATH) . '[file:ffp-name-only-original].[file:ffp-extension-original]', 1),
          '#maxlength' => 512,
          '#size' => 128,
        ),
      ),
    ),
  );
}

/**
 * Implements hook_filefield_paths_process_file().
 */
function file_aliases_filefield_paths_process_file($type, $entity, $field, $instance, $langcode, &$items) {
  if (isset($instance['settings']['filefield_paths'])) {
    $settings = $instance['settings']['filefield_paths'];
    foreach ($items as &$file) {
      if ($file['timestamp'] == REQUEST_TIME || $settings['active_updating']) {
        $token_data = array(
          'file' => (object) $file,
          $type => $entity
        );

        $file['filealias'] = filefield_paths_process_string($settings['file_alias']['value'], $token_data, $settings['file_alias']['options']);
		
        $path = "filefield_paths/alias/{$file['fid']}";
        $alias = drupal_get_path_alias($path);
        if ($alias !== $path) {
          path_delete(array('source' => $path));
        }
        path_save($path = array(
          'source' => $path,
          'alias' => $file['filealias']
        ));
      }
    }
  }
}

This will create the alias and everything, but an error does come up when you use the Retroactive update feature. This error is

The specified file http://xxxxxxxx/yyyyyyyy.zzz could not be copied, because no file by that name exists. Please check that you supplied the correct filename.

Where xxxxxxxx is the base url and yyyyyyyy.zzz is the filename alias (with or without subfolders). I will briefly look into this now, but I'm not going to spend a lot of time on it because it doesnt effect the website I am working on.

Got it! Took me HOURS and HOURS, and in the end, only an underscore was required (lol).

Line 33 of file_aliases.module needs changing to the following;

function _file_aliases_file_load($files) {

Making this a private function (add the underscore prefix) fixed everything, and it all seems to work on my system. The problem was this function was setting the file->uri to the aliased path, and then the filefield_path module could not move it (needed actual path, not alias). Making this function private means the filefield_path module does not use the file_alias hook.

There maybe another fix required, but I am not too knowledgeable. Line 93 of file_aliases.module reads $results = db_select('file_managed', 'f') but I am wondering if it should read $results = db_select('{file_managed}', 'f') .

A tweak may also be required to my code above (post #7). The code in $token_data array is created slightly different in the filefield_path modules code, so we should probably keep it the same. It should change to

        $token_data = array(
          'file' => file_load($file['fid']),
          $type => $entity
        );

To #8 — great job, it almost work!
But my original image alias doesn't works:

[host]/files/120529-2116488.jpg?large — ok
[host]/files/120529-2116488.jpg — not open the image

Can you fix it? Thnx

I have used this for thousands of images now, and everything is working for me, so not sure what your problem could be. It could be that the 'source' image has moved or been deleted, but the styled image was left behind in the styles/large/.... folder. You would need to investigate.

But my problem still actual:
The original image places normally, but alias doesn't works.
Your suggestions?

Have you checked your logs for clues? What are you file path and alias settings, post them here. Perhaps you should run a retroactive update, to fix any issues?

There is a 'strict reference' error (or similar). Small tweak is required to fix. This code in post #7

path_save($path = array(
          'source' => $path,
          'alias' => $file['filealias']
        ));

Needs to be replaced with

$path = array(
          'source' => $path,
          'alias' => $file['filealias']
        );
path_save($path);

Patch attached, compiled from comments above.

Hello,

I'm making a simple file sharing like system on my site.
I've applied the patch #15 successfully and the alias is not working.

I got a 'The requested page "/7bc19947aea2e5ab344302da696f1f0657ce7e99" could not be found.' when I click on the like to my file.

The tokens are:
The file alias is set to: [random:hash:sha1]
The file name is set to: [file:ffp-name-only-original].[file:ffp-extension-original]

@pol : how did you successfully apply that patch while I get smacked in the face with "trailing whitespace" errors ? and a fatal error at line 56 ?

I didn't try to run #15, but Drush IQ will apply it just fine. (drush iq-apply-patch 1492978)

don't have drush on the server I'm working on :/ but thanks anyhow

my bad - i wasn't patching against the dev version - terribly sorry.

Here is my patch but can't apply with git apply, i do it manually right now ...

Hope it helps

+++ b/file_aliases.moduleundefined
@@ -105,6 +105,16 @@ function file_aliases_load_fid($fid) {
+	$image = image_load($result->uri);
+	if($image){
+		file_transfer($image->source, array('Content-Type' => $image->info['mime_type'], 'Content-Length' => $image->info['file_size']));
+	}
+	else{
+		drupal_not_found();
+		exit;	¶
+	}

You should not use tabs, but spaces.
You should also remove trailing spaces.

+++ b/modules/filefield_paths.incundefined
@@ -29,12 +29,16 @@ function file_aliases_filefield_paths_field_settings() {
-    $path = "filefield_paths/alias/{$file['field']['fid']}";

I think it's not a good practice to use that kind of string concatenation. use $var = 'string' . $var;

Hi Pol and thanx for your feedback.

I will do it again and post the new one ;)

For the syntax, i keep the original one.

Arthur

I had to apply the patch from #21 I by hand due to the whitespace errors.

After changing the code all of my directories are created, renaming of the file works and the directory alias works. Thanks a bunch !!!

Although everything looks to be working correctly I am now receiving the following error:
Notice: Undefined index: file_alias in file_aliases_filefield_paths_process_file() (line 39 of sites/all/modules/contrib/file_aliases/modules/filefield_paths.inc).

Looking forward to the patch.

Also could the Maintainer set up the GIT revision tab for 7.x-1.x as I really enjoy trying out patches with git :)

The patch in #21 has different code to what I posted in #7 (which btw I am using on numerous servers without error), and it appears that is causing the problem.

I had in #7
$file['filealias'] = filefield_paths_process_string($settings['file_alias']['value'], $token_data, $settings['file_alias']['options']);

Patch in #21 has
$file['filealias'] = filefield_paths_process_string($settings['file_alias']['file_alias'], $token_data, $settings['file_alias']['options']);

@neRok

Thanks for helping out with this code !!

The patch that was made from your comments did not include the changes to Line 33 of file_aliases.module

You have coding skills that the Drupal community would really benefit from. I can't write a line of code but know how to patch :) here is a link that helped me out. http://jacine.net/post/8419331209/patches#create

The attached patch combines all of neRok's comments.

If anyone can help with the two whitespace errors and re-roll that would be helpful.

Had the same error and all is working fine now with patch from #27. Rerolled the patch because of the whitespaces.

Yes, #28 works. It also will fix another bug (Files can no longer be deleted from server when deleting a node.). Bu there is another one. Version: 7.x-1.x-dev is still affected by "File Aliases remain after deleting/removing files from FileFields" bug.

I have made a patch to fix a bunch of issues with File Aliases module, including this issue, in the following issue.
#1896326: Combined patch for all known issues in D7 branch

+++ b/file_aliases.moduleundefined
@@ -30,7 +30,7 @@ function file_aliases_menu() {
-function file_aliases_file_load($files) {
+function _file_aliases_file_load($files) {

Why change the function name? It will no longer trigger when the hook is invoked.

+++ b/file_aliases.moduleundefined
@@ -88,7 +88,7 @@ function file_aliases_load_fid($fid) {
+  $results = db_select('{file_managed}', 'f')

This is not valid, database tables are no longer wrapped with {}'s.

I note that these changes weren't implemented until #27, which is the 'combined patch'.... I suggest breaking those changes out and going back to the actual issue at hand here.

Used patch from #32 and it fixed the fatal error - using filefield_paths 7x-1.0-rc1 and file_aliases 7x-1x-dev.

Thanks for the report, this module is still on my radar.

Latest commit has re-written this whole section and it now works correctly.

delete