Wrong parameter order in features_get_default()

What I found is that you need to change the order of the variables every time features_get_default() is called in fe_block.module

Line 157

$defaults = features_get_default($module_name, $component);

Changed to

$defaults = features_get_default($component, $module_name);

You need to do that every time this function is called in the module.

You may have a look here (and apply patch in #5): http://drupal.org/node/879588

3. Enabled feature on staging site - At this point I was experiencing the eval'd error so patched to fix

I'm having the same "eval'd error". Is this documented or discussed somewhere? Can you post a link?
Thanks.

EDIT:
Ok, must be this one: #769660: expecting T_STRING or T_VARIABLE or '$' in sites/all/modules/features/features.export.inc(590).
No "eval" in the issue title, this confused me.

I applied all three of the patches recommended in the link to #3. IE #769660. But still have this issue. The block is never properly imported. Further for existing blocks provided it doesn't work either. If I revert it works.

Seems there is a part of the process in features that isn't getting called to enable the default configuration. Does anyone know how or where this is suppose to happen?

Can someone verify that this code doesn't work? Here are the steps. (from memory)

1. create a block
2. Create a feature exporting this block (shouldn't need to apply any patches because they have been added to dev).
3. Save of the feature.
4. Setup a brand new install (or new database).
5. Try to enable the feature.
6. Does the block show up? It didn't for me.

I am fairly certain this is because there is no fe_block_settings_features_rebuild function.

Confirmed. This is related to issue #879588: Wrong syntax order for features_get_default() breaks all Features Extra modules, and has to do with the correct argument ordering being switched to incorrect for the two functions that manage boxes. this patch resolves the issue.

-Chris

given that exporting blocks (specifically boxes) with features extra can't happen w/o this patch i'm bumping this up in priority.

#8 seems to cause the blocks to be imported along with the settings, but the feature still appears "Overridden".

@idlewilder,

enable the diff module and compare the overrides. I'll bet you exported with one set of themes enabled, and are now looking at it with another set. if not, then you haven't applied the patch in comment #6.

subscribe

The patch above is a duplicate of a previous one and is already in the latest code.

I am reopening this issue because I believe something else is going on here (as well). I have been having the exact same problem, but with 7.x-1.0-beta1. I was able to retrace this to where the module writes changes to the block-table; it always uses drupal_write_record complete with the optional primary keys array. The presence of this array indicates to drupal_write_record that it is an update, but in case of new blocks, it should be an insert, in which case the primary keys array needs to be left out. The attached patch checks if the block exists and does an insert or an update accordingly.

@eelkeblok, you shouldn't add new blocks by writing them to the database. Blocks are created by using hook_block_info(), and the entries in the database are created by _block_rehash().

Also please do not reopen issues needlessly. This issue was about a function call that had its parameters mixed up and this was fixed more than 2 years ago in the 6.x-branch.

Apologies, I was not fully aware Closed (fixed) issues should not be reopened. Apart from that, and until you changed the title in #15, the title and description together looked in fact like the exact problem I was running into. Also, from the various comments, it looked rather like contributors had lost interest, instead of the issue actually having been resolved.

So, indeed, anyone finding this, please disregard the patch. Since submitting it, I did find this is not the complete picture, as the blocks (defined by menu_block module, which at first didn't seem particularly relevant, but in fact appears to be highly relevant) were still not being created. Menu_block module uses variables to define its blocks, so to export menu_block modules, you also need to add the variables relevant to the block. It is very confusing, being able to select the block for inclusion in the feature and then not actually having it created on a new environment. This seems to be more a specific issue with menu_blocks combined with Features Extra, though, instead of a general problem with Features Extra.