This topic will be for any bugs or suggestions relating to the new image gallery (http://randomland.net/imagestream) we are implementing. It's a little rough around the edges and I'm sure we can come up with plenty of suggestions -- post them here.
I'll start it off.
I want to be able to make some semi-permanent links to image collections. These collections should be dynamically pulled based off of tags. For example, I might want to make a "francine" collection. The current system can do this via the imagestream view...except that I haven't added the Francine images yet.
Anyway, the problem I have is that I can not control the order of images in the collection. It might be nice to allow arranging them however I see fit (like the old system does), but really, all I want is a "order by date taken" option. Right now, they are displayed by date uploaded. This is not the most useful for collections.
Perhaps we can add another view and have it sort by date taken as the default?
Ok, so perhaps no one is going to respond to this either but:
I think we need to decide on a standard base url for all new-gallery stuff. I have been aliasing things as /gallery/zourtney/[whatever] for my stuff, kind of trumping the old gallery's url.
I like the looks of /gallery, it's a good one and would like the new stuff to use it. Are we ready to move the old gallery to a subservient looking url? Or should we do something different entirely?
I am all for moving the old gallery url to something more obscure. I don't want to get rid of it just yet as some things are using it.... those those things might be broken once the gallery url gets changed.
If you want to specify the order of images in a gallery then you will have to assign them all weights. Doing this by hand is a little silly so we will have to find (yet another) module to help with that.
Making them sorted by when they were taken should be easy as slapping poodles. We can make another gallery view and pass it parameters for what tags to show and how to order them. I make something real quick for that. Its raining and I have the flue so I don't have much else to do.
Sorry to hear that you, indeed are down with sickness. (oo-ah-ah-ah-ah)
Another, slightly modified view would be super awesome. I was thinking we make "collections" by creating a new node, slapping a little explanatory text and a view query into one page. We could (should?) then give it an alias like "gallery/francine" and everything would mesh ok, in my mind, at least.
I just have to find the 3 lines of code it takes to query a view again. It was simple, I'm pretty sure.
I am liking the new gallery styling. May I recommend a little padding around the edges? 5px is always snazzy. :)
We need "Rotate CC" and "Rotate CCW" buttons which save rotated versions of the uploaded image...
I looked into that before. I even install a module that added some image manipulation functions but did not add the rotate ability. I haven't yet found an addon that will allow for rotations easily. I guess I can look into the image-field stuff and see if there is an option for it to display an image rotated. Then we would just need to set the number of degrees to rotate.
Yeah, well...I can remove all my sideways pictures, edit them in photoshop, and upload them again, but that seems like unnecessary work considering we could write a PHP script to do it in very little time...It's just integrating it that I have no idea how to do. Maybe I'll look at modules again, I know someone has done this before...
Unrelated, but still important -- it would be nice to have a view which:
- pulls from all galleries
- has tag filtering
- possibly date filtering
- includes items marked 'exclude from imagestream'
...basically, an imagestream which ignores the 'exclude from imagestream' option.
I was trying to create a link so that I could show everyone pictures from the "Bike Tree" project. I excluded some from the image stream because they were boring AutoCAD screenshots. However, if you were coming from the bike tree's project page, I would expect to see those screenshots.
Also, I had the idea of a gallery content type which can be tied directly to another node. So I can make the "Francine Part 1" story and then have another node with some descriptive text and a wall of images relating to "Part 1." We probably already have the structure in place for that and what I wrote probably makes no sense. Ok bye.
For all the bike tree images... why not have a gallery that contains them all? Images can be in more then one. But I guess if you have already uploaded them all then it would be less work to just make another view (almost no work actually. I would just have to make another page on or clone the image stream view.)
Creating a gallery probably makes the most sense. We will almost certainly get gallery overload sooner than later, though. I guess I'm stuck in the "gallery is just a group of images with common tag(s)" mindset. Be that good or bad.
I was going to comment on something else, but it has evaded me. Oh well. It was quite unimportant.
I think its worth it to have the other page for sorting and displaying images. We could probably kill the galleries all together and just have pages with hidden sort/filtering options. But then I would have to change things a little. But also, you could then have images without forcing you to put them into a gallery. But if you didn't tag them the only way to find then would be to search by user. But thats more or less what the galleries are now.
Is it time to remove the extra 'random image' box? The one that is tied to the gallery 2 stuff.
Sure. It's a little redundant to have both, and I think the new one is here to stay.
On a related note, the pager on the random image block is a little weird.
What would you have it look like? Just the next back arrows?
When it says "1 of 749" or whatever, that it a little confusing. It kind of implies that the set has an intentional order, which it does not. And when does the order of that change? Having forward and back buttons, or event just a "random" button would suffice, in my opinion.
It changes every 10 minuets. I agree that its a little misleading but I liked that it showed you how many pictures were in the random pool. It needs some polishing. It would be easy for us to just hide the middle part. i might even be able to create a 'shuffle' button for it to return another random image.
Should we have another page for browsing the images one at a time? Should we reorder the random images more often? I liked having a little widget for thumbing through the images in an idle manner. But I also wanted to have random images so people would see a new one over there every so often without having to do anything. Was combining the two a mistake? Or is it just a confusing pager?
I like knowing how many are in the pool as well. A "shuffle" button would make sense. For what ever reason, I expect that batch to get shuffled up every time I load the page. This does not seem to be the case. What do you mean by "another page for browsing images one at a time"?
A dedicated page that would be like the imagestream, but only display one image at a time. Like a slide show.
The problem with randomizing the images on each page load is that it might mess up other people who are trying to flip through the random images. I will have to test it I guess and see how it acts.
Yeah, and that makes sense. But when you reload the page, you current index isn't stored -- you get thrown back to the first image. I ran in to that once or twice. I say that if you're going to keep them in the same order, it should remember where you were. Otherwise, make it dumb and simple.
I know of no way to keep the location while using the ajax thing. Without the ajax I think it throws the current position into the URL but the whole page reloads when you switch to the next image, and that's annoying.
So cool. You can have a separate stack of random images for each user. So reshuffling will only effect the shuffler.
So lose the forward back buttons and add a randomize one? I still kinda like having the navigation option. But perhaps a more elegant one.
I sometimes like the navigation too, like when I am flipping through and want to go back to one I blew past...Perhaps this functionality would be better on a dedicated page? I don't know...
Its less convenient on a dedicated page. The more convenient something is the more likely it is to get used. At the moment I took the pager off and set it to randomize on each page load (because I don't know how to add a button that refreshes just the image block. Well I know how, I just don't know how to do it with drupal stuff)
Well, should we pull the g2 random image block and switch randomland.net/gallery over to the newness? I think there are still a few images which have not been copied over to the newness, but nothing important. If we switch though, it'd be good to go through the whole site and forum and link stuff to new gallery images.
I think everyone has suggested that we do that. So yes, I do think its time.
Is there any good way to do a site-wide search for images still linked up through G2? I'd like to move stuff over to the Drupal nodes because I like it's nativeness. Though I do think we need to put more work into making albums/sets/collections/whateveryouwanttocallthems.
I guess that goes for the forum too. I mean, we can do searches, but I'm not sure the search will pull up stuff based on keywords of image URLs...
All good questions......
I removed the g2 block from the main site. The links still point to that gallery instead of our new one. How can we pretty up the landing page for the new gallery? I think that even the ability to have (and display) a gallery thumbnail would make that page 60% better. And a light sprinkling of CSS dust could make it highly tolerable! Is that possible?
I looked at the guts of the gallery thing and it is supposed to me showing thumbnails for the various galleries. But it is clearly not. I haven't found the problem. The best solution would be to get rid of the gallery module and just work with what we have made. Very little of it uses the module stuff any more. Just the list of galleries and the 'create new gallery' option. Or we could just make a new gallery display page. Though the gallery nodes are kinda strange. Oddly different from other nodes.
Sounds like another project. I don't think it'd be too hard, but a project nonetheless. I vote for working on section landing pages first -- like Motors, Rec, etc. If we get that looking good (like we were talking about in that other thread), we could make the gallery pages look similar. I guess what I'm saying is that everyone knows that gallery page is ugly, so we can put it off until we have a more defined look. :)
Ok. I can live with that.
I just had a sad, sad revelation: since moving the new gallery stuff to displaying with LightBox, you can't get a full size, downloadable copy of the image. Well, you probably can if you start guessing image URLs. But there is no link to get the full version. And if you right-click in the LightBox (or it is ThickBox? whatever), you don't get normalish options.
Am I just overlooking something?
There should be a link to get the full sized image on the bottom left of the popup. I will check it to make sure though.
EDIT:
I looked and the gallery pages have two option to see a larger image on the popup. The rlimg thing does not. I don't know if that's a difference from using thinkbox to lgihtbox/thinbox whatever (we should only have one installed :)) or what. It might just need some settings changed on rlimg call to the popup module.
Umm...where?
http://randomland.net/node/737
On the popup, I have the expando option, the close option, and the "view details" options (which incidentally takes you right back to the same page you're on).
You don't get the green "download original" link at the bottom left, taking you to http://randomland.net/sites/default/files/zourtney/images/Tentin%27%201277.jpg ?
No, no I'm not. Either the permissions are differing for our accounts, or I fail the "Where's Waldo" test.
Here's a screenshot of what I see. Click to go to image node.
(http://randomland.net/sites/default/files/imagecache/600px_wide/zourtney/images/tentin-troubles.jpg) (http://randomland.net/node/1141)
OK. Its a bug in the lightbox module. They are looking for permissions that are no longer part of the imagefield module, and as such not present. There is dev release with it fixed that we can install. In fact, I think I will do that.
Edit:
I installed the updated version. It appears I can now get that link while logged out. I hope this fixes it. Been a little too long since I banged around on the drupals.
So...I've been trying, off and on, for a long time to find a module which let's you rotate images uploaded as an Image node. So far, I haven't had much success.
I have uploaded quite a few pictures which are portrait orientation. Now, of course this information IS stored in the JPEG. But our system isn't smart enough to display it properly. And I haven't found any nice module which either a) rotates it and displays it properly on the fly or b) allows you to rotate the stored copy.
This seems so mindbogglingly basic. All I find is references to "write a PHP script which does X, Y, and Z." Come on Drupeople.
We could write one. I don't know how off hand but it cant be hard. Then we can make it into a module!
@#%#^%!
I don't think it is hard. So why aren't there 43 modules out there which implement this already??
Hmm, I've got this great idea! I think I'll call it a wheel... >:(
Just recording which pages need to have images updated...Edit/reply if you find more
http://randomland.net/zourtney/2009/10/wet-day-in-woods
http://randomland.net/motors/francine/part5
http://randomland.net/motors/francine/part6
All of the Tempo pages
http://randomland.net/rec/bumper-buddy/labor-day-2009-grinding
http://randomland.net/rec/stayton-lagrande-roadtrip
http://randomland.net/rec/weekend-adventure
lightsaber pictures have been missing for a long time...
http://randomland.net/tech/firefox-ms-addons-risky
http://randomland.net/tech/iphone-mms-finally
http://randomland.net/tech/picture-project/pacs
http://randomland.net/tech/picture-project
http://randomland.net/tech/custom-monodev-theme
http://randomland.net/nick/harbor-freight-fire-starter
http://randomland.net/nick/turtle-turtle
Lot's of old stuff here in the forum
As promised:
We need to look in to editing the get parameters on the imagestream (http://randomland.net/imagestream). The [] brackets in the URL (when you filter by tag) do not parse properly on systems looking for bbcode. This forum is, of course running bbcode. Also, I believe Drupal has a bbcode parser on one of two of the input modes we use.
For example...
http://randomland.net/ImageStream?keys=&tid[]=810
I'd like to continue tweaking the imagestream (http://randomland.net/imagestream) to be more friendly and return more accurate results. This would probably be a good place to start.
Yes and ok. Everything needs work still and probably always will. But that ok. Its all kinda interesting if not fun to play with. Improving the image stream is up there on my list with new front page banner.
I was going to maybe play with the views sometime...see if I can figure out how those are working. Let me know if there's anything I can help with.
Help away. I/we can even update the test site to reflect updates to the main site so we can ply with ideas.
A slight oversight on my part: we can't create dynamic galleries (ie imagestream (http://randomland.net/imagestream) with parameters) on images intentionally excluded from the imagestream (http://randomland.net/imagestream) using that cool little checkbox. This becomes a slight problem when I create computer tutorials with screenshots. I don't want those images showing up in the "random images" box, but I would like to dynamically query (ie "drupal tutorial screenshots").
Solution? Um, we could:
- create a view just like imagestream, but leave out that restriction
- make imagestream take a boolean flag indicating whether or not it should restrict
- forget I mentioned it
Adding a second flag would be easy enough. But then random images from articles would show up with camping and other pics. Making a universal searcher would be ok I guess. One that was just for URL based filtered, but could show any image node on the site.
Hmmm...when I think about it, it seems like the proper way to do it to just make one view (they are views, right?). On the page we're calling "imagestream," automatically select the proper option(s), and don't let the user change it. Then, we write another front-end for the "everything gallery." That option can be displayed as a checkbox.
I have no idea how the UI is set up right now, but I think it's weirdo auto-generated stuff, right? I don't see any reason why we can't write an HTML form and pipe our results through that view query. It's doing it somewhere already and shouldn't be terribly hard to duplicate. Maybe I'll look into this when I get a few free moments.
I found another image uploader thing. Seeing as our current solution has compatibility problems with my favorite browser (The Burning Fox - Also a good tavern name)
Anyway here it is: http://drupal.org/project/imgupload
Allows for resizing and rotating prior to uploading. Still it would be nice to display them rotated at load time based on the exif info.
Cool. I'll have to try it out. Even having the option prior to uploading in an improvement. I have some Shellberg Falls pictures to upload. Maybe I will can to that this weekend.
I just found that windows 7 has a hidden feature for setting an RSS feed as the source for a desktop slideshow. I propose that we create a randomland theme and a corresponding RSS feed comprised of our best (or least sucky :)) images available.
Excellent idea!
Did we ever get the image uploader fixed up? I have so many Shellberg Falls images to upload! And so should you.
Not that I know of. Just use IE or Chrome or Opera.
Oh, ok. I forgot that it was a Firefox related issue.
I installed Opera on my work computer (for compatibility testing). It's a strange browser, but it's snappy. But so is Chrome, for that matter.
Um, the "Gallery" link doesn't show up on the main site unless you're logged in. And if you go to it (randomland.net/galleries) when you're not loggged in, you get "access denied".
We should probably fix that.
Probably. I thought permissions were set so anonymous people could see it but I guess not.
Brad's comment in another thread got me thinking...just thinking. Perhaps we could build a gallery page which aggregates Randomland user photos and Flickr photos. I think they have an API.
Not sure if somebody already mentioned this... but it would be really awesome if the image gallery could read the exif data and rotate the images properly. Either when displaying, or when uploading. That would be cool.
Yeah. If it hasn't been explicitly mentioned, it's at least known as "missing feature número uno." In my mind anyway.
I really wish there were a decent image gallery module. Actually, it boggles my mind that there is not. The Drupal community is huge but irritatingly unproductive. And I'm kind of tires of inventing wheels :-\
Perhaps there is some better way we can serve up our images. There must be some free "media server" software out there....?
So, last week Nick mentioned to me that he might know what to do with the image system (granted, it has been a week). Anyway, it sounds like we are shifting towards using the semi-official Media and Media Gallery modules and creating a few custom views and/or display pages.
I will update the rlimg module to work with it...somehow!
Sound like the plan?
I think so. I looked at the RLimg medule... but I am not sure how to make it work with drupal 7. It seems some of the stuff you were using before (token) are built into the core. And there is not a single function for doing text replacement. I spend a while confused and then gave up. Perhaps you can fill me in on what parts do what and where to be looking.
Really the only part you should care about is rlcore.filter.*. The other files were for setting up the nodes and taxonomies.
The filter stupidly delegates text processing to the class defined in rlcore.filter.processor.inc. I say "stupidly" because no other Drupal code is structured in this pseudo-object-oriented manner. parseParams()'s call to node_load() and the few lines in processAttributes() are about the only things of interest. We just need to change how those nodes are loaded (I hope). And I can mess with this. Probably this weekend or on a lunch break.
What's the bare-minimum I need to set up what you've got going? Just Drupal 7.4 with the the Media module?
They are up to 7.7 now!
Yeah, that should about do it. Also views if you want to test it with those. I can give you the XML or whatever files for recreating my views.
The login is admin and you already know the password for the test site if you want to investigate anything.
Seven seven?? I'm calling 2011 the "year of inflated product revision numbers." I mean I already have Firefox 6b...when did 4 come out?...April??
Anyway, I'll play with that soon (probably start with a local copy). I'll test with Views later, unless you see a reason to add that complexity now.
No need to add views at the start. Buts that's how I will ultimately use it.
Regarding version numbers: I know! Its getting crazy. Firefox had like 400 versions of 3 and then 4 come out with big fan fair just to get stomped by 5 in what seemed like a few weeks later. And drupal seems to just be skipping revision arbitrarily.
7.7 was released (wow) yesterday. I'm guessing the second 7 refers to this month, July. Which I totally disagree with. Major and minor revisions should be feature-based milestones, not some release date ordinal! If you want to do that, make it a minor-minor revision, like 7.1.110728. Of course I could be wrong, just an observation/rant. It's like the world of software development went into a @$)"-measuring contest with Chrome's absurd release schedule and numbering scheme (v1.0 to 13.x beta in under 3 years)
Aaaaaanyway, I will download version 7.7.illegitimate and start playing. I think it'll be a fairy quick fix.
On a related note, where do we want to store the source? I've been using our SVN, but opened a GitHub account this week (under "zourtney"). It's nice. Drupal has also moved to a git-based system (away from their hated, ancient CVS). If we commit to that system, we should show up in their module lists and stuff, which is probably good. The only reason I haven't done this is because the code was too broken to be public (in my opinion).
Update: So, I got everything set up locally like test (http://test.randomland.net) except Colorbox previews. Any tips?
Yes! You have to go into the colorbox configuration and turn on the inline options. Otherwise it will look like its trying but wont actually display an image.
Here are two ways to make colorbox links that I know of.
<a class="colorbox-load init-colorbox-load-processed-processed cboxElement" href="http://test.randomland.net/drupal/sites/default/files/P6280047.JPG">Linksers</a>
and
<a rel="" class="colorbox-inline init-colorbox-inline-processed-processed cboxElement" href="/drupal/?width=600px&height=400px&title=&inline=true#colorbox-inline-2">http://test.randomland.net/drupal/sites/default/files/P6280047.JPG</a>
I am not 100% sure how the second one finds the image. I guess because the path is the link text.
Both of these can be seen at Views test-gallery (http://test.randomland.net/drupal/img)
So...we can do 90% of what we want with Colorbox and the overly verbose Media Markup (http://drupal.org/node/1138142) found in Config->Text Formats.
Sample:
[[{"type":"media", "view_mode":"media_large", "fid":"3", "attributes":{"class":"media-image"}}]]
I propose we utilize this, keeping the simplified rlimg syntax as a wrapper along with the template files. Easy cheese.
Ok! So whats the missing 10%?
What will the rlimg syntax look like with this?
Hmm, missing 10% is the "short descriptions" I liked having. Because it seems useful to have a one-line teaser text and a full description. I guess we can use titles? I don't know.
Syntax can stay the same, so long as we run our filter after the Media Markup one. Any change suggestions?
We could add a field for optional short descriptions. Other then that I think it sounds good.
We now have a sandbox project (http://drupal.org/project/1236474/git-instructions) on drupal.org. I will be committing all rlimg code here (once I get started on it). It's empty right now, but not for long.
You can grab a copy of the master branch with:
git clone --branch master randomnets@git.drupal.org:sandbox/randomnets/1236474.git rlimg
Awesome!
http://test.randomland.net/drupal/img
Minor update to the status of the imaging system. I looked up how to work the "image style" system in drupal 7 and used it in the theme for the gallery view to produce some rough thumbnails. Next will be to change how the formatting is done to get the grid items close together.
There are also ways to specify the display format of File (module) types. I think it's overly generic, but I could be wrong. All I know is that they exist. Might be worth looking into...
Show the documentation and I will play with it!
I only skimmed it, but this is what I was referring to:
http://drupal.org/node/1242904
Sounds like it might be a generalized version of what we'd have to do.
That's for video. I think we will be ok using the built-in function for the images. All you need is the uri for the file, and those are easy to come by using views or the whole file path.
What we might need is a way to use the media ID to get the uri though.
Also, they just started a new branch of the media module. They are using a 'file entity' sister module now. Not sure what this will change. Probably just have to use a different function to get at the uri and field values.
Whatever is going on in Configuration -> File Types, I don't understand....
Configuration -> Media -> File Types ?
A poorly designed interface for changing how the files are displayed in various contexts (mostly for use when putting files into posts using the wyswyg editor.) And for adding fields to the file types like any other content type. Its confusing. I think there is a way to use those view modes in custom places (php code) but I don't know what does that.
I deleted most of the different view types and mostly got it to use the default.
I have found that $file = file_load($fid); will fetch a file entity (or file node. I an not sure what to call them) with all its goodness and fields in an object. Then with $image = array(
'style_name' => 'thumbnail',
'path' => $file->uri,
'width' => '',
'height' => '',
'alt' => "Poots",
'title' => "Pots",
);
print theme('image_style',$image);
You can make a thumbnail. Or any other size image based on a preset.
Ok cool. That is the standard method for invoking a theme template. I used that in the old rlcore code. Should we create our own version of that image template which overrides this? That makes more sense than what I was doing -- wrapping/recreating such a template.
That still doesn't take care of the I input filter, but yeah.
Either way. I have no idea how to override/add to the template. I suppose it wouldn't be too hard, just implement some hooks or something in a module. But these are things I am still trying to lean.
I think I will make a temporary gallery setup with views, just using some php and template files. I am hoping at least some of the effort there will be of use with the RL module. Most of the php could eventually be replaced with a simple call to the RLimg module. And then the markup for the layout might be a starting point for a view that the module could create.
Yep, that sounds good. Sorry I haven't gotten much done on that input filter part. Maybe I'll find some time within the next few days. It won't take long...I'm just busy procrastinating.
Out of Drupal-induced anguish, I tried installing Wordpress again. I slapped on a few plugins. Puzzled, I soon said, "um, wow, this kinda actually works."
I got a basic, taggable image system in place. You do BBCode-style text to display images by tag (Wordpress calls this "shortcode" syntax). You can use the admin pages to search and image names, tags, and body text.
Perhaps I've lowered my standards a bit, but this beats what we have no on both D6 and D7. Strangely, the part Nick has been working on in D7 is the part I haven't yet found a good, standalone module for -- a user-facing search/display page. But honestly, if we are to write* module code, I'd rather do it for Wordpress. The other obvious missing piece is a single-image embedment syntax (ala rlimg). Both of these exist in some for or another in other plugins, though may be incompatible. But we can dig/code more if we trait-upon das Dries (http://buytaert.net).
true story: as I was writing that sentence, my phone autocorrected "towrite" to "torture". Coincidence? I think not.
Edit: oh yeah, test.randomland.net/wp (http://test.randomland.net/wp)