Cannot use object of type stdClass as array... module line 74

I get the same error. With Presets installed, crucial pages of my site become inaccessible (like the module page, the page to flush the cache etc.) - the only way to get back in is to use drush to disable Presets. I'm marking this as critical.

After some debugging the issue seems to lie with presets_get_presets returning an incorrect set of results (the error message indicates that it's returning at least one Object instead of just arrays). I had a look through dsm to see what 'presets' were being picked up. I hadn't set up any presets using Presets (I couldn't get past the install!), but it seemed to have picked up some of my Features, specifically those from ImageCache, Views and OpenLayers (see attachment). So it seems to me as if this function is incorrectly picking up what it thinks are presets, when they're not (at least not in the format the Presets module would save them).

I don't know if this is a bit of a hack, but I changed presets_get_presets to the following to ensure only arrays (and only those with the 'version' element) are returned.

/**
 * Function to get presets.
 *
 * @staticvar <type> $presets
 * @param <type> $reset
 * @return <type>
 */
function presets_get_presets($reset = FALSE) {
  static $presets;
  if (!isset($presets) || $reset) {
    if (!$reset && $cache = cache_get('presets')) {
      $presets = $cache->data;
    }
    else {
      $presets = module_invoke_all('presets');
      // Ensure that we are supposed to be calling this.
      foreach($presets as $id => $preset) {
      	// Check that the preset is an array and contains the
      	// 'version' element. This stops the loading of
      	// incorect presets.
      	if (is_array($preset) && $preset['version']){
	        if ($preset['version'] != 1) {
	          unset($presets[$id]);
	        }
      	}
      	else {
      		unset($presets[$id]);
      	}
      }
      drupal_alter('presets', $presets);
      cache_set('presets', $presets);
    }
  }
  return $presets;
}

Note that if you've already installed Presets, it seems (and I don't understand the mechanisms behind this) that you need to change the function definition to function presets_get_presets($reset = TRUE) (i.e. change $reset to TRUE) for the first time this function is called. (Change it to TRUE, then clear the cache, then you can change it back to FALSE and it seems to work fine from then on).

Once I did this, I was able to clear the cache through drush without any errors and could then access /admin/build/modules.

I'll leave the issue open in hope that someone could step in and explain what's really going on and whether this is an okay workaround or whether it has any impact on the module. I'm only using Presets so that SEO Tools runs, so hopefully it should be okay.

Thanks.

Okay it looks like my changes completely break the Presets admin page, so don't use them!

Actually it seems ok. After clearing the cache a few times I can get to /admin/presets/seotools. I can't see anything on /admin/presets but it appears that function calls a block of some sort and I have Panels Everywhere installed, which disables all blocks in the theme, so this could be the reason why.

The problem is that it's invoking hook_presets(), which tries to call modulename_presets() on every module that's enabled. However, modules like ImageCache already define that function (in this case, imagecache_presets()) for their own use - it's a namespacing issue.

Since this happens in several other modules that have much larger usage stats, trying to get them to change won't be a good way to solve this.

I propose renaming hook_presets() to something like hook_presets_preset_list()—that is, the module name plus the intended action—to ensure that it won't conflict with existing modules.

However, a change like this will require an update to any other modules that depend on Presets. For example, seotools_presets() would need to be renamed to seotools_presets_preset_list(). This will be a problem if the user updates Presets but not the modules that rely on it (or vice versa). I'm not sure how best to handle this: simultaneous releases of updates, defining seotools_presets_preset_list() right in the Presets module to call the old seotools_presets().

I am having the same issue. I suppose I cannot use seotools until it is fixed. I don't know php or I would write a patch for both modules. If someone who does know php could submit a patch to both at least we could apply them until the releases get synchronized with the new namespace.

Would this be as simple as find and replace, or is it more complected than that?

Thanks a ton for this module. I can wait to use it via seotools.

Craig

Created an issue on the seotools page as well

http://drupal.org/node/1310962