The added patches open the door to use more parameters to configure/administer/develop the image inserts.

It is now possible:

Advanced image grouping; see example code:

/**
 * Preprocess variables for the pirobox-insert-image.tpl.php file.
 */
function template_preprocess_pirobox_insert_image(&$variables) {
 
  // Group images.
  $variables['gallery_id'] = '';
  switch (variable_get('pirobox_insert_gallery', 0)) {
    case 0:
      // Post
      $variables['gallery_id'] = 'gallery-' . $variables['node']->nid;
      break;
    case 1:
      // Page
      $variables['gallery_id'] = 'gallery-all';
      break;
    case 2:
      // Field post
      $variables['gallery_id'] = 'gallery-' . $variables['node']->nid . '-' . $variables['item']['field_name'];
      break;
    case 3:
      // Field page
      $variables['gallery_id'] = 'gallery-' . $variables['item']['field_name'];
      break;
    case 4:
      // Post per user
      $variables['gallery_id'] = 'gallery-' . $variables['node']->nid . '-user-' . $variables['item']['uid'];
      break;
    case 4:
      // Per user
      $variables['gallery_id'] = 'gallery-user-' . $variables['item']['uid'];
      break;
    case 6:
      // No gallery
      $variables['gallery_id'] = rand();
      break;
  }
}

I wait for include this patches to contribute the upcoming Pirobox module.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

quiptime’s picture

Priority: Normal » Major
FileSize
21.95 KB
14.71 KB

bump

In order to visualize what is possible with the patches. I have attached 2 screenshots.

1. The image before_patch shows the very simple ability to configure the grouping of images - Colorbox module.
2. The image after_patch shows the enhanced ability to configure the grouping of images - Pirobox module. The selection options correspond with the sample code of the initial post.

quiptime’s picture

@quicksketch,

I'm waiting for feedback.

quiptime’s picture

@quicksketch,

please take a look at my Pirobox module issue: http://drupal.org/node/1339636

quicksketch’s picture

Title: Patches that allow to extend the functionality for more usability » Pass node objects to Insert widget to allow for 3rd party functionality
Priority: Major » Normal

I don't know about this patch because in Drupal 7, Insert (like other fields) can now be used on anything, not just nodes. This patch certainly wouldn't work for users, terms, or comments.

quiptime’s picture

Right, does not work with the entity types user, comment and taxonomy term. This is not a problem. I've changed my patches.
Now they are working with the entity types node, comment and taxonomy term. The entity type user are not included.

I'll post soon the updated patches.

But, it exist a bug in the Insert module. Because of this bug, it is not possible to insert images into comments and terms. This bug is known but unfortunately not yet fixed.

quiptime’s picture

Status: Needs review » Patch (to be ported)
FileSize
52.38 KB
767 bytes
613 bytes
2.98 KB

Here are the announced updated patches.

This makes it possible to work with entity types node, comment and taxonomy term.

The attached image shows what is possible with the patches.

quiptime’s picture

bump

quicksketch’s picture

Status: Patch (to be ported) » Needs work

Hmm, I'm okay with this new approach if the following changes are made:

- Use entity_load() instead of making pseudo objects for each type in D7.
- A backport patch is also provided for D6.

If you could roll it all into a single patch too, that would also be appreciated;

quiptime’s picture

I will reorganize the patch code using entity_load() and roll out the patches into a single patch.

The backport patch for D6 coming soon after:
At the moment i develop on the new Pirobox module (with Insert module support). This has a higher priority for me as the D6 port.
The D6 port will come - I promise.

Is that for you so fine?

quiptime’s picture

FileSize
4.5 KB

Here are the announced updated patches as single patch.

NOTE

@quicksketch, think simply.

The use of entity_load() is not necessary! This produces unnecessary overload.

The needed entity informations are already available! This is based on my patches #6.

quiptime’s picture

bump

quicksketch’s picture

Hey @quiptime, not sure if you're still interested in this patch or not given it's been so long.

But the current patch has a section that doesn't make sense:

+  switch ($element['#entity_type']) {
+    case 'node':
+      $entity = entity_load($element['#entity_type']);
+      $entity = $entity[1];
+      $entity->entity_type = 'node';
+      break;
+    case 'comment':
+      $entity = entity_load($element['#entity_type']);
+      $entity = $entity[1];
+      $entity->entity_type = 'comment';
+      break;
+    case 'taxonomy_term':
+      $entity = entity_load($element['#entity_type']);
+      $entity = $entity[1];
+      $entity->entity_type = 'taxonomy_term';
+      break;
+  }

This should be more like this:

$entities = entity_load($element['#entity_type'], array($entity_id));
$entity = reset($entities);

This will work with any entity, regardless of its type.

Snater’s picture

Status: Needs work » Closed (outdated)

Browsing through old tickets while working on the module's D8 version, I had a look at this one. I think this is a reasonable change, except for the annotation made in the most recent comment. I would also propose to just pass on $element instead of loading the entity which is not required by Insert itself. Animated by this ticket, I implemented that in the D8 version. In my opinion, whatever module requires loading the entity should load it by itself.
With the last comment on this ticket six years ago, I am closing this ticket. However, if there is still use for having that implemented, feel free to reopen.