It is with version 0.9.5. You can download the dev version, but I haven’t gotten the image uploader working with that yet. Soon! It is the holidays, but I’ve been trying to get 0.9.5 out the door, and the “multiple images” feature is one of the biggest features there.
You can sign up for the mailing list if you want to get pinged ahead of time — I try to let people know what’s in the pipeline, and it gives folks a chance to test drive the release candidate and report any bugs before it gets pushed out to the public.
Just signed up for your list. Looking forward to new version of plugin with multiple image per field support.
I do have one request. When you setup the ‘relation’ field type I wish you could specify a post type you will be choosing from so you get only the relevant choices to pick from vs having to select from every single post in the dB
“specify a post type” — that and more is already implemented in 0.9.5. When you set up a new relation field, you’ll be able to specify EXACTLY which posts are available for selection by using any input available to Summarize Posts’ get_posts() function (see this to see how flexible the filtering is: http://code.google.com/p/wordpress-summarize-posts/wiki/get_posts) — you can do basic filtering (e.g. on post_type) or on taxonomies, custom-fields, etc — the default filter will be cover basic stuff (like post_types), but the filter will be completely customizable (although, admittedly, it’ll take me a while to document all of this).
Cool. So is this ‘multiple fields’ of a custom field going to be just for images or will it apply to all field types? (Like text fields too – I’m specifically looking for support for 1 – n number of text areas on a page.
Great looking module – thank you!
It will support all relation fields (relations, images, media), and text fields. I’m still working on the dev version, so I can try to add some support for the textareas as well — donations appreciated 😉
Multi-selects already let you select multiple values (which is essentially the same thing), so there’s no need for them to be repeatable. I might add support for other field types too… just depends I guess. The one that I probably won’t be able to do multiple instances of are the wysiwyg fields (due to WP’s poor implementation of the underlying functions).
Just installed the 0.9.5.0-dev version and realized I need a 1 – n number of WYSIWYG elements. And also a text field to be used as a title – possible to have these grouped? So something like
Add New ‘custom page type’
Title 1
WYSIWYG 1
Title 2
WYSIWYG 2
[Add another] — this would add Title 3 / WYSIWYG 3. Or how else would a user add another one?
Any thoughts on how to implement this? If we can just get multiple / arbitrary number of wysiwg boxes I will be able to use this and will happily donate. (Any suggested donation amount…)
thank you!
You can set up a predefined number of fields, and that’s the easiest route. Supporting N fields is much trickier, and with WYSIWYG fields, it’s a disaster: the good folks at WP apparently gave no forethought to the possibility that their code might actually get used for something other than the narrowminded usage that it normally gets used for as the post’s main content block. There are some really stupid things in the WYSIWYG fields that were blatantly hard-coded making it nearly impossible to use in a modular fashion. The end result is that I have to re-invent the wheel on this stuff because the script-kiddies who developed parts of WP obviously had no idea what they were doing. (Harsh, I know, but I’m continually shocked by how piss-poor the WP architecture is).
Re the text-field title: I wouldn’t recommend that for the same reasons: WP was built from the ground up expecting that the post_title would be the title. So all your theme’s and related functions and hooks would be tying into the_title() function, NOT to your custom field. Things in the manager get really unpredictable if you omit the title and content blocks. (again, jaw-droppingly poor architecture in this app, but whatcha gonna do?). You could do this: create a post-type with a standard title field (just like normal), but in your single-xxxx.php template file, do this:
<head>
<title><?php print_custom_field('my_title'); ?></title>
...
<body>
<?php print_custom_field('other_field'): ?>
</body>
</html>
Know what I mean? Again, the way WP has blurred the layers of the application in the standard WP themes is a complete and utter mess, but in a well-constructed view layer, you could simply print whatever field you wanted in whichever place you wanted. Kill the loop and the “has_posts()” bullsh*t, and the WP template files start looking halfway sensible. (I’m pretty burned out on the WP architecture right now… I’m working on a book comparing MODX to WordPress, and dear lord, I’m struggling to make any polite comments because there’s no comparison in the maturity of the architecture).
Another thought: what if you made a simple post-type (e.g. named “blurbs”) with just the standard title and content fields (i.e. the built-in WYSIWYG field), then back in your other post-type, you set up a relation field that pointed to however many instances of “blurbs” you need. Would that work? My guess is that there’s a better way to do what you’re trying to do. e.g. why not just add a <!--separator--> tag to your WYSIWYG field to distinguish between sections? There aren’t many use-cases I can think of where you need the infinite N instances of a field, relations being the notable exception.
Thanks for the feedback and I hear you on the architecture – I’m doing more Drupal development these days for precisely that reason.
I think you took my example of a ‘title’ field too literally. Let me give you a better example. I need a page where the author can set an arbitrary number of employee bios on a page. Each bio has an image, the employee’s name (the “title”) and then a paragraph containing the bio (WYSIWYG field). Each department gets it’s own page and then each department can have 1 to N employees listed down the page. The image can be part of the WYSIWYG field but I need a separate title/name field so I can make a list of href anchor based links at the top of the page for each name which would jump to each bio.
This is elementary with the CCK Drupal module – just create a group of these objects and then when the author edits the page they get an “add another group” button of these objects.
Thanks again for the feedback.
Wow… I don’t have much good to say about Drupal’s architecture either, so you must have a tougher skin than I. Drupal templates are just as bad as WordPress’, and their support of custom content (with the CCK) is nightmarish if you need to deal with the data manually via MySQL. On the whole, Drupal offered a cleaner manager interface for custom data, but it ran afoul of many architectural norms. That was many moons ago, but I’ll have to cross-check the CCK again to see if it’s database patterns offer any improvements on the CCTM… off the top of my head, I can think of several disadvantages of how the CCK stores its data (notably the limitations of Drupal’s @!#% node pattern that isolates tables making search forms impossible to code). The big problem right now with the WYSIWYG fields has to do with WP’s TinyMCE integration — if WP cleans that up, I could make them repeatable. I just don’t foresee having time to recode all of that WP slop outside of a paying gig.
Re the bios, this sounds like you should create a post-type for “bios” — you could give it an image field for the mugshot and a relation field that points back to an employee. That’d give you links to each bio, and you could pull up the data about the employee by looking up the data for the employee ID. Know what I mean?
The more I think about this, the more I think I need to come up with my own way to attach TinyMCE to the textarea fields… WP’s integration is just too unpredictable.
