Image gallery to have multiple galleries inside one post

[ShaneF]

I have made this extension on the base [gallery] short code and "design" where you can go [gallery group="2"] and it would show only images in group number 2. This way if you had images you wanted to place individual within a post without it having to be the posts gallery.

By default in my code, each image that is uploaded is in the "-1" gallery which means if the gallery tag was just entered "[gallery]" it would not show up. "0" being the default (i.e. [gallery])

Below is a screenshot of what it does including the patch file I created off the 2.6.1 tag. When doing this off the trunk.

[ShaneF]

Screenshot of it in action

[Viper007Bond]

+1 to the feature, although I'm a bit impartial to the implementation. It'd be nicer if you could do this via dragging, like a box per existing gallery + an empty box to drag into to create a new gallery for example.

[ShaneF]

I was originally looking at that, but then a new table called "galleries" would be needed to create together. I thought of this as a "quick" way to do what I wanted to do :P

[ShaneF]

I'll see if I can improve on my design. This was a rough thing I put together last night so I could display all my pictures in separate galleries on one post on my blog. :)

[ShaneF]

@ Viper007Bond

This is the update look (attached). I am still working on the jQuery problems when moving around to the different galleries and updating the value, but I will keep you posted.

In this version, I forgot the "Add new group" button and "remove group"

[AaronCampbell]

+1 here as well. I agree with Viper on the dragging being more intuitive. However, I'm also not a fan of having images upload to -1 by default. I think that the base [gallery] tag should show everything by default (with no additional work), and that anything you DON'T want to show should need to be moved to a different group.

I also think we should add an "Insert this gallery into post" button to each group.

[ShaneF]

In the update version that I worked on, everything defaults to 0, being the non-gallery items.

I will change the behavior to make [gallery] do all minus the items that are non-gallery items (i.e. 0).

I was thinking that wasn't needed, but since I'm changing the way it works, I will do that."Insert this gallery into post".

[ShaneF]

Everything should be done. Ready for testing! This newest patch is off the 2.7.x trunk.

[Otto42]

+1, I like it.

[ShaneF]

Minor update to the gallery.js file, but still having the problem with the ordering. Maybe a "Re-order button" ??

[ShaneF]

grrrr... extra space not needed

[ShaneF]

Ok all. Need your feedback.

Myself and DD32 have been talking on how this should be done.

Right now as this patch stands, the gallery works by adding two extra columns to the 'posts' table. 'groups' and 'group_number'. 'groups' is assigned to the row of the post itself indicating the groups that are around. Currently it's stored '0,1,2' as in there is 2 groups + default one. This is right now being changed to just being '2' to indicate the same thing. 'group number' is assigned 0 or 1 or 2 on the attachment row in the posts table indicating what group it is part of. Using the 'post_parent' part as the reference back to the post's ID number during query.

DD32 suggested that the gallery information be moved to the postmeta section as a new key "_wp_gallery". The postmeta.post_id would refer to the post number itself. Inside the 'data' area would be a serialized data field storing the number of gallery groups and what images would be in each group referring back to either the posts table or to the postmeta.meta_id of the image description itself.

I have generally opposed to the idea since doing so would fundamentally change how the original gallery system works. Granted this is a new feature, this wouldn't be much of a problem since no one else has to worry about a new "structure" except my production blog.

So the two options are (A) Work off the post table where no extra queries need to take place since it already gets information off the entire row during post retrieval or (B) store the gallery information in postmeta.

Feedback welcomed! :)

[Otto42]

The "groups" column seems unnecessary to me. Why does the parent post of these attachments need to know how many groups there are? What happens when you have it say "2" but there's actually an attachment with a group_number of "3"?

My suggestion would be to simply add a "post_group" column to posts. Make it a bigint(10). Attachment posts can get grouped together by virtue of all having the same value in that post_group column. The parent post of them can leave it blank.

Additionally, with this plan, the group column is more generic. It can be used for other things as well, if you want to group any set of posts together in some fashion in the future. Much like the term_group column.

[ShaneF]

The post needs to know how many groups there are so it can create the separate groups in the 'gallery' area. The same function I am manipulating to show the different groups is not only used in 'gallery' but also in the 'media library'.

If I were to post the information in postmeta, now that I think about it, I would have to re-write on how those two sections get there data.

[Otto42]

Yes, but it's already pulling all the attachment posts too, to get the data about those. So, can't it just count the number of groups? The count information is just redundant there.

[DD32]

DD32 suggested that the gallery information be moved to the postmeta section as a new key "_wp_gallery". The postmeta.post_id would refer to the post number itself. Inside the 'data' area would be a serialized data field storing the number of gallery groups and what images would be in each group referring back to either the posts table or to the postmeta.meta_id of the image description itself.

Ah no, What i meant, Was to add to each of the attachments a metakey refering to which gallery they belong, eg, 1, 2, 3. The number of galleries can easily be determined in PHP, Dont be afraid of looping over attachment metadata, unless its in the thousands of attachments for a post, storing the actual number isnt going to be an issue, infact the object cache can be used to cache that number if need be.

You could add a metakey to the actual post to tell it how many galleries there are if theres multiple galleries and it actually needs it.

a post_group column that Otto42 suggests could be useful i guess too.

[ShaneF]

I was talking with ryan, and it seems the overall media system might be getting an overall where attachments (videos, images, audio, etc) are not linked to just the posts that they were uploaded on. So they can be independent.

With this in mind attachment system might need an overall before this idea is finalized on how to implement it. Moving the attachments from the posts table into a new table will change basically how everything will work including how this ticket is develop. I'll be working off ticket #7764 for independent attachments first, then complete this as needed.

[DD32]

I've been thinking about this, and #7764, and i've come to the conclusion that another table is really pointless, It feels like a step back to the post2cat and link2cat tables which have been dumped in favour of the new Taxonomy system.

My suggestion:

• Leave the attachments as they are
• Define a new Taxonomy ('gallery') - like post_tags
• Name a gallery as a new Term (ie. 'Flood Photos')
• Add "Show in Galleries: [Flood Photos], [2008 Photos]" like interface to attachments, "Attachment posts" get linked via the taxonomy system
• Add a "Insert Gallery [Flood Photos], [2006 Photos], etc" to the media page under gallery or somesuch
• Upgrade script would pick up the current galleries and add the new taxonomy & terms as "My-Post-Name Gallery", link 'em all up, etc.
  • There'd need to be an adition to [gallery] to select the first gallery term attached to a post for backwards compat. Extra galleries could be used as such [gallery id=34] or [gallery name="post 24's gallery"]

• Using the taxonomy system has the advantage of the fact its allready used to group posts together, It was well thought out and doesnt appear to have too many downsides, Its a table that allready exists, The upgrade proceedure shouldnt be too difficult, it satisfies not needing a extra table or columns to be added to a table, and most current attachment methods would still work.
• It does have some downsides, Current themes and scripts would not be able to take advantage of multiple galleries, However, Backwards compatibility would be still held possible by marking the post_parent as the post its uploaded with (even though it'd be near useless to do now)

There was a 2.7 Ideas idea for a new 'Gallery' post type: ​http://codex.wordpress.org/Version_2.7 too, This sort of fits in with that idea rather well, while being more flexible than a gallery post type.

It would also open up the door for more advanced gallery functionality in future versions of WordPress, While WP is a Blogging/CMS platform to start with, Images and Galleries of things are becoming more common with todays online content, so its something that needs to be ready for those who want to use it. Other applications such as Gallery2 exist to fill these slots i admit, But they're simply a gallery, not a CMS.

Of course, this is all just my opinion, but it really seems like the best solution out of what i've thought of, and what others have mentioned.

[ShaneF]

Without having to copy all of that, I will make the changes once my internet is fully up and running to use the tax system.

[ShaneF]

I am bring up the priority so we can get this implemented so we are not rushing this and do a shabby job. I'll be working on it when I can tomorrow.

[ShaneF]

OK! Let me give you an update on what is going on with this patch file that I am about to upload. First of all, this is a complete "re-write" of the system to allow there to be no structure change in the database, which has been a major dissent among most of you, but I have solved that problem. Keep in mind! I have no created an upgrade script yet. Use this patch at your own risk.

This is a sample serialized data: a:2:{i:0;a:2:{s:4:"name";N;s:5:"items";a:1:{i:0;i:3;}}i:1;a:2:{s:4:"name";s:13:"This gallery.";s:5:"items";a:1:{i:0;i:4;}}}

The system now users the "postmeta" table to store the gallery information for a thread. Using the post_id as a reference back to the post/page that you are using, it gets a serialized array stored in "_wp_posts_attachments" key. Which basically hold the "name" of the gallery (New Feature!) and the attachment ID numbers (from the posts table).

Attachments can still run-normally with going back and forth between the different items.

[gallery] from the original idea has not changed. [gallery] outputs all items regardless of the group number. Right now I have it outputting even the items in non-group area, but that may change to the original way where it just be in the groups 1 and above. [gallery group="1"] would show the group one items. In both scenarios it's using a new function called "get_attachments( $post_id, $group_num = null, $args = )". What is currently not working, and if anyone wants to work on it, the args are a mystery to me. I know how get_childern do it, but that's not what we are doing here. Any help in this section would be great.

What is currently not working in this version is "Save Changes". I wanted to wait till tomorrow before working on this critical piece of code. Hopefully it will be snap to complete, but with my new gallery name area, this could get a bit wacky, but I will get it! :)

Images/Audio/Video is still in the posts table and is still working and still beinging assigned a post_parrent to the post/page that it belongs to.

Questions? Comments?

[ShaneF]

I am working on some of the other features that DD32 suggested, I just wanted to get this "core" part patch reviewed by you guys/gals.

[DD32]

_e('Group (' . $i . ') ' . $group_name . ' ' . $group_link); 

Just a note on how translations work: The __() and _e() functions must be passed an exact string, dynamic strings are useless, Instead you'd use:

printf( __('Group (%d) %s %s'), $i, $group_name, $group_link);

I'm also setting the Priority back to Normal, If it gets in, it'll get in; Priority is mainly useful for defects.

[Viper007Bond]

Actually, wouldn't it be this?

printf( __('Group (%1$d) %2$s %3$s'), $i, $group_name, $group_link);

That way the order of the dynamic bits could be controlled.

[DD32]

Actually, wouldn't it be this?

Ah yes.. I allways forget about the ordering of them..

[ShaneF]

Replying to Viper007Bond:

printf( __('Group (%1$d) %2$s %3$s'), $i, $group_name, $group_link);

Done.

[ShaneF]

Ok. I this latest version it saves the "Group Names". You can from another post do [gallery name="Hello Word!"] and [gallery name="1"] and you can sub-group it also with the name parameter. I didn't do "id='1'" but it would be easy to add. Gallery format should now be XHTML 1.0 compliant.

A new attribute added was "class" which will (once I update the options page) for lightbox, etc.

[Viper007Bond]

"id" is already in use. It allows you to call another post's gallery.

​http://codex.wordpress.org/Using_the_gallery_shortcode

I would like to see [gallery id="123" name="Hello World"] if there isn't support for that already though.

[ShaneF]

name I reserved for the post/page title. You can go... [gallery id="123" group="1"] and it just get group 1 items from post 123. I can make "group" allow the name of the gallery inside 123 and it show that. [gallery id="123" group="Sunset Photo's"] which could be the equivalent to [gallery id="123" group="1"].

In any case, diff 3 is the version that has the upgrade script attached. Minus the fancy stuff of browsing all the gallery's in a list, this is pretty much ready for testing. The script has yet to be tested by myself, but I will report on that later.

[ShaneF]

Currently working out a few bugs I found during the move to my production server. Will post once complete.

[ShaneF]

7607.3.diff is ready for commit. :)

[ShaneF]

Working with the latest changeset.

[ryan]

Moving enhancements to 2.8.

[ShaneF]

This is being closed as this system is way outdated. Will be brought back under a new ticket. Closing own ticket.