Edit machine_code in UI

I actually went back and forth on showing that field. We came to the conclusion that it might confuse users. I would be willing to add a permission that shows/hides it for users. What that be acceptable?

Untested patch attached. (my favorite type)

Cross posting #1408616: Machine name improvements

This patch is more or less the same as #3.
Differences are:

• It keeps the form in a nice order on both the bean type creation and bean edit forms. If the user clicks the 'edit' link for the machine name, the machine name field populates directly below the label field.
• It also addresses the length limit issue from #1408616: Machine name improvements by updating the DB schema, and changing the maxlength attribute on the machine name fields.

Hmm.. actually on further testing, #5 doesn't work.
The machine name field validation seems to be complaining about the dashes.

This is a bit more robust of a patch.. It includes everything from #5, and changes deltas so they use underscores instead of dashes. Including an update hook to rewrite any existing dashed deltas as underscored deltas.

This one works for me with every curveball I've thrown at it thus far.

Ok, third time's the charm.. same as #6, but also updates deltas in the block table in the update hook.

@willvincent, thanks for the patches! I've made a few comments below.

Let's try to keep the delta with dashes. It's used in URL's and I'l like to keep it as compliant as possible. Feel free to ask any questions.

Great work!

+++ b/bean.installundefined
@@ -176,3 +176,42 @@ function bean_update_7006() {
+function bean_update_7007() {
+  $spec = array(
+    'description' => "The bean's {block}.delta.",
+    'type' => 'varchar',
+    'length' => 255,
+    'not null' => TRUE,
+  );
+  db_drop_unique_key('bean', 'delta');
+  db_change_field('bean', 'delta', 'delta', $spec, array('unique key' => array('delta' => array('delta'))));
+  return t('Updated maximum allowed size of {Bean}.delta field values');
+}
+
+/**
+ * Rewrite bean deltas as lowercase with underscores (instead of dashes).
+ */
+function bean_update_7008() {
+  $deltas = db_select('bean', 'b')
+              ->fields('b', array('delta'))
+              ->execute()
+              ->fetchAllAssoc('delta');
+  $count = 0;
+  foreach($deltas as $delta => $data) {
+    $query = db_update('bean')
+               ->fields(array('delta' => str_replace('-', '_', $delta)))
+               ->condition('delta', $delta, '=')
+               ->execute();
+    $query = db_update('block')
+               ->fields(array('delta' => str_replace('-', '_', $delta)))
+               ->condition('delta', $delta, '=')
+               ->condition('module', 'bean', '=')
+               ->execute();
+    $count++;
+  }
+  return format_plural($count, 'Updated <em>1</em> Bean Delta', 'Updated @count Bean Deltas');

Update 7007 and 7008 can be in the same update since this is a single patch

+++ b/includes/bean.core.incundefined
@@ -288,6 +288,14 @@ class Bean extends Entity {
+  public function changeDelta($original, $values) {
+    $this->delta = str_replace('-', '_', drupal_clean_css_identifier($values['machine_name']));
+    db_update('bean')
+      ->fields(array('delta' => $this->delta))
+      ->condition('delta', $original, '=')
+      ->execute();

I would rather have a Bean::setDelta($delta) method then leave the db change in the Bean::save() method.

+++ b/includes/bean.pages.incundefined
@@ -269,6 +285,15 @@ function bean_form_submit($form, &$form_state) {
+  if (!empty($insert)) {
+    if (isset($form_state['values']['bean']->delta)) {
+      if (isset($form_state['values']['machine_name']) ¶
+          && $form_state['values']['machine_name'] != $form_state['values']['bean']->delta) {
+        $original_delta = $form_state['values']['bean']->delta;
+        $bean->changeDelta($original_delta, $form_state['values']);
+      }
+    }

We don't need 3 levels of nesting if we don't have else cases. Just do one if with 3 checks.

I can see the use cases for renaming BEANs and I think it makes sense. However, I am concerned about an update hook renaming BEANs with no warning to the admin. I currently have a site which is making extensive use of the BEAN module. This proposed renaming will break large parts of our site as we place our BEANs (blocks) using the context module.

The machine_name form element allows you to define the characters allowed for the field. The default is [a-z0-9_], but this can be changed to [a-z0-9_\-] so existing BEANs are broken.

Changing priority. It does not make any sense to me that it can have a minor priority and still be a release blocker.

Oh yes, bean_update_7008(). I do not have very warmly feeling for changing the machine_name. As mention in #9, we can break a lot of stuff, and going from RC6 to RC7 (or 1.0) should really not do stuff like that. I suggest we move this issue to 7.x-2.x-dev. I'm OK with breaking stuff but I do not feel now is the right time.

Ops

Removing Release Blocker.

BTW changing the block delta field to 255 will cause problems with integration with the core Block module, which only allows the delta to have a maximum length of varchar(32).

+1 for this feature, controlled by a permission. I found myself creating a bean instance using the words I'd want to become the delta, then editing it to rename with a more admin-friendly label.

Another note to add about hyphens vs. underscores -- if the deltas are saved with hyphens, you won't be able to implement hook_block_view_MODULE_DELTA_alter() for them (because the hyphens wouldn't produce a valid function name). This same issue was discovered for menu blocks: http://drupal.org/node/1076132. FWIW, core block-related URLs, i.e. admin/structure/block/manage/..., have the underscores in them.

definitely +1 for this too. In bean_panels, we allow kind of placeholder beans to be placed within panel regions. That means that a panel region references a bean with a specific delta. If a bean with the delta doesn't exist, a link to create it is shown instead. However, without being able to control the machine name, the best we can really do is how that content editors create the bean with the correct name so that the resulting bean has the expected delta. Ideally, we would be able to pre-populate the bean machine name from the url, but until we have a way to set the machine name manually this is impossible.

Just stumbled on another motivation for using underscores in the deltas. In my module I created a custom theme hook for part of a bean block's output; let's call it 'my_bean_output'. Then I went to use it as a base hook, naming the hook suggestion with the bean block's delta as the dynamic suffix. So in my bean class's view() function, my render array looks like:

$results = array(
  '#theme' => 'my_bean_output__' . $bean->delta,
  '#nodes' => $nodes,
);

And then in the site's custom theme, I added a template that would implement this hook: my-bean-output--my-block-delta.tpl.php. But my output was blank, and I realized #theme had been set to 'my_bean_output__my-block-delta', but drupal_find_theme_templates() converts hyphens in the template filename to underscores and thus my template was stored in the registry as implementing the theme hook 'my_bean_output__my_block_delta'.

The simple workaround is '#theme' => 'my_bean_output__' . strtr($bean->delta, '-', '_'), but it's not intuitive without digging into the theme and phptemplate engine system.

I've created a commit to implement "Edit machine_name in UI base permission", anybody can help me create a patch here.

My code is on Github: https://github.com/hutushen222/Bean/commit/41459fe26b19664d30dcf77b72e0b...

I've just faced a problem of this delta / label thing. When create a bean and label is Chinese/Japanese, e.g.: 保守付Lレンタルのご案供 (mysql length is 34), it will have an PDOException error because of delta value.

So, considering the multilingual sites or non English site like Chinese/Japaneses, who uses bean may face this problem a lot. A editable machine_name or auto-generated delta will be a needed requirement. Furthermore, delta saved in db is also Chinese..