Randomland - The Forum

Last weekend I made a Drupal module to display a custom image block (seen here (http://randomland.net/sandbox) if you have permission). It just pulls the image node description and sets the alt text and throws a gallery link at the bottom. It can be called by simply inserting [rlimg <node#>]. It needs a little refining if we're going to use it. It was an idea I had toyed with trying for a few months; I just tried it out on Sunday and got that. And making it a Drupal module seemed like a good learning experience.

Does anyone see any benefit in using this? If so, we could expand our toolset in include other commonly used elements.

I like it. I also like that it pulls the image from a node. If in the future that nodes image changed then you have updated that picture site-wide (say your replacing a low quality or outdated image)

Oh -- a potential pitfall I just thought of though -- if that image ever gets deleted, and a new one is added in its place, you'll have to update place that references it. Because the node IDs are not ever recycled, I don't think. But that's not much worse than static linking. Just don't delete the nodes.

And you can always fix it by hand in the database, though thats not desirable to do often. So be strong, don't delete! Just unpublish if need be. 

Exactly!

Quote from: Nick on Oct 22, 2009, 07:10 AM
...be strong, don't delete!. 

:) This phrase, along with "swamp diving" need more obscure references on this site! I actually did have a "be strong, don't delete" page up once, years ago. Back in the free-stuff-and-t-shirts days.

I would wear one of those shirts. We should also make some pamphlets to hard out to offending deleters to enlighten them of the atrocity that they are committing!  Or maybe just for download.

Maybe we should make a tri-fold pamphlet, complete with dying polar bears and crying applesauce. And some nonsense argument about future generations having a skewed perspective on life in the early 21st century because of posed portrait shots*. Or maybe we shouldn't do that.

*It's more likely that we'll be viewed as idiotic for all of our worthless "look, it's me in the mirror" snapshots, offensive avatars, and haphazard framing of shots.

I do like me some good satire.

It used to spring from my fingers like a mighty flowing river onto the pages of the Randomland. But here we suffer the dead heat of the summer of satire, for my river doth run dry. Oh! how I long for the refreshment of the winter solstice.

How poetic.

Yeah.

Another thing that I would find useful when writing pages is the ability have links autogenerate the title text. This would be quite easy to implement.

Just go:
[rllink 150 "Tentin'"]
And it makes
<a href="http://randomland.net/node/178" title="Tentin' on the Ten-Ten â€" Fall Camping Trip, 2009">Tentin'</a>

And any changes to the node title would be automatically updated. Hover text ease! There is likely something out there that is 9000x more powerful and written back in like 2005. I think I came across something similar once. Oh, did I mention the part where it would take 3 hours to configure and learn to use?

So, should we continue to use my little image block module, or ditch it for straight embedding of images? I never quite got the divs to float around like I thought they should, but it's almost right. I think our normal "Full HTML" input type does something nasty to the code -- just try [rlimg 237] or whatever on its own line. It makes a big fat box all the way across the screen. Or perhaps I don't understand what I'm doing.

Either way, the question stands: Expand RL module? Leave as is and use? Or ditch it?
Note: this applies to anyone who might ever write something on the main site. AKA: anyone looking at this.

It does do horrible things to the code. It ends tags early (stops the span from doing its job) and apps superfluous <p> tags. It's annoying.

Yeah. It has to be one of those extra input filters we have on there. I haven't messed with it too much though. I have enabled the rlimg for all input type (including PHP).

I don't believe it's the wysiwyg editor itself causing us grief. I actually like that thing, once I got used to using it. Unfortunately, we can't use that to embed our image blocks (unless I make some weirdo extension to the editor, which sounds possible, actually).

Plah. I don't know. I like uniformity more than I like my module.

Yep. A nice consistent 'look and feel' site wide. 

I changed the Francine pages which I have updated to use the [rlimg] syntax to display pictures. It's not the most awesomest of solutions to embedding images in posts, but it's workable. Maybe I'll go back and edit a few posts at some point. I need to upload more Francine pictures, too.

Check out this site's image block (nevermind the content, I was trying to remember the program name 'msconfig').
http://www.sevenforums.com/tutorials/1401-startup-programs-change.html (http://www.sevenforums.com/tutorials/1401-startup-programs-change.html)

I still think our block is better because we don't embed text in the image. If we changed our "view details" link to be a caption instead, it would be easier for the spiders to associate the text with the image. But anyway, I like their next/prev option in the popup. Perhaps that's one of those thin/thickbox slideshows that I never messed with. Anyway, just another idea.

Yeah, that is some version of the lightbox/thinkbox thing I think. Ours does all that too, it just looks different. You are limited to the images on the current page for sideshowing. But I am sure there is a way around that.

Viewing the images on the current page as a slideshow would be cool for most pages...like camping stories, bike tree howtos, etc.

Its automatic in the lightbox. If you move your mouse to the right or left of the image pop-up you will get next/previous arrows.

This Randomland Drupal module is still plugged in and working, but I found a major bug. The nice floating imagebox (seen here (http://randomland.net/zourtney/2009/11/bike-tree-finished), for example) does not display properly in browsers other than Firefox...though I thought sure I tested it!

It seems that:
a) if a float style is applied, it is ignored
b) if not floated, the black background goes to 100% width

...Actually, I just tested on IE at home and it seems that only the center style is being cranky. I had different results with both IE and Chrome at work. Anyway, apparently I have stuff to fix with the [rlimg] module. Yay?

So, I was wanting to update the style on this little rlimg image block we have everywhere. I started to, but somewhere in Drupal, my CSS is getting eaten and the style is getting messed up. You can see it on the front page (http://randomland.net); just look at the kitty pictures. The border is supposed to be uniform, MUCH smaller, and the exterior border will look rounded (in Mozillas) once I get the padding issues figured out.

Well, I mostly fixed up my rlimg module's styling. The problem was either in my understanding of CSS subclassing, or Drupal's implementation of it (I think Drupal is smashing all stylesheets into one at run time). But, no one really cares.

There are only two remaining problems...or wait, three...or foura few problems:

• Each rlimg block has an overly large bottom margin (see Tentin' on the Ten-Ten (http://randomland.net/rec/camping/tentin-2009) for a good example)
• Each rlimg block says "Caption text goes here" instead of actually having a caption. I'm thinking I'll pull this from the node's "teaser" field, if possible.
• And I forgot to actually test whether or not the double-quote escaping is working
• no one has told me if it is too ugly to use or not
• Lightbox (thickbox?) in-page navigation is not working...you know, it's supposed to have those left and right arrows so you can go to other images on the page.
  

Drupal is aggregating them all into one css file, otherwise IE refuses to get all of our style files. It has a limit of 10 or 20 css files or something dumb. Without the css smasher I think the site uses 25 or 30 files.

which seems like an absurd amount of css, but yeah. Sometimes I want to rewrite the current theme from scratch. But most of the css is probably coming from modules anyway.

So, I'm thinking of making an rlimggrid type thing to extend this module. I had been setting up grids of images with code like this:
[rlimg xxx][rlimg xxx][rlimg xxx][rlimg xxx][rlimg xxx][rlimg xxx]

The problem with this is that Safari and IE were extending the each image's div to the width of the parent. Firefox, on the other hand, just lined them all up horizontally. Anyway, I tried this:
<div style="overflow: hidden">
    <div style="float: left">[rlimg xxx]</div>
    <div style="float: left">[rlimg xxx]</div>
    <div style="float: left">[rlimg xxx]</div>
    <div style="float: left">[rlimg xxx]</div>
</div>

This appears to give the proper grid-like setup in all browsers I've tried. As a niceness, it'll fit as many on a row as it can. This, therefore, plays nicely into our "fluid" layout.

Making an rlimggrid would allow you to style the background of the containing div and customize the look further. As is (see Tentin' (http://randomland.net/rec/camping/tentin-2009)), there's a bunch of padding between the blocks -- I'd prefer a black background with less padding.

Nice. We could use that in the gallery and make it more fluid and conform more with the rest of the site's look.

That could be nice.

I was thinking, if I wanted to go crazy, we could make a slightly different version that would auto-paginate. Just give it a maxRows x maxCols size, or something? But that's a ways off still...I got to fix that dang caption first and foremost.

By the way, the parameter you can pass to the rlimg module is the imagecache preset. This will tell it which version (size) of the image to display. The available imagecache presets can be seen here (http://randomland.net/admin/build/imagecache), for admin users. By default, it uses preset 'Thumbnail'.

For example, if you wanted to display the 1024x version, you would call it like this:
[rlimg xxx | 1024px_wide]

The module now displays "teaser" text as the caption.

Drupal's a poople and is caching that stuff, so if you edit a description and it doesn't seem to be updating, go to Admin>Performance and click "clear caches."

One final note: when you save a node with no teaser text, it tries to auto-generate it from the node's body text. If you wish it to be blank, throw a blank <p></p> in there (or similar). All HTML is parsed out at runtime. It's a hack, but it'll work until I make an admin page.

Thats cooler then a barrel of cucumbers in mid October! Now I just need to write some articles so I can put it to use.

Yeah, you should! (And pickles are good!)

So, my next step is to make that canvas thing so you can lay out a grid on images. If you look at the Tentin' (http://randomland.net/rec/camping/tentin-2009) post, you'll notice that they wrap to the next line, when needed. How would you, as someone who uses it, want it to work? Wrap always? Wrap by default? Never wrap? We could do things like setting the number of columns.

Also, what should it be called? Like rlimg-block or something? And have it so you just throw your images in it? Like:
[rlimg-block]
    [rlimg xxx][rlimg xxx][rlimg xxx][rlimg xxx][rlimg xxx][rlimg xxx]
[/rlimg-block]

Respond if you care.

Wow. I more then slightly like it. I think wrap by default is the way to go, with the option to set a min/max width. Also there in a weird thing where the grid of pics jumps over from a lefty looking align out toward the middle of the page. Might be something to do with a <p> but I am not sure. It the bottom block on the tentin' post. You might not see it without some crazy desktop resolution like what I am punishing my eyes with.

I worked on the module quite a bit tonight. You can see the final result here (http://randomland.net/rec/camping/tentin-2009). Just look for the grids on images towards the middle and bottom of the page.

I have implemented some very rudimentary [rlimg-block] code, with a snoozingly boring style. I broke up the code into separate files and commented it pretty heavily. I have pushed all HTML styling into three template files: rlimg_single.tpl.php, block_open.tpl.php, and block_close.tpl.php. CSS is still defined under css/rlimg.css. Edit them as you wish (all ye who have legitimate server access).

Straight from the article body, this is the code:
[rlimg-block][rlimg 451][rlimg 464][rlimg 456][rlimg 472][rlimg 471][rlimg 495][/rlimg-block]

Here are some improvements that immediately come to mind. Please, toss out your own if you have any.

• Reduce padding between images. This will probably involve defining a separate template file for images contained within rlimg-block tags.
• Reduce head-room padding. Why is this here? The rlimgs still have way too much bottom padding, too.
• Fix styling to be less 'blahhhh'
• Add content alignment parameter. I kind of like it defaulting to left-aligned, but if you only had 2 or 3 images, you might want to center-align them. Syntax something like [rlimg-block contentalign=center]?
• Add width parameter. I suppose this could be up to the page designer, making the implement it with a style="width: 500px;" or something...what do you think? Would syntax like [rlimgblock width=500] be of
  benefit?
• Add block alignment parameter. Meaning that you specify how it would align on the page. This is optional, but I think I would use it. You could have options like center, left, and right. I almost always want it centered, with the content left-aligned, but maybe that's just me.

Ok, that's enough out of me. Respond if you feel so inclined. And, for all of you with admin rights, I've set up a "sandbox" page here, at node 1267 (http://randomland.net/node/1267). Please, feel free to try it out so you can tell me what it needs.

I like, I like. I will definitely be using this in the future. And for whatever reason I am really fond of the rounded corners on the 'cells' of the grid (the borders of the images.)  Now we just need to decide on some colors. 

For the exterior border, I used the -moz-border-radius. Consequently, they're just square in IE. The inside uses four very small PNGs to round it out. I could easily use the image-corner method for the exterior of the border if it is worth the effort.

I am trying to decide what would make the background of [rlmg-block] look better. Rounded corners? Gradient edges?



EDIT: I just thought of another potential feature -- adding descriptive text to the rlimg-block. That way you could write have a little blurb about your group of pictures. Maybe looking like

-----------------------------------------------|
|  ------  ------  ------  ------              |
|  |img1|  |img2|  |img3|  |img4|              |
|  ------  ------  ------  ------              |
|                                              |
| With much undue direction from Justin,       |
| Brad backs over Francine's fenders,          |
| rendering them mangled and unsalvageable.    |
-----------------------------------------------|


Would this be worth implementing?

It would be worth it if there was no way to do it otherwise. It may look better to have the text in the block with the images rather then underneath it all. We/you might maybe experiment with HTML 5 for creating the background and corners for blocks.... Just an idea. I am actually not familiar enough with it to know if that would be something it could do or not (the rounded corners that is. I know it can do backgrounds of all sorts.)

I fixed up the code so that [rlimg] calls embedded within an [rlimg-block] get routed through a different template file. Right now, the only real distinction is that the [hh]rlimg[/font]s are floated so that they look right in IE and have a little less padding between them. But you could change them to look entirely different, because they are now separate code/templates.

Tentin' (http://randomland.net/rec/camping/tentin-2009) is still a good place to look at the rlimg calls working in harmony...except I just noticed that the YouTube videos are not displaying in IE for some reason...grrr.

What's next? Alignment properties?

What's with the dark gray bars on the bottom of images?

Style gone bad. Feel free to change the template file, called rlimg-single.tpl.php (I think). Than is where the teaser text caption shows up, if available.

I like the teaser text... but its not always appropriate.  And if there is no text then it just looks weird. I might play with it just a little of its all right. Try to put the teaser text in a span so it will collapse if its empty. Plus.... maybe there should be an option to display the teaser or not.

What do you say, z-man?

Yes, those could be good changes. Feel free to make any changes you want. I agree that the little semi-transparent bar looks out of place without text in it.

As for the teaser text, I was wanting to make it so you could pass it a text override parameter. Like [rlimg 1047 | teaser="Eighteen chickens in a Petrie dish"]

How many chickens can one fit in a petrie dish?

I agree with that. Custom teaser text relating more to the juxtaposition of the image is a good idea.

I don't know about the chickens, but adding the aforementioned funtionality has been in my mind since the beginning. Right now, the only working option is setting the imagecache preset (defaults to thumbnail, obviously).

Any official suggestions for (functional) features you'd like implemented? I might squeeze out some weekend hours and change it up a little bit. Right now, this is what we have:

Embed an image by calling rlimg and passing it the node ID.
[rlimg 1234]

Embed an image and display at something other than the default, thumbnail size. The parameter is the string value of the imagecache preset name.
[rlimg 1234|1024px_wide]

Embed a group of images within a poorly styled box. Right now, all images come in float: left and will wrap to the next line, when needed.
[rlimg-block]
    [rlimg 1234][rlimg 5678][rlimg 9012][rlimg 3456]
[/rlimg-block]

And that's about it. I'll all for changing the style up to be better, but I feel the code*.

So...don't be shy about changing the templates...I hacked that style together fairly quickly. There are only a few things I require:

• Shows image (duh)
• Has link to image node (currently the little 'i')
• Shows long description on hover (via title attribute), if supplied
• Shows short description below, if supplied
• Looks pretty much the same in all browsers

*motivation level subject to change at any moment

[chirp, chip...chirp, chip]

Ok, that's what I thought. I guess I'll work on the rlimg parameter implementation next. I figure the following would be useful:

• id="int" (implied if directly following rlimg tag)
  
• preset="string"
  Displays image at the size specified by the imagecache preset. This syntax should probably replace the original [rlimg xxx|presetstring] syntax.
  
• teaser="string"
  Overrides the teaser text. This text is shown below the image.
  
• description="string"
  Overrides the body (description) text. This text is shown on hover.
  

A sample call statement:
[rlimg 1234 preset="1024px_wide" teaser="You are such a teaser" description="Don't stop Mr. Ed from dancing in the hall"]

Looks good. How much of that is in there? And I think i might be able to help with that stuff. Unless I am underestimating the complexity of it all.

Cool cool!

All you can do now is set the image size (and display the image, of course).

So, like [rlimg 1234|preset_name]

Im planning to work on this a bit tomorrow. That, and taxes, cleaning up (finding) my desk, packing meat into the freezer, making chili, and enjoying the sun. Hmmm, busy, busy boredom.  :-\

Hows the chili?

Yeah, I actually finished my taxes (just need to mail the state money AGAIN). And the chili was highly tolerable. There's even a little left. Come get it while it's not moldy!

Oh, and I never got around to working on the rlimg module. I tried, I really did. But I kept falling asleep and not getting back up until the morning. :(

Falling asleep? I do that almost every day! If only I could avoid it. Just think of all the extra time I would have for being productive! I could not get around to doing twice as many things!

Anyway.  I would definitely be interested in trying your chili some time. 

Name a time! Maybe next time we go camping, I'll stew some up during the week before. I cooked this stuff both Saturday and Sunday (in the crock pot). Cooking it longer certainly didn't hurt.

More on topic, I worked on the module a little bit, as can be seen on the test site (http://test.randomland.net/node/210). You can now (w/in-development version) specify the caption, linktitle, and more via XML-style attributes. For example, all of these are valid:

[rlimg 454]
[rlimg  id="454"   ]
[rlimg id="454" linktitle="That's one huge bear!!"]
[rlimg 454 LinkTITLe="Fishing with razor claws is the way to go!" __ignored_attribute="Betch'll ne'er see this!"]
[rlimg 454 preset="800px_wide" alttext="Stream slasher"]


The only loss of functionality is that you used to be able to specify the ImageCache preset using a [rlimg xxx|preset_name] syntax. This was only ever used in about three places, so I figured I'd just go fix them manually when I roll this thing to the live server. (That, and I didn't want to make the regular expression any more complicated.)

The attribute names available are: preset, relpath, fullpath, linktitle, caption, alttext, and gallerylink. And I don't like the name of a single one of them, so please, help me by giving some input on what you think they should be called. :)

Also, the code is now under source control at https://randomland.net/repos/randomland/modules/rlimg (https://randomland.net/repos/randomland/modules/rlimg).

Mmhmm. A resounding "no comment." Ok.

I was just thinking, maybe I'll add "float" and/or "class" attributes. Then just call it like:
    [rlimg 1234 class="teaser_img" float="right"]

It'd beat wrapping the thing in a div every time you want to apply rudimentary styling. But perhaps that's just me.

Those are now implemented. You can see an example of the attributes in action here (http://test.randomland.net/node/210). I split each example on to a separate page, because it's less confusing. There are 8.

I think it'll be useful, especially with the alignment property because you can just throw a [rlimg 1234 align="right"] in the middle or your paragraph. It's all on that sample page, too. Let me know what you think.

EDIT: code now committed to the repository at https://randomland.net/repos/randomland/modules/rlimg/

Dude. That's at least 1.63 times cooler then me. I like it! I will defiantly use it.

Haha, um that's a good thing! What other parameters would be useful?

We currently have (in no particular order):

• preset - sets the imagecache preset. Defaults to "Thumbnail"
• align - alignment values available are [float] left, [float] right, and center
• class - a CSS class to apply to the top level of the image block
• relpath - the relative path to the image (excluding the randomland.net/ This is only used to tell thickbox what to display.
• fullpath - full path (including the randomland.net/) to the image
• linktitle - the hover title on the image (of course, Internet Explorer implements ALT tags wrong, so they'll never show in IE..!)
• caption - the text shown in the annoyingly semitransparent bar at the bottom of the image (subject to styling change: yes!)
• alttext - should probably be called simply "alt" and is just the ALT text on the img node.

And yes, I'd like to change the variable names. Let me know if you have any naming suggestions before it's too late!

Right now, the thickbox is not allowing for navigation between images in posts when using this module. Does anyone have any idea why that might be? You're supposed to be able to go the prev/next images within that thickbox popup, right?

I have seen the lightbox one do that. I think they only bo back and forth with images on the page. So they may not be seeing the RLimage thing as an image. Or I could just know nothing about it all. Just a guess.

Yeah, that's what I was thinking, but it's just php code. Ulimately it's no different than if I had just made a bunch of img tags myself. Perhaps I have the syntax slightly off?

Look at the source of the image stream. I am fairly certain that it works on there. 

I've started the The Randomland Image Embedder (http://wiki.randomland.net/index.php/Randomland_Image_Embedder) wiki.

I saw that, and approve greatly!

Ok, not that anyone cares, but I've started porting the image embedder code over to Drupal 7. A few things need changed (like how the permissions function is defined) but it'll ultimately be better.

Does that mean you want to make an en-mass migration to the new-hatness of drupal 7? Albeit a slow migration at that.

I tip my hatness to the new Drupal 7 and think we should lead our flock thither. Migration is a slow process, almost by definition. But so far, I'd say everything about it is better. Pretty much everything we need is now core functionality. The admin pages are almost nice now (as opposed to barely tolerable, before). And while updating the module, I found out that they switched stuff around some (.module file, hook function definitions); definitely for the better.

Plus, it'll give us a good chance to remake certain thing that were done hastily...or in an uncoordinated manner, at least. Namely, the theme and gallery pages. I think I'd like to develop/refine a set of gallery pages and content types for our use. I could definitely use some input on this. I think I'll start another thread.

Alas, Randomland is nothing but a time-pit for the few of us. It and sees no real traffic or critical examination. So, all of these improvements are really just pet projects.

There is no better way to get more visitors then a smarter look and easier navigation. More, newer content would be a plus too. And perhaps some humorous videos and pieces.

Another thing is google seems to ignore the forums for the most part in search results. If you try really hard you can get it to bring up something, but you have to be real specific in your query. Its like it sees it as less relevant for whatever reason. Is it the URL? Does it hate forums? I don't think it does as I find useful forum posts all the time with google. And some of them have atrocious URLs. Perhaps it just wants a site map or something to make finding everything easier. The new SMF should have a sitemap easily enough. Then, we will just have to see what happens.   

The module has been ported over to work on the Drupal 7 framework. They actually made quite a few key changes to how the module system works. And I started putting stuff into classes...because object oriented is your friend.

It still has a few kinks to work out, including but not limited to the styling issues. I'll be working on it off and on this week, when I get the chance.

It can be seen on the test site (http://test.randomland.net).

Notice: Array to string conversion in RlimgProcessor->processAttribute()  (line 139 of /var/www/randomland-test/sites/all/modules/rlimg/rlimg_image_processor.php).

!!! Fun times.

Yeah. Boring story. Basically I'm not (yet) sure how to get the data out of that caption field. I set it as a "text" field, but it seems to be storing an empty array. I might just change it back to "longtext", though in my estimation, a caption ought to always be short; like 100 characters or less.

As broken as it seems, it's mostly functional. Before I didn't even have the proper functions implemented.

Ok, that little issue is mostly worked out now. I changed the widget to be "longtext with summary." Whatever's in the summay gets passed to the template as the $caption variable.

Styling is still extremely rough. I'll probably work on that tonight.

After that, I need to start defining functionality for [rlimg-block] tags. What would you like to see here? Block caption? Width/height attributes?

Both. And perhaps a 'css class' for defining how it should look. I should start remaking the gallery in new-drupal form. Perhaps even making a better one as most of the stuff I used before is now built-in to the core. 

Ok. I was thinking that the call (for both images and image blocks) should take an optional class parameter which gets applied.

So you'd go, give me an:
[rlimg 123 class="image-sensored" description="Pants have never been for eating"]

Similarly, something like:
[rlimg-block class="dev-screenshots"]...[/rlimg-block]

I'm going to post about the gallery setup in the Test Site Discussion (http://randomland.net/forums/index.php/topic,175.0.html) thread.

I fixed things up a little bit and committed it to the SVN. It at least does not spew warnings at you anymore. Styling is boring and the containing div sizes to the caption text instead of the image width. But still, it's better than before.

I updated my module demo page a bit, here (http://test.randomland.net/node/2).

The Drupal 7 version of the module is more or less finished, demo here (http://test.randomland.net/node/2). I've started updating the wiki page (http://wiki.randomland.net/index.php/Randomland_Image_Embedder), but it's real sloppy and out of date. But hey, what is wiki for?

Let me know what changes you think should be made...including, "Dude, just forget it and modify your ImageCache templates." I'd suggest looking at the demo page instead of the wiki for an accurate depiction of how to use it.

Since this code is worthless until (if?) we roll out Drupal 7, I'm going to start directing my attention towards other design matters in the Test Site Discussion (http://randomland.net/forums/index.php/topic,175.0.html).

Apparently it's been over 120 days since I worked on the Drupal module. I'm considering fixing it up so we can use it. The Node Gallery (http://drupal.org/project/node_gallery) project looks similar and very promising, but a Drupal 7 implementation is far off (http://drupal.org/node/650208#comment-3836048). Plus I just want to do a little late-night coding.

Any suggestions?

We should start setting up the test site in preperation for making it the live site. And then see what we still need going from there.

well, we do have Drupal 7 (release) running on the test site. I have a bunch of modules installed, but I tried to only install what we were might use.

As for the image thingy, I installed it on a local copy. To work, it needs:

• tag and collection taxonomies set up properly
• default field display modes tweaked
• optionally: some sort of url-based search result thing (like current "imagestream")

Should we try and migrate the database from the 6 install to the 7 install? That will give you all the taxonomy terms.

The module creates a separate taxonomy for both image tags and image collections. I fixed them last night. I guess it's not really necessary, but I like the idea of keeping them separate. When you search, you could search all taxonomies, or just the ones you want.

We need some sort of automatic thumb-nailing, the ability to assign images to taxonomy terms (galleries) and the ability to add tags to images.

None of this appears to be on the test site at the moment. I am not sure about your test environment though.

Edit:
And the theme needs a little work :)

Um....the Drupes automatically create the thumbnails. The module creates a content type which has the fields:

• title
• body
• image
• image-tag(s)
• image-collection(s)

So all that functionality should be there. The default display modes are all messed up though (they always display full size). But aside from the [rlimg xxx] input filter, it doesn't do anything you couldn't recreate in the UI in about 2 minutes. In the future, I'm hoping to give it some decent search and display functionality.

I committed a fix on the taxonomy thing last night. That code (https://randomland.net/repos/randomland/modules/rlcore) is now live at test.randomland.net (http://test.randomland.net). The other fixes mentioned below have not yet been updated there (got locked out of the SSH or something).

---

Updated list of things to implement/fix (in no particular order)

• FIXED 2011-01-21 broken taxonomy references
• FIXED 2011-01-22 default display size (who killed image_link_content__thumbnail?? Where is this field info stored???)
• discuss collections taxonomy widget. We want something where you can add on the fly, but avoid duplicates
• a search/display page
• Figure out how to display and use EXIF data
• FIXED 2011-01-22 integrate with PathAuto so that URLs get created something like author/YYYY/MM/title

I want to get Drupal to parse and store EXIF data. What fields should we store? Also, should this be stored in a new taxomony? Or would you consider these "image tags"?

They can just be part of the image node. The way it was done before is a module gobbled up all the exif stuff and put it in a table that was linked to the associated image node.



PHP can read all that information if you think we should try and make our own.

But...

• Camera model
• ISO
• Shutter speed
• GEO location (if any)
• Exposure compensation
• Focal length
• Shooting mode (Auto, program, manual)
• Macro?
• F-Stop
• Flash?

And anything else you can think of. I think all those should be standard, or should be easy to figure out based on the camera manufacturer information.

And, of course datetime taken. That seems like a good list.

The new version of the EXIF module has the ability to parse the data into text fields or taxonomy terms. I think the terms become something like exifiso400. Not perfect, but probably searchable. Definitely usable with a little scripted parsing logic.

Edit: I'm utilizing the wiki again so I can write downfor bugs/ideas down somewhere and not let them get buried 5 posts back. This thread is good for discussion. Feel free to editUse the wiki withfor semi-formal information.

http://wiki.randomland.net/index.php/Randomland_Image_Embedder#Open_Bugs_and_Issues

Edit 2: I use too many words.

Yo, yo. So, as Nick already knows, I got the EXIF parsing to work. The module now creates a field on the Image content type for each EXIF entry you want. Currently, the date, ISO, shutter speed, exposure bias, and f-number are stored. If you want to add more, you can tweak the rlcore_enable (http://randomland.net/repos/randomland/modules/rlcore/rlcore.install) function. I'm just lazy (and used the 30 seconds it would have taken to add the extra fields to write this here sentence).

You can play around with it on the test site (http://test.randomland.net/node/add/rlnode-image). The formatting will need work, but here (http://test.randomland.net/gallery/admin/2011/01/brad-woods)'s a picture I uploaded at random. The EXIF module throws errors which don't actually seem to hurt anything. Hopefully they fix it some day. If you're feeling beta-testerman, report errors here (http://wiki.randomland.net/index.php/Randomland_Image_Embedder#Open_Bugs_and_Issues).

The next step will be a search page. Something akin to the current imagestream (http://randomland.net/imagestream), but eventually more powerful.

I pretylty much fixed the input filter (though I forgot to commit it). I'll try and make it live on test (http://test.randomland.net) tonight.

Still, if the Media Gallery looks like a better option, let's move that way. Perhaps it's up to me to try it out.

So, I updated test (http://test.randomland.net) tonight but it somehow broke everything. So I disabled it :-\ I'm taking it no one has tried the Media Gallery plugin yet. Maybe I'll try tomorrow...

Haven't tested it yet, sorry. Been busy. But I am staying home sick today so I might have a look at it.

Sick? Man, youda illest! I mean, get well soon.

Ok, the test (http://test.randomland.net) site issue has been resolved. It is now running the most recent version of the module. I've uploaded and tagged a few pictures. Yeah, the UI still sucks, but you can get the idea of how it works by clicking on the tags listed below the image.

For example:

• woods (http://test.randomland.net/gallery/tag/woods)
• jacsveus (http://test.randomland.net/gallery/tag/jacsveus)
• camp-camp-2010 (http://test.randomland.net/gallery/camp-camp-2010) (collection)

Just tossing out there that Nick has been working with the Views module and is getting many workings done. If it's feasible, I'll try to automate the creation of this in the module code. Or at least make an admin page.

We almost have a working image system, I think. Cool.

Apparently this isn't where I've been posting updates about the ol' Drupal image module, but I'll do it anyway. This forum loves fragmented, wandering, meandering, unfocused, .....what was I saying?

Oh yeah: http://drupal.org/node/1236474/commits (http://drupal.org/node/1236474/commits)
I just committed a super-crap implementation of the old rlimg module which passes off work to the Media module....expect the implementation to change significantly. But what does work is the tried-and-boring [rlimg 1] where 1 is now the media id.

All this to say: if you want to test super-duper basic rlimg syntax with Views, you can now. It'll use thumbnail size. And it isn't configurable...yet.

Easiest way to get it on the server:

  [admin@randomland drupal]cd sites/all/modules
  [admin@randomland modules]git clone --branch master randomnets@git.drupal.org:sandbox/randomnets/1236474.git rlimg
  [admin@randomland modules]cd rlimg
 

Then get future updates with:

  [admin@randomland rlimg]git pull

Cool! I look forward to implementing this into the gallery!

I haven't quite figured out how it gets the image sizes. They might be hardcoded presets (they are not the names defined in Image Styles). Anyways, it's something. Any feature requests?

You don't just use print theme('image_style',$image); ?

What are you using for outputting images?

I have a suspicion (<-- why does that word look wrong) that I will revert to that. And drop the usage of Media Markup entirely. So long as I get the image path, using theme() is likely the better approach. And strikingly similar to the original implementation in rlcore.

Which brings me to another point from a conversation Nick and I had yesterday. The base image File type has no fields other than the image itself. We will need to add them. Adding them programmatically (in a module) seems like the "right" way to do this. Much of this was already done in the old rlcore code, just with Nodes instead of Files.

Should we break this up into a separate, dependent project? If so, what should we call it? It might be nice, at least for development...for issue tracking (http://drupal.org/project/issues/1236474), anyway.

Call the other one media-fields?

I vote making it all one module with the expressed intent to create a useable gallery and media categorization system from the media module. I guess it would be a competitor to the media-gallery. But hopefully a little more powerful.

But with that said, it would be nice to give people the option to have alternate fields used off of the media nodes. Giving them the option of naming them different or using a bunch of nodes that already exist.

A third thing is search. At the moment the taxonomy terms attached to media nodes do not show up under that taxonomy. So we will have to figure out what is missing from what and what needs hooked into. I know; that's vague.

Hmmm, grrrr, it appears that the downsized images are not being generated at the moment. Only the square thumbnail the Media modules uses (see Content -> Media tab).

Investigating...