Randomland - The Forum

I installed the latest version of the drupler on  the test site (http://test.randomland.net/) Have a look. Its the latest and greatest drupal 7 alpha.

Seems I will have to remake the theme from (nearly) scratch. If you have any design ideas, requests or suggestions then let me know. Or put them in yourself :)

---

Updated by zourtney

The following is meant to be kept as a running list of TODO items for the Randomland test site. If it seems like something we should actually do, add it in here. To discuss ideas (or if somehow you're on this forum, have valid input, and are not an admin), just post a reply on the last page of this thread.

Theme
We will need to create a new theme, because Drupal 7 is quite different. I would like to see a more simplified and unified theme (the one right now feels a little mish-mash, to me). I would also really like a mobile-friendly version.

Calendar
One of the things I'm missing is the calendar functionality we have right now in Drupal 6. I downloaded the dev version today (10-28-2010) but have not had a chance to play with it. Sure, it's dorky, but I like the calendar thing.

For the wish list: if we could get a Randomland calendar that'll sync with mail accounts (ie, on my phone), that'd be sweet

Trim down arbitrary sections
I know, I know. I pushed and I pushed for segregated sections on Randomland. But I take it all back; a few simple tags and a decent site layout would fix all of that. So let's trash the pseudo-sections, tag posts appropriately, and just make the top nav links view a specialized landing page with a list of posts with that tag.

Image system
We need to decide what we want here. I still like uploading pictures to Randomland. It is a good thing. I am still willing to work on the image module, but I want to avoid reinventing the proverbial wheel. I'm open to opinions. I do like image as nodes, the "ImageStream", and the idea of a way to add images to posts without referring to their filename on the server.

Wiki, forums, and nodes
What goes where and why do we need it? As good of an idea as the Wiki is, it just fragments the site worse. Right now, I find the forum to be the best part of the site (probably because it actually gets used). How can we merge these 3 CMSes into something usable? (If you've never been, you might want to check out Stackoverflow.com...they have a huge user base and incorporate all of these ideas into a pretty usable site). Is the Drupal-based forum worth looking into again?

Web 2.old
We should at least try to add some elements of websites which have emerged within, say the past decade or so. Gravatar, OpenID, Digg, Facebook crap, AJAXy interface, usable node comment systems, etc.

Cool, yo. We should make a better theme anyway. I'm up for that. It needs to be done anyway.

What all has changed? Are views and bunches of other stuff included with the download now?

Did you lose my module code? Is was in the base modules directory. If you did, don't worry, because everything got checked in to the SVN.

I made a copy of the old test site folder so nothing is lost forever. All that is installed at the moment is the base drupal 7 and a ultra basic zen theme. They changed the way themes work a little so the current one is not compatable the way it is. I also installed the new version of SMF, but I have been having trouble getting it to import the older SMFs database. I didn't see a guide for importing all the drupal database stuff into the new drupal, but I am sure there is a way. It needs allot of work and looking at to see if its usable. Send me a message and I will set you up an admin account on the test site (that goes for Brad and Cody too.)

Ok, cool. I was thinking that I should make the base styling of that module tsupabland, and let user themes override it as they see fit. That's how theming is supposed to work and it'd help me learn how to do module style overriding properly.

I definitely think we should try to migrate to the new SMF. It seems to be where the development is happening. Then we can have necessary features, like blink text!!

I sent you a message about getting an account on the test site. It was obnoxious, I know.

I was thinking that it would be a good time to solidify a few:

• theme -- what do we want the theme to look like. I'd like something a little "cleaner" than the current system. A mobile/lo-res version is still enticing to me as well.
• input modes/filters -- like the seemingly misnamed "full HTML", or the fact that PHP input filter must be enabled for the rlimg thing to work (which seems bad)
• node types -- we seem to have ones we never use (on purpose). I am still fuzzy on post/page/blog entry terminology. Ultimately they're all the same thing and seems to just add confusion. For example, whatever type Cody used on his desk project post does not allow for comments. Why not just always have comments enabled by default?
• taxonomy --maybe we should revisit the taxonomy debate. Our sections are becoming less and less distinct. Also, many concepts are missed entirely (such as photography or food). Should we just migrate to a flat tag system?
• image system -- everyone will agree that it's still a bit rough around the edges (and apparently unusable by the likes of Brad and Cody). I'm willing to work on the presentation aspect of this if we can get some consensus on what we want.
• oh yeah -- why nobody makes posts to Randomland anymore. Or, perhaps better stated as, "Define the roles of the main, forum, and wiki site and what content shall be provided in each." Because, we now essentially have 3 full-fledged content management systems running concurrently. This is probably the most important thing to figure out, actually.
  
  

These are the issues I see that think could use some refinement. So, take your shot. Someone? Anyone? Please?

In response to Nick's comment (http://randomland.net/forums/index.php/topic,67.msg2538.html#msg2538) about redoing gallery stuff, I say, "go for it!"

I'm not much familiar with how this works, but it seems like we could:

• 1) Create a dedicated node type. Call it gallery or whatever.
• 2) Add a field of type list or list text. This would store image node IDs. It could also potentially store gallery node IDs.
• 3) Also add boring fields, like a title, description, etc.
• 4) Look into creating an image-selector widget. There might be something built in already.
• 5) Party.
• 6) Maybe update the image module to embed galleries as well. [rlimg-gallery xxx] or something like that.

But, I don't know much. That's just what pops into my head. What are your[all's] thoughts?

You know more about the drupal guts then I do. I just smash modules together until things kinda work :) It will be fun trying to figure it all out though.

It seems that the official documentation is still a bit light, though it does exist. Sometimes I have to open up the core modules and start scrolling through foundational modules, like image or field. But it's kind of fun. And I would be utterly stuck if it were not open source.

It's fun, you should try it.  :)

With the Drupal 7 version of rlimg and rlimg-block stuff mostly working (http://randomland.net/forums/index.php/topic,67.msg2655.html#msg2655), I need a new project. Should we slide on over to setting up the gallery taxonomy? Or perhaps an write uploader? Or a UI for tagging stuff?

Or, drop the image stuff (for now) and concentrate on theming? Or data migration? Or...concentrate on writing something worth reading?

Suggestions? Have I overused the question mark? Should I end this post off with a question?^{1 (http://www.azlyrics.com/lyrics/relientk/mywayorthehighway.html)}

No, you defiantly should now end your post with a question. Statements are so much cooler.


I think we should work on making an actual gallery for the site. And all that that entails.  If we do a good one it might even get used by other people!

Themeing should be easyish once I figure out how to convert the existing stuff over. I hope.

Ok. Sounds good. Shall we make a "gallery" content type? It seems like the right approach, but what do I know?

Sounds goodish. Perhaps even a 'collection' type to hold galleries.

I think it'd be best not differentiate between the two. Just have collections whose contents can contain single images or collections. Now I need a diagram.

Self referencing containers! I will put this box in a box in a box that also happens to be in a box! Oh my!
The only reason I suggest the container idea is to make displaying things differently easier. You want a couple of thumbs to represent a gallery and just a thumb of the image to represent an image. But in reality they are simply both just lists of nodes. So it could probably be done with only one list-container type. Having two would be for usability (logically having a collection/list of galleries make sense to me just like a gallery is a collection/list of single images)

But just doing a 'gallery search' with parameters would do fine for creating what I have in mind. Then we would only need gallery nodes and image nodes and a page that can search either/or.   

I started making a diagram, but figured it'd be half as much work to just do it (since it's on a test site, anyway). So, I did make the content type (http://test.randomland.net/node/2#overlay=admin/structure/types), but list is the wrong way to store node references.

It seems like the best way to do it is to make a custom field (http://api.drupal.org/api/group/field/7). As long as we're building modules and stuff, we might as well do it right. Besides, it sounds kinda "fun." I'll take this on if no one else feels like it -- or has a better suggestion.

Warning: I'm slow.

I'd like to help with it. Might move it along faster too. I will have a look at the test site and see if I can figure out what your trying to describe. I need to know more about the basics of making new content types (beyond the GUI thing) and displaying them. I thought it would all be easy but there is no views module for drupal 7.

Yeah, any help is good help! I'm not exactly sure what happened to the concept of "views" in Drupal 7. But I'm no convinced we need it. We're going to need a custom(ish) search component smart enough to sift through image and collections, heeding tag, filename, caption, and EXIF information. I just wonder if it'd be easier to write the search loop ourselves and forget the complexity of the views?

I've started an image system overview document (temporarily in Google Docs). I'll slip it over to the wiki in a while.

Well, my documentation efforts sputtered because making crappy music is so much more fun! And I was looking into Drupal's Field API (http://http:/api.drupal.org/api/group/field/7). I was attempting to make "widget" which would allow you to select from existing image nodes...or at least enter them in some way other than a text box with no verification that the nodes exist.

Anyway, what should we focus on?

Focus on? Other then making crappy music!? :)

We should focus on actually making a page that could be considered a gallery. Paged, grids of scaled images as links. That would be a gallery at its basics. After that we could expand on it and actually make it cool/usable (those two things don't always go hand in hand.)

What do you think?   

I'm being constantly reminded of my Drupal ignorance. For example, I learned today how to make a module create its own content types. I'm playing with this. It makes more sense to have the image module(s) control the existence of the content types. I think I want to break this stuff into a couple modules.

Ok. I am more ignorant then you about such things. What would the different modules be responsible for doing?

Sorry, I meant to explain that, but I was typing on a phone. And at work. I'm setting up Drupal on my desktop so I can edit the code more quickly (VPN is nice, but impractically slow). So....let's see.

The following areas I know could be implemented (and should, given my current knowledge). Can you help me organize them? I know there is more, but this is what I can think of...

• Image content type (hook_node_info)
• Collection content type (hook_node_info)
• Image/collection node selector widget (field API)
• Result widget -- shows grid of images. We might want to put sorting controls and stuff on here eventually?
• Search (there seem to be specific hook functions existing)
• Search widget, perhaps (field API, again)
• Image embedder input filter (rlimg and rlimg-block)
• Perhaps a collection embedder input filter (rlimg-collection or something?)

For those (Nick?) looking for something specific to learn and implement, we will need to define some pages for our image system. I don't know what they should even be yet, but it looks like hook_menu (http://api.drupal.org/api/function/hook_menu/7) and related API will get us on our way. If I understand it properly, most core modules use this hook. You can define admin pages or any publicly accessible page. It sounds like our "imagestream" view should be generated using this.

I'm hoping to create a pure programmatic implementation of this image system rather than a UI-built mash. I finally got the content type creation (http://randomland.net/repos/randomland/modules/rlcore/) down. Next, I'm going to work on creating a custom "image selector" field which lets you select from a list of existing Image nodes. Unless someone else wants to...

EDIT: nevermind, I have a long way to go before I can actually save and load from those content types :(

I upgraded the test site. It's now running Drupal 7 alpha 5. For some reason, the rlimg module is not loading its CSS file(s) though. It's maddening. Want to go insane? Try this:

• Visit the image module demo page (http://test.randomland.net/node/3) and notice how none of the image blocks have styling around them.
• Go in to the modules page (http://test.randomland.net/admin/modules), disable then re-enable Randomland Image Embedder.
• Reload the demo page (http://test.randomland.net/node/3). Image blocks should have styling around them because the @import url command got added to the page head.
• Reload the page (http://test.randomland.net/node/3) again. Image block styling is gone.

What the crap? It does NOT do this on my local copy. The entirety of the the randomland-test folder is owned by apache:apache with permissions 0775. I'm baffled.

But on the bright side, the Image and Image Collection content types are now generated programmatically by the RandomCore module. So setup is practically as easy as enabling the module.

WARNING: disabling the RandomCore module will probably delete and nodes of type Image or Image Collection. (This will be fixed later)

UPDATE: I was able to recreate the insanity. So that means my local copy working as expected is the exception...
UPDATER: fixed by implementing hook_init() and adding CSS in the proper spot.

Ok, design question time. This has been mentioned before, but I'm bringing it back up.

Q: Should image/collection tags be stored in a separate taxonomy?

I say "yes" as to make things like article specifc tag clouds not get cluttered up by unrelated taxonomy. From the programing standpoint, it doesn't look difficult to implement.

I say yes too. Only because, like you said, things would get cluttered.
Though many of the tags would overlap. And searches can exclude image/collection nodes. There are reasons to do it both ways. But with any search I am sure we can set it up to include/exclude any taxonomy we want. So as long as we can search both taxonomies at once (for a site-wide search) then I say yes. Otherwise it would be better to have a sub-taxonomy for image/collection nodes for searchability.  Logically both ways are about the same. But when editing/viewing the taxonomy lists there might be a difference. 

Ok, the Image and Image Collection content types now share a new vocabulary called Image Tags. It's not on the test site yet, but it is in the SVN.

I'm now learning about custom fields and formatters. I can probably slap up a demo tonight, though it'll be a bit rough. My thinking is that we can create a field type which allows the content author attach a list of image/collection nodes. This would be the primary storage device for an Image Collection.

Furthermore, we can easily define multiple formatters which could display the contents in different ways. A formatted grid layout would be the primary, preferred formatter.

So, I got a crappy working version of the module up on test.randomland.net (http://test.randomland.net). The SVN copy has all components merged into module, but the live one does not. It does the following:

• Defines a vocabulary Image Tags
• Defines an Image node which has a title, description, tags, and the image data
• Defines an Image Collection node which has a title, description, tags, and an Image Select List
• Defines an Image Select List field which allows you to select one or more Image nodes.
• Defines a filter which converts [rlimg xxx] into themed HTML which displays the image in node xxx.
• Defines a filter which converts [rlimg-block] into themed HTML.

Regarding boring stuff, like testing:

I found this page (http://drupal.org/simpletest) on Drupal's site which gives an overview of testing procedures. I mentioned to Nick a few days ago that I'd like to set up a few tests and dummy pages which demo the functionality of the module. It is complex enough now that it can get a bit confusing.

Right now, I'm working on fixing my Image Select field so that it saves associated Image node IDs as rows in an intermediate table, rather than serialized into a finite length varchar column.

Ping, ping. Are we all still considering moving to Drupal 7? I like what I've seen in the alpha versions I've installed.

Aside from image gallery stuff, what modules do we need to have the site functioning as it is now (in Drupal 6). Honestly, Randomland doesn't have much functionality..!

Nope. Other then the gallery and a few things I installed for the sidebar (the 'most read' articles ticker) I think we can get by with the core stuff for at least a while. Add stuff or make stuff as we see need for. I got all SVNed up yesterday with the intent of starting a little (hopefully) helpful work on it. But I got somewhat overwhelmed in my lack of drupal module knowledge. It will take me a little catching up before I will be of much help. And then I started reading about the '<canvas>' tag for the new HTML specification. But I have your source now! If you would, give me a little pointer on where to start. I was going to try and make the part you were talking about that will make a default test page when you install the module.

I could devote more time into porting over the theme. I am confident that I can stumble my way though that ok. Lots of the stuff is the same... lots of it not. Then after its ported and I am more familiar we can start making alternate themes.

Oh, so the source is totally broken at the moment. Sorry.

I've been spending my "free" time changing the code formatting to the Drupal standard (of as close as I care to make it comply). And I also added a ton of comments to the code. I'm going to post the phpDocs to randomland right now!

Ok, it's up at http://test.randomland.net/docs/rlcore. The formatting sucks; big time. But all the text is there. Honestly, it'll be better just to look through the code itself.

Here are a few highlights (most of which is explained in the inline docs)

• rlcore.module defines the template files, help text, and the two content types (Image and Image Collection nodes)
• rlcore.install contains database table information and what to do when the module is enabled or disabled. Basically, it controls installing and uninstalling the content types and fields.
• rlcore.field.inc defines the ImageSelect field/widget which is a multiselect HTML box filled with Image and Image Collection node references. By selecting them, you'll associate an Image with whatever node this field is attached to.
• rlcore.filter.inc is the old rlimg module. It takes the text [rlimg] or [rlimg-block] and formats it based on template files in the module directory. We can use Drupal themes to override this.

There's probably more, so feel free to ask. I'm still a bit confused over the whole field/widget thing and how to implement it properly.

I updated the module code a little bit. The image collection's multiselect field (unimaginatively dubbed "ImageSelect") now saves and deletes entries properly. This code can be seen in rlcore.field.processor.inc (http://randomland.net/repos/randomland/modules/rlcore/rlcore.field.processor.inc) and is called from rlcore.field.inc (http://randomland.net/repos/randomland/modules/rlcore/rlcore.field.inc).

It still has major issues; I would consider it unusable. Mostly because your previous selection is not highlighted when you go back to edit the field. I'll get to that next. But, if anyone's interested in seeing some simple field loading/saving guts, it's in there.

Sounds like progress. I am interested to see how all that works. I will do my best to take a look at some source tonight. It'll do me good.

The Drupal standard is surprisingly NOT object oriented. So it feels very C-like to me (which I don't really like). At any rate, feel free to bug me about it. I'll gladly explain the code in any form of (non violent) communication you can muster.

So....I have a UI design question I need to work out before I work on my Drupaler thing any more...that is, if anyone still finds it worthy of being created. If not, just let me know. There are plenty of another projects I can play with instead.

But, if I should continue to work on this, the question is:
How should the user select photos to add to a collection?

Drupal gives you the ability to dynamically add multiple instances of the current field. In the picture below, I created a dummy content type, added a single field of type "Decimal", then edited the "Number of Fields" to "unlimited." These fields are rearrangeable using the stock Drupal UI. No fancy needed.
I could use this same approach with a widget that lets you select a single image. And let the user add as many as they want, shuffle them around as they want, etc. But is this good enough for our purposes?

I was going to make a full-blown, complicated AJAXy widget which would let you do all this. But is there a need to? If you (anyone) has the time, try creating a dummy node that has some field with unlimited cardinality (I believe that's the terminology used in the code). If having multiple instances of a field which lets you select a single, existing image seems good enough, I'll go that route.

What say ye? (If I lost you, I'd gladly try to clarify.)

Whats this for? Uploading or adding to galleries? If its for uploading then it will work for small numbers of images. If its for creating galleries why not just use taxonomy to assign them to a gallery? Or is the point that you can sort the display order. If thats the only way to change then display order then OK. But it would be nice to be able to do both; Have images assigned to a gallery via a taxonomy term type tag, or to swap around the boxes. One might have to make a script that goes through and takes all the images with a gallery name tag and apply them to that gallery node.

Or am I missing the point?

Well, I suppose the purpose was twofold:
1) I'm not sure what we want
2) I don't know what I'm doing

That said, perhaps I was thinking about this backwards. I was trying to store image references in collection nodes. If we instead slap a "collections" taxonomy on Image nodes, we've simplified it greatly. Perhaps we don't even need an Image Collection content type?

My reason for wanting it a content type was so we could associate author, date, etc with the group of images. If this isn't wanted, then everything is simpler.

It might be better to associate an author node (or user profile) with the images. Then we could just have the field for telling the images what gallery they are in. I think it would still be nice to have a node (or fake node that's just a canned search) for displaying the associated images in a nice formatted manner.

What are your thoughts?

Actually, now that I think about it, I think my primary reasoning was that you would want to slap a description on the collection. Perhaps this is presumptuous. Of course, along with every node comes the author, date, and access-level data. Which may or may not be of any use on collections.

Or we could just use Flickr.

That's true... or we could use the flicker API to use the images/collection to drupal. But unless you have a paid flickr account, they impose all sorts of restrictions on you. Mostly about the amount you can upload. And I like the idea of us having our own little thing under our control.

I think we would want a description with collections. But I was thinking we could avoid the tediousness of adding images one by one. I don't know, as your doing (so far) all the work on it I think you should get to decide. I will just throw in my 42c.

If collection have images added to them then they are the masters of their own contents. Else images decide what collection(s) they belong to.
If images decide where they go you can assign a large number to a collection (or more then one collection) at a time (Like I want to add all these images to the collection 'nicks pics' and 'the beach' and 'summer 2012' all at once.
Or we could forget about collection as a node and just have an advanced search page that takes parameters. Then you just tag images and like-tagged images are all in the same collection.

You could still assign more information to the image either way. Like an author/owner to the image (beyond just who created the node. Have another Author node that has information about how who took it and if they do commercial work or something. ) And have some preset copyright license stings to add to image nodes so people know if they are available for free use or not.

There are (or were) things that would allow you to add descriptions to taxonomy terms. That could give you the description ability you were looking for. Just have to make a custom search page for displaying 'collection' terms that displays it with the images. Or below a thumbnail representing that collection.

Thoughts on that? Do I help, hinder or just confuse things more? Am I seeming to get what you are trying to say? I always worry that I am misunderstanding things.

No, your input is quite helpful. Obviously, I haven't really thought this through. And now that you mention it, I stumbled upon the fact that you can add fields to taxonomy terms. I thought this strange at the time, but perhaps this is exactly what we're looking for(!)

(An hour later...)

Ok. So I've set up a manually created demo (http://test.randomland.net/) of how it can work with that setup. I really didn't DO much:

• Created vocabulary called Image Tags (http://test.randomland.net/taxonomy/term/26#overlay=admin/structure/taxonomy/rlcore_tags/fields)
• Created vocabulary called Image Collections (http://test.randomland.net/taxonomy/term/26#overlay=admin/structure/taxonomy/image_collections/fields)
      Slapped a field rating on it, just to prove it can be done (it already has description)
• Created content type Image (http://test.randomland.net/taxonomy/term/26#overlay=admin/structure/types/manage/image/fields)
      Added image upload field
      Added image tag and image collection fields as taxonomy term references
  

The image nodes work like I want. It's easy to slap on whatever collection comes to mind (just like tagging). AND! Better yet: Drupal can display the list of taxonomy (http://test.randomland.net/taxonomy/term/26#) terms oh-so-simply.

So, I think you nailed it. Your Drupal knowledge is far superior! I was intentionally avoiding the taxonomy because I thought it was not powerful enough -- boy was I wrong. The ignorance was not so bliss.

What do you think of this implementation? What does it lack?

Wow, I think you give me way too much credit. But thanks.

If we can make a nice way to display the images in a collection I think that will work just fine. Thats where I ran into problems before as we were lacking the views module. No way to display the images as a formatted table or get the RLimage tag onto them. I know there is a way to do it, I just don't know what it is.

Ok. So, is that the basic setup of the current (6.x) setup? If that's all we're really looking for, plus a little formatting, I think we can do it..!

I'm still a proponent of creating these vocabularies, content types, and views programmatically. It allows us to quickly recreate the content schema, which is good for testing, site migration, etc. It's also redistributable -- as simple as it may be, we could probably still toss it up on Drupal's module section (http://drupal.org/project/modules). Plus, I've already started (and I'm interested in learning the Drupal APIs).

I believe I could make the module programmatically create what's on the test site pretty easily. I can, then, drop the idea of custom fields...at least for the time being. If we want a slick UI for selecting images, we can work on that later (perhaps it'd be better as a utility page than a content type field anyway?).

Thoughts? Opinions? Rebuttals?

Sounds good. And if we start simple like that we can expand on it later if it does not seem to be providing everything we need.

An action plan. Cool. Guess I'll get on it!

And I'll get to the encouragement :)

'Good job! Way to persist in face of extreme pessimism!"

Oops. I didn't realize I was that pessimistic.

Not you. The rest of the world. And it was a joke. And it was a quote from a game you likely have never played. Though you should play it. You would like it. Its a puzzle game. And its free now. And its Portal.

No wonder I missed it :)

Portal is free now? Jerks on Xbox live had it on "sale" for like $8. How rude, are those platform gamer stores!

Yup free. Just steam some up!

Nope, I was wrong. It was only for the portal 2 announcement that portal was free. Its back to $20 for a three year old game that used to just cost $30 in the orange box.

Just wait for another steam sale. It'll be back to $5 or free eventually.

Good news: I got the module doing what we manually created on the test site the other day. I did it my deleting a bunch of code. It's on the SVN. I'll try to make it live on the test server tomorrow.

Ok, the new, running image module is up on test (http://test.randomland.net). In typical Randomland fashion, "tomorrow" means ~2 weeks.

:)

Drupal poople. I heard from The Register that v7 should go in to public beta soon. Ik not sure what that means since they've been tossing out lots of beta versions, but yeah. We should totally work on Randomland in our "free" time.

Actually, making content is probably more worth while. Yet seemingly not so much fun. I guess we need things to write about...

Defiantly need more things to write about. Reviews and opinions and useless yet humorous  things.

Wish list for new site (just so I don't forget):

- New theme, probably something a little lighter
- Uh, content
- Image node support (using my module, if necessary)
- Tagged and browseable images (pretty-up / override taxonomy view pages)
- Gravatar support (show avatar for author and commenters, when applicable)
- Anonymous commenting with some anti-spammery

Oh. Also quite important:
- A decision on what content will be where (because, by now, most of it is on this forum)

So, I'm getting that "randomland needs sprucing up" urge. Should I waste hours and hours on Drupal 7 theming stuff? I might be up for it...

Its a slightly daunting task. And thats why I haven't done it yet. But I too have felt that I am neglecting the good ol' RL these days. It needs some love and some content. I would be up to assisting in a drupal 7ing of things.   

Ok, cool. Perhaps I can start playing with this in the evenings. Time to sevenize!

I'm going to try to work on the image module again. It currently creates an image content type with a few tag fields. It also defines the input filter to allow embedding an image in posts. That stuff needs a little cleaning. Once I'm done there, I'll work on display pages for tags and collections.

Somewhere there is a list if all the things I was thinking we need to do for the sevenization. Nick recently mentioned it in the "Forums is the Deads" thread so yeah...

The biggest thing I've been waiting on is the Date API. I looked it up, and while there is no official release yet, it is under active development (this one (http://drupal.org/node/70963/release?api_version%5B%5D=103) was released tomorrow!) Other than that, I'm kind of waiting to see what kind of gallery projects people are coming up with...surely someone smarter than I has already put more work into one much better than I have and come to better results (the internet serves up a mean slice of humble pie). Should we perhaps make a separate image sever (subdomain)?

Also, we will need to look into data migration...not that we have a whole lot, but yeah.

Are you talking about a whole separate imaging system? Like make out own API and create a replacement for flickr? 

I think we started that once :) It sounds like an interesting project, even if its kinda futile given all the other gallery systems out there. But it would be worth starting (what ever happened to brads game and the client we were going to make?) I kinda feel that building everything into drupal is kinda like having a Swiss army knife. Yeah it has a spoon, but an actual spoon is so much nicer. Or like me trying to use my phone as a camera/podcast&music/phone/web browser/email/day planner/messenger. It will do all that. But it is in no way a replacement for my pocket camera, an iPod (or other dedicated music squawker) or a decent browsing interface. But it makes phone calls rather well and keeps my contacts organized. I wont even go into its messaging...  >:(

What exactly were you thinking?

Curiosity seems to have struck at an opportune time, for once. Because it seems that D7 versions of Views, Date API, and Calendar have been updated very recently. I installed a bunch of modules (using my Swiss army knifephone, no less). You might want to check out this (http://test.randomland.net/admin/structure/views) or some of the other admin pages, if you get a chance. I think Drupal 7 is finally at the stage where enough modules have been ported over to make it (nearly) as useful as 6. Yay!

As for the image thing, I am only worried about losing all of our links again. It'd be nice to not have to re-upload and tag 3000+ images. But I'm not sure if we can do that  :-\ I was eluding to the idea of an img.randomland.net virtual host, or something along those lines...

That's cool, about the D7 maturity and all that.


What would be hosted on the img.randomland.net?

We probably shouldn't do that, I suppose. Because would guarantee every image has a bad link...but yeah.

But in the future it would guarantee that links would still be the same after a site upgrade.  I am sure there will be some way to migrate everything over from the old site to the new one. Even if we have to write a script to move all the images over.

Yeah, which I guess is what I was thinking. Not breaking everything for a 5th or 6th time does have a certain, strange appeal though. I dunno.

The Tempo stories are still missing their images  :'(

Edit: update the first post (http://randomland.net/forums/index.php/topic,175.msg2458.html#msg2458) with some to-do and to-discuss items.

Ok, not that anyone is real interested, but I came across a Drupal 7 module which seems to be essentially what I was attempting to create. There is a companion gallery module which looks to be decent as well. I saw mention of Flickr something-or-others too....and it is in active development! I think I'll try them out tonight, or some time very soon.

http://drupal.org/project/media
http://drupal.org/project/media_gallery

Cool.
Sounds useful. I would be interested to see it in action and play with it a little. See if we can get it all searchable like we seem to like.

Well, I tried it out yesterday, but I seem to have gotten an unstable version of one of the dependent modules. I want to try the new Drupal beta anyway, so I'll nuke the test installation some time soon and start over. Just FYI...

NUKE IT! It's the only way to be sure.

Quote from: Nick on Nov 03, 2010, 02:25 PM
NUKE IT! It's the only way to be sure.

Quite the byline..!

I sadly can't take credit for that. Its a quote from 'Aliens.' But that only makes it all the more fun to say.

http://en.wikiquote.org/wiki/Aliens#Dialogue
http://knowyourmeme.com/memes/nuke-it-from-orbit
http://nukeitfromorbit.com/

Perhaps why it seems so familiar. Still, I like it :)

Sooo......the test site was pretty screwed up for that module I installed. So the test site is now gone. Totally gone. If someone knows the mysql username and password, can you let me know? Apparently it's not what I thought it was  :-\ The "test" database will need to be dropped and re-added before we can install the new Drupal beta...

If you are working on new themes make some more mobile friendly ones.

I'm not currently, but that's a pretty high priority, when I get there. You're welcome to help, of course. Though I'm sure you'll be pretty busy for a while. But yeah, I will need opinions, at the very least.

The password for the test database should be store in the drupal config files. Unless they have been deleted already.

I know...I searched around in the settings files but did not find it. It's gone now. Apparently I don't even know the root password anymore...

It hasn't changed :) I am about to PM it to you, so check your forum mail.

I updated the test site (http://test.randomland.net) with the newest of Druplars. Unfortunately, the media gallery (http://drupal.org/project/media_gallery) module appears to not install properly :(

I installed the media gallery module on the test site. It seems to work decently, but there is a hitch -- images are not stored in Drupal nodes. This means that we would have to port every image over into the new gallery and fix EVERY reference.

I can think of a few tedious workarounds, but nothing fun sounding. So, I dredge the ancient question: what should we do with our images on Randomland?

We should create our own image server. Nothing that is tied to anything specific, but has an API for serving up images and list of images based on requests. This could then be interfaced with anything capable of sending a request in XML to the server and the server could reply with information about the image and with a link to or with the binary image.

Lots of work... its probably been done/being done... of limited usefulness seeing that there are so many things that fill this nitch already. Perhaps we should just find a canned solution and make a drupal interface for it (if it doesn't have one already.)

Dare I say Bam?

Hey, for the SMF 2.X beta stuff there is a plugin for automatically detecting mobile devices and pointing them to a mobile version of the site... there is even a theme to use/ base a new theme on.  I cant set it up at the moment. But I will try and play with it sometime soon.

http://test.randomland.net/forums

I kilt the test site last night. Lo siento.

That's ok. the forums are in another folder and just need a sym-link pointing to them from the test-site folder.

Cool. It doesn't work, but I like the idea.

It was working day before yesterday...

OK. Looks like the link got deleted at some point. That's why it wouldn't work. It should be good now.

http://test.randomland.net/forums/


The command is: ln -s /var/www/forums-test/ /var/www/randomland-test/forums
if it ever needs created again.

Yeah, that would be my fault, I'm sure. The test site now has Drupal 7 RC1 (and nothing else). What features do we want on the site? I can't remember if I made an official list or not...

A new relase of Drupal 7's release candidate is out. RC3. I think I'll update it tonight. And maybe slap together a list of modules we want.

Yay! Go for it. And then send me a link please!

I updated test.randomland.net (http://test.randomland.net) last night. The only user, as of now, is admin. It's just a blank installation at the moment.

I will be looking around for what modules we should install. If you have suggestions, please post them!

Last night, I added a few modules to the test site. I have a bunch more I want to test out, especially gallery-related stuff. I've added the Calendar module, because I always liked that thing.

Also, I enabled the Drupal forum module. Personally, I'm liking its layout. Check it out, if you wish. Make some boards, posts, replies, etc. I'm not crazy about the theme, but we ought to change that anyway. If anyone else likes it enough, I will look into importing the SMF database -- it can be done! My idea here is to de-segregate the forums.

Good news: Drupal 7 (http://drupal.org/project/drupal) is officially released today.

test (http://test.randomland.net) is running the release version of Drupal 7 as of last night. I installed a few modules just to see how well they'd work.

I made a google doc (https://docs.google.com/a/randomland.net/document/d/1QULWMwVLmkeAtbNvPkU1DlB18ToJHJxsmcdD96Uu164/edit?hl=en) listing what's installed and comments/notes. Let me know if you can't access it.

Dude, guys. Let's sevenize!

So apparently the Media and Media Gallery (http://drupal.org/projects/media_gallery) projects have had some recent updates. It might be worth looking at, though transferring everything over will be fairly painful.

I like the pain! Bring it on! Come-hither, frustration! I beckon to thee!

If they are good modules, it might be worth it. If not then we can stick with our own.

I guess we can write a script to handle the moving of the data. Or at least to create new nodes with the old data  using the new modules. Its possible to do that, right? Make a script that makes nodes?

Yes, we can make scripts to create nodes, but that won't do us any good. That module doesn't store them as nodes; it stores them as "entities" which are somehow different. I'm sure it could be done, but we would have to at least understand the architecture first (which isn't bad, just tougher).

Assuming we move that way, is there any desire to keep the shorthand rlimg syntax? I originally did that so there'd be a "buffer" between filepaths and stored content. We can drop it or adapt it. My efforts on the module were as much an exercise in learning Drupal as they were an attempt to provide useful enhancements. I won't cry (too much) if we move away from it.

So, I downloaded the most recent version of the Media Gallery (http://drupal/project/media_gallery) project but it is still dependent on modules which have no 7.x version posted. Last time I think I found the dev-7.x version after digging around the CVS repo or something. So, you can try and enable what's there if you can find the dependencies...

I lost steam on my image project because I don't know the right approach for making a custom search page (especially one which heavily favors taxonomy terms. It'll take some time (and motivation) to figure that out. If you have any ideas, let me know. What's there, however, works as intended.

We could use some sort of modified taxonomy searching tool like before, or we could make a more specialized page that shows lists of galleries (in a grid or list) AND had a search box someplace. 

What did we use before? I tried doing it with the new Views UI, but just got confused when I started adding taxonomy-term parameters. I suppose we could make a page that runs straight queries, but there is surely a better way. It probably involves the Search API. Maybe I'll dig through that Custom Search module and see what I can glean. Ugh. Surely there's a simpler way though...

I think all it was before was a views thing that had a search box tied to the correct taxonomy... but now I feel the need to check.

That's what I thought it was too. I installed Views on one of my dev copies (not test.randomland.net, I don't think). It was almost working...and is probably the bbest approach (for a backend at the very least). I do, however dislike its URLs...and so does SMF

I played with views on the test site a little at lunch today, this is what I managed to get in my limited time.
http://test.randomland.net/gallery_test

It's not much, but shows that it can be done. I will work more on recreating our gallery, and I will try and keep the URLs pretty :)

Of what I can think of, the only major thing we'd be missing is multi-file uploads. But that's fixable.

Cool. But I give up; what are you querying for? I tried playing with the Views UI a few weeks ago and had trouble getting the GET parameters to work like I expected.

I we figure something good out, we can automate it.

I didn't do a query (or filter as it calls them) I just got all the image nodes. I only spent about 10 minutes messing with it. But it looks doable.

oh ok. Well, if you figure out how to make it filter by URL parameters (specifically tags by machine name) then cool. I kind of gave up. But that doesn't mean it's impossible, only that I'm lazy.

I have it filtering by taxonomy terms. Is that what you meant? Its simpleish to make it do it by ID instead.

Here ya go

• http://test.randomland.net/gallery_test/thanksgiving-2010
• http://test.randomland.net/gallery_test/camp-camp-2010

for the two collections we have in there so far.

And this:

• http://test.randomland.net/gallery_test_2

That's a list of all the collections. I don't yet know how to make it use a preview-image. Doing that might require some PHP.

(I thought I was writing a reply to this already, but it seems to have been a mental composition only  ???)

Cool, that's a nice start. Can you get it to query multiple terms names via URL? (This is where I got stumped) Ideally, we would have a few different options, like "union", ....oh I forget my math terms! Like this:

• cheese,camping means cheese AND camping
• cheese+camping (same as above)
• cheese|camping means cheese OR camping
• cheese+!camping means cheese AND NOT camping

Mind you, that's just off-the-top-of-my-head syntax. But that sort of thing (especially the first) is used frequently.

Then I tried combining term filtering rules with a some other filtering rule, and the whole thing fell apart. Like maybe:
/gallery/title=snowball&tag=snow+camping&collection=snowcamp08

Perhaps you get the idea. Anyway. I never got that far (and perhaps that's not even what we want). But that's where I start, mentally.

I think that would be a different page made for searching rather then browsing collections. But you can pass multiple collections to the page as it is (I just updated it to include that.) Just use a ',' between collection names.

Example: http://test.randomland.net/view_collection_by_id/31+17

You can only do it with IDs at the moment it seems. But (from the looks of the options) they are going to offer it with term names as all. At the moment it is not handling the text input correctly for the multiple terms, but the IDs are fine.


We are also running the DEV version of Views due to a bug in the current release (multiple terms would not even work as IDs with that release.)

I think I ran in to that issue too (multiple IDs worked, but not multiple terms by name). Surely that's a desirable feature that will be fixed eventually. So we might as well build around it...instead of completely stopping...which I what I did  :-[

Anyway, one thing Nick and I were talking about is setting up the module to define templated search pages (.tpl.php). Then just invoking whatever view we need and skin the results how we want. This might be an overly complex way to generate a simple query, though; it seems that Views was designed to be an all-in-one solution for this type of thing. I dunno.

Soooooo, maybe a better place to start is defining what we want. A while back, I updated the wiki page (http://wiki.randomland.net/index.php/Randomland_Image_Embedder#Open_Bugs_and_Issues) with some possible URLs and outputs. Please edit them. I don't yet know how we want the gallery to behave, so let's get something down and discuss it.  :) (Note: what I defined in my last post is probably different than what's on the wiki...)

I'm lame and haven't touched the picture stuff yet. Plah.

What else do we need to sevenize?

All of our content and the theme/make new theme.

The module 'migrate' may be of use for moving our custom content over. I am not sure how it works yet, but you create files that define what you are getting and where it is going and it takes care of all the commands to get the data and create new nodes/taxonomy.

Also. I tried running the included update.php script for drupal 7 (that comes with drupal, nothing to do with the migrate module) and it seems to not like our site. I get the 'white screen of death.' Not sure if its some modules or what.

I was thinking about the lack of a SMF drupal bridge for 7, and what are people thoughts on OpenID?

I looked into it briefly, and both SMF 2 and Drupal 7 seem to support it. We can set up our own server or user google/yahoo/whatevers servers (i.e. Authentication provider.)

Thoughts? Ponderings? Or Musings?  

Of course, the other option is to just use the drupal forums (not that there is any way to migrate the existing one. Unless there is a smf->v-bulletin->drupal-7 path I didn't find)  

Furthermore, drupal can act as an intermediary for openID logins: http://drupal.org/project/openidurl
You could log into places by adding http://randomland.net/users/yourpersonage to applicable accounts.

Ok.. done editing. Back to busytimes.

Using OpenID seems like a good solution to the lack of a Drupal bridge. Implementing OpenID is actually one of the things on the "sevenization list". I definitely want that working.

I played with it a month or two ago but...in classic Drupal fashion, it either wasn't as straightforward as expected or I am too dumb to understand what it was doing. Do we need to set up some authorization scheme? If you want to play with this, go ahead :) I definitely want it working when we switch over.

Ok. I will look at that more and see what I can do. It sounded like an interesting concept, running ones own method of identification. I wonder how much better it is then shared keys or some scheme like that. Research, research. Looks like I have some reading to do, out of curiosity of how it all works anyway.

Cool. Let me know if I can help.

You can use an OpenID to log into the test site.
Its built into the core and only needed a php module added to work. Its not perfect, but seems to work in most cases.  Actually, I think its fully standard compliant. Its just google that is breaking the standards in some cases (the google-apps randomland-specific page for the OpedID login does not work with it, but the generic one works. And the generic works with all google accounts of all kinds (I think.)

Make sure you have the admin overlay turned off, or access your user config page directly, using /user/USERID/edit in the url. You can get your userid by clicking edit and letting the overlay come up and looking in the url. The overlay breaks the page forwarding for the OpedID authentication check.

Go to your account setting and click nick 'OpenID identities'
enter your openid URL into the box. I set up openid.randomland.net to point to the google one. But this will change if we set up our own provider for this.
click the button and fill out your details. Google should ask if its ok (or yahoo or whoever)

We can add a module that will show icons for major providers (the same one that stackoverflow uses)

Google works, yahoo works after setting it up, and I am sure there are dozens more that work well.

Sould we set up our own provider?
http://wiki.openid.net/w/page/12995226/Run-your-own-identity-server

Ok, so I maybe kind of get it. But it wasn't exactly self evident that my username should be https://www.google.com/accounts/o8/id. A login screen more tailored to OpenIDs (like the one you mentioned) seems in order. Plus, why does Drupal want email verification? Verification it seems to not even be sending out...for what ever reason.

So, what's the benefit of having our own provider thingy?

The only benefit of having our own provider is it would be compliant with standards and work everywhere. That and a url you might remember. But the openid.randomland.net is easy to remember, though it only goes to google. It could be changed to go to a php redirect page that takes arguments as to what service to forward to. But just making 'click here to choose openid provider' with a bunch of icons is better. 

But the draw back is we lose out on all the advanced security stuff that the big players have had the time to implement. Like the custom verification images that accompany the login page (not that that would be hard in the slightest to do. But they do it in a way that prevents automated bots from making screen grabs and creating spoofs lognis to try and fool you into giving up your password)

I like the idea of OpedID, but I don't think I like the general implementation of it. Its a little fractured and wiggly. With tenticles going every which way.
The google implementation is complex and unstable. There are many pages telling you to use your accounts profile page, but that method no longer works. The current method is probably going to be around for a while, but who knows. And what is with the URL format? Is it really that big a problem to pick something easy to remember?
The yahoo implementation on the other hand, is easy. Just enter yahoo.com OR your profile OR me.yahoo.com.
I haven't tried any others.

With the exception of the openid people themselves, everyone is hiding the fact that openID is being used. Sites mostly just say "click here to log in with X" to avoid confusion. No one who isn't tech-ish knows what it is, and most of those people only know it superficially (like me.) I guess it is a young protocol... it has all the technical stuff ironed out... but none of the user-friendliness. Will one provider win? Will we all have to log into everything with a facebook id?

Also, SMF's openid implementation is broken for any provider that wants to use HTTPS (both google and yahoo do)

So we have to use plain-text transmittal of credentials (not your password, but your identification hash) or not use openid with SMF... or not use SMF.


Update:
The drupal forum module is super ugly....
http://test.randomland.net/forum

That is ugly. But what is it? SMF embedded in Drupal? Or the Drupal node-based forums?

Its the drupal one. I just enabled it to see how it looked. I am sure there is a way to style it.... but as it is its hideous.

And doesn't work with my phoney app. Boohoo :(

Installed the dev version of Advanced Forum module.

Looks much better now. Viewing posts is still ugly.... I don't like having the text box shown by default. And there is too much crap on the screen.

That certainly is better. Though I don't know...is it worth leaving SMF behind? I could take it or leave it. But now with my little tappyyacker forum app I've been using, I have a compelling reason to stick with SMF... :\

Still, I like the idea of the forums not being off in their own little world and properly bridging logins.

Another option is to give phpbb a try. Its also free, and SMF will migrate to it relatively easily. It has the OpenID as well, but still... we would be missing the drupal->forum bridge.

I am also tempted to just add some code/make a module that runs during registration and login and calls the SMF functions for logging in. It would be about the same as what was being used before. Even better would be to make a SMF module that allows it to use the drupal users as they are. And make it ask drupal/look at the cookie to see is the user is logged in (again, that kinda like what is done with 6 already.)


Edit:

Also, they are making a tapatalk module for drupal, but its not ready (or even close I don't think) at the moment.

I've been the 514x0rZz^{1 (http://google.com/search?q=define%3A+slacker)} and haven't done anything with the test site in [proverbial] ages.

Do we need to figure out the Drupal-forum login thing still? I suppose that and a semi-functioning gallery is really all we need...

Yup. Those are the two biggies.

I think the gallery is 1/2 ok. Need some sort of bulk upload... or better yet something that could interface with picasa or something for the bulk uploads.

The forum just needs to differ to the drupal login credentials. I am sure once we start looking into that it wont be too hard to hack something together.

Hmmm, uploading through Picasa sounds like a "fun" challenge :) Maybe I will check out the APIs some day. Though I should probably make it work in Drupal first.

I just downloaded the Gdata API (http://framework.zend.com/download/gdata) to my home computer for playing with. My original intent was to make a Randomland-hosted GUI to a data-tracking spreadsheet I've been using lately (gas log).

Anyway, I was thinking, if we need to use it for letting people log in with Google IDs, I'll at least know...well, I'll at least know how to install the framework :P (not that it's hard or anything)

Grumble cakes.

Not sure picasa would work well, though it would be cool if it would. There needs to be a standardized image server, upload format and interface between a client and server. This would allow all sorts of UIs to use a standard server to source images, all sorts of client utilities to upload images to the server and far fewer headaches with everyone repeatedly recreating the same functionality in a dozen and a half frameworks. All you would need is a module that polled the server for new images added and then create nodes pointing to them, or treat them as nodes doing a query against the images stored in the server.

But until that eventuality (google and flickr already have such things, I am sure. Plus there are some not-so-free solutions already out there.) we can use something else.

There is a thing called plupload.  It has no fewer then six different upload interfaces built in (one for HTML4, HTML5, Flash, Silverlight, Google Gears, and Yahoo BrowserPlus.) We could combine that with a php page that passed the data to drupal functions to create nodes from the uploaded images.

There is a drupal plugin for it... but it has no UI associated with it and I don't know how to use it. As it is, your supposed to integrate it into a module as the upload method. But I don't find documentation as to how. And its in beta.

Whats the thinks amidst the randomnets?

Does anyone have anything important sitting on the test site? I have a hankering to toss Wordpress back up there, just to see if it's useable.

Reasoning? I happened upon some post mentioning an Android app for posting to Wordpress blogs...and heck, if we post more content, it'd be worth it. And I'll bet there are useable image galleries!

Running Drupal is kind of like me owning a machine shop...awesome, with endless possibilites! But it's hard to use effectively and there's very little usable output. Oh, and did I mention I have the machine shop primarily because I wanted to make nice, shiny, perfect...um, nails? Yeah.
Um, [/rant], or something like that.

Let's give simplicity a try on the test site. Any takers?

The only thing I have on the test site are the views that I configured. But I saved their configs to the google docs thing.

There is an ok gallery for drupal 7, and its close to working all the way... The only thing it is missing is multiple file uploads at the moment, that and me being able to get it working on the site.

Why don't we create a wordpress.test.randomland.net and a drupal.test.randomland.net. Then we can compare and contrast.

I hate to abandon the power of drupal, but the 'it just works' of wordpress (not to mention its larger user base, and therefor greater number of community contributions) might be worth it. It feels like abandoning ones manual transmission for an automatic.  Really nothing wrong with it... but still.

A sad, but fitting analogy. Which reminds me how much I miss that manual tranny...

But from time to time I come up with ideas to post to randomland. Sure, not doing so is at least 80% apathy. And I rarely have anything worth saying...but large part of the remaining 20% is related to me not wanting to fight its interface...7 is much, much better though.

And perhaps its slightly pathetic, but being able to toss up a "blog post" from my phone seems like something I should be able to do with ease. Right now, it's certainly not. The Drupal community disappoints me with its unproductiveness. (probably because it's a pain in the butt to extend...)

Just thought re-exploring our options sounded like a good idea. So sure, let's toss them both up there. (we could put them at test.randomland.net/[name], if that's easier...)

Options, options...

Both methods are equally easy. Just having a /whatever is fewer steps (and there is no need to wait for DNS to propagate) So lets go with that. Just throw up a directory page with links to all the sub-test sites on the root of 'test.'.

There is a module that lets you post entries via email... but I am sure its not easy to get the formatting you want.

I remember that email thing. Sounds cool. It may be a bit of a pain to configure, though...who knows.

I would be slightly sad to ditch Drupal...but Randomland is just a playground. So I might as well be acquainted with the options out there!

I just downloaded it. It's at test.randomland.net/wp (http://test.randomland.net/wp). It's not set up yet, though. Feel free...

Edit: ok, I set it up. It look like 5 minutes....including me looking up the SQL to create a new MySql user (not sure why I can't commit that to memory, but that's not the point). I installed the first gallery plugin I saw. And it works! Wordpress feels more refined than when we first tried it ('08?). Hmmm....a temptress.

Edit 2: and a mobile theme. Easy cheese.

Also, going down the wordpress lines, there appears to be a working and up-to-date bridge for SMF (http://wordpress.org/extend/plugins/wp-smf-a-simplemachines-bridge/). So we could finally go with V2 of the forums.

Hmmph. Drupal, you're looking awefully sad, these days...

Well, to be fair drupal 7 is brand new and no one wanted to make modules for it until it was complete. But still, they have had months and it shouldn't be that hard. All the basics are there. We are just missing a way to bulk-upload files into new, tagged nodes.

The draw back of wordpress is not having the nice taxonomy of drupal for tagging and searching the images. Though I am sure there is some sort of add on for it. I must play a little more. See if there is some missing thing that will drive me crazy.

If only I had more time... I could just make all the missing modules. But then I would lost what little social time I have as it is :)

Creating Drupal modules is actually moderately painful. The API is well documented; how to do stuff is not. I had to read through a lot source code to figure out how to do simple things...it was the only way. Not to say I don't like the challenge...it's just incredibly time consuming to code trivial tasks.

Wordpress may or may not be better. I'm just "playing Devil's advocate," or whatever. I like the idea of actually using Randomland :) I can't really think of any advances features we are using...Randomland's actually pretty tame.

I played with the wordpress a little. Its a bit different and needs some additions. But I think we can make it work.

One thing we will likely want is a good gallery setup.
http://codex.wordpress.org/Photoblogs_and_Galleries
A little bit is detailed here.

I installed one plugin for tagging images and one (that does not seem to do anything) for showing exif data. But the above seem to take care of all that on one package. We will have to take a look. I would like to know if images are stored as their own 'pages' or what. And is it searchable on tags and titles/captions?

I would like to know, too. I mostly like the idea of saving images as nodes with a title, text, short caption, and exif data...

I installed a Twitter thingy on the Wordpress tester. Drupal had a decent one a while back but it stopped working and I never updated it. I was going to attempt the SMF bridge, but didn't get around to it.

I made two more word press installs while I was waiting (for only 10 seconds according to windows) for some files to copy. I will try out some of the 'photoblogging' plugins and gallery plugins to see what does what we want. And I think we agree, one image + discription to make an image 'node' and group by tags into collections. ??

Quote from: Nick on Apr 21, 2011, 10:36 AMAnd I think we agree, one image + discription to make an image 'node' and group by tags into collections. ??

Yes. That's the rut my brain is stuck in, at least. It seems to be the most "lightweight" solution.

And for that matter, I am now of the opinion we should organize content similarly. Just tag posts with broad tags (like auto) and be done with it. My old ideas are total overkill for our utter lack of content. :)

 Seems like there might not be something like that for wordpress. Everything wants to make one picture per post, or have images added to galleries explicitly (then just linking to the image files or making a lightbox)

I guess another option might be to use the built in media gallery thing and use PHP to search tags and generate a gallery at run-time in a template.

This is from their gallery 'shortcode' page:
<?php
   $gallery_shortcode = '[gallery id="' . intval( $post->post_parent ) . '"]';
   print apply_filters( 'the_content', $gallery_shortcode );
?>

include
   comma separated attachment IDs, [gallery include="23,39,45"] will show only the images from these attachments.

Using the include option might do it.

Wordpress seems annoying in that everything is either a page or a post. There is a media library, with titles, descriptions and now tags for files. But there seems to be not way to view the media items on their own other then a direct link to the file, or making a dedicated post for them. I think this is why we went with Drupal before. Wordpress is very limiting. But it has MULTIPLE very nice bulk-upload tools. Makes me GRRRRR.



Edit:
I found how to view a media entry on its own:
http://test.randomland.net/wp/?attachment_id=15
By its attchment_id.

That is a really awesome picture.

!

Haha. Thanks. That's the magic tank that Cody randomly came upon while digging a hole.

That was quite awesome. Awesome enough for me to say "campcamp"!

Edit: as for the topic at hand, did you find anything about the images galleries that would make life harder/easier than our current Drupal setup? I didn't mess with it at all this weekend...

I did no messing with it either. And I am sadly not moving masses of files today. I will try and look at them though.
The one photoblog setup I looked at didn't seem like what we were after.

http://test.randomland.net/wp/?p=30&preview=true
Also, there is a 'tag gallery' plugin. That works with two other plugins to do 'lightboxes'
Its not as powerful as drupals solution. So far the only advantages wordpress offers is SMF integration and a bulk file uploader.

So our options are:

• wait for drupal to catch up.
• Fix the wordpress plugins to be better (I think this is doable)
• Move the gallery off the main site.. I don't like that. We are to thin already.
• Fix the drupal plugins/make them work better. If all we want is a nice flash/html5 uploader that creates tagged image nodes I think we can hack something together.
• Live with the crappy admin menus of 6 and make a new theme
• Get a jeep

Yeah, I think I know enough about Drupal now to hack an uploader thing together. It won't be pretty---I had a semi-rant written, but then spent 10 seconds and brought this up, IMCE module (http://drupal.org/project/imce) (Drupal). Whatever shortcomings it has, it is certainly better than what we have now. And there is a 7.x version (yay). It's installed now (http://test.randomland.net/drupal/node/3). I think we've played with it before...

So, lest I forget, these are about the only things I care about having functional on a Randomland CMS

• Posts with tagging and commenting support (given)
• Server-hosted image support. Tagging and batch upload pretty much required. External services (Flickr, Picasa, etc) is cool, but really not necessary.
• Mobile theme (detection is probably a module's responsibility; we'll write the theme)
• Forum login bridge. Better yet, support 3rd-party logins (Google, Yahoo, OpenID, etc) on both the main site and the forum. And you'll never need a (user-visible) Randomland account again!

Am I forgetting anything? I like the wiki idea, but we're too fragmented; we ought to shuffle any worthwhile content back over to the main site. (I know, I probably could have done that in the time it took to write this sentence...) We could tweak permission such that anyone could edit the posts, I suppose. But that's a use-case with no user.

Edit: half-thing number 5 is mobile-friendly posting capabilities. The Wordpress app looked decent; I've found nothinga little (http://drupal.org/node/414808) for Drupal (exceptand a chorus of "yes we should!") I'm going to start digging into the Android APIs in my spare time, so this could be a new project. Of course, a decent mobile theme would be almost as good...Almost, but not quite because mobile Safari likes to hard-refresh pages if you leave them sit for 5+ minutes, thus erasing your entire post if you decided you had to pee, smack your cat, or work.

Let's use IMCE (http://drupal.org/project/imce) for Drupal. It's works (http://test.randomland.net/drupal/node/3). And pretty well (http://test.randomland.net/drupal/media-gallery/detail/3/2).

I like the look of it, and it does work... but....

http://test.randomland.net/drupal/taxonomy/term/6#overlay-context=taxonomy/water

Images are not their own nodes.... so their tags don't make them part of the taxonomy. Unless I am missing something.

Edit:
Also, I just disabled the Media Gallery module so we could be less confused as to what part of what we are talking about. IMCE is not a gallery.

Does that mean I was using the Media Gallery the whole time? :P I really don't care...I just want pictures! :)

If we need to write custom search scripts, then ok. I guess. Not fun, but we can do it.

Do I need to lower my standards in order to get something functional?

If you just want a gallery, then using views and tags works.

If we want a bulk uploader then..... not drupal at the moment.

Perhaps there is a better gallery then the Media one that works with the IMCE thing.

Does this mean I have to go back to being disappointed by Drupal? :(

Never! And always.

Drupal rocks, but it is missing those little things... the things that make so sense to have missing. The things that seem so obvious to have that it dives you just a little bit crazy that they are missing. Leaving you with a throbbing head and aching teeth from the dull frustration of searching for something that has to exist... yet cannot be found.

The ability to bulk create nodes. Present in drupal 6 in multiple forms. Missing from drupal 7 (Should be in the freaking core) The one module that is capable of this only works with other modules that call it.

Perhaps we should create our own version of the fUpload module (its rather in demand for 7... yet no one seems to be working on it.)

I could probably hack out a proof-of-concept in a sleepless weekend. What's the existing batch upload module called?

pupload. The most basic thing we need is a php script that eats a directory and spits out nodes of images. All while making the images get thumbs/preview sizes created.

But a bulk node creation/upload page would be nicer. If you want to do this I will set aside some time for coding it. I can give the dwarfs and the portals a break for a few days.  But as soon as we finish something, a semi official one will get released :)

This seems like a job for Drush. And that makes me shudder!

Ok, so, I spent a few minutes playing with the image modules we have installed on the test Drupal (http://test.randomland.net/drual) site. I think it's pretty usable. It does everything I was trying to do in my own attempts at a Drupal module. That is: individual images with titles/descriptions, galleries, tags.

We (probably (http://drupal.org/node/1044504)?) still lack a mass-upload option and a way to view/search EXIF data.

Using the Media module markup, we can embed images in posts via unique ID. See this example (http://test.randomland.net/drupal/node/6). The syntax is both unwieldy and sparsely documented. If it's of benefit, we can wrap this up in my crappyclassic rlimg syntax.

Edit: aaaaarg, I tired to install a multiple-upload module. All I managed to do was raise my blood pressure. And get grumpy at Drupaldom's Perpetual Beta. I just want something that works!

:) that's about how far I got.

It's so close to usable, and yet so far.  What should we do? All we really want is a few random pictures and an easy way to reference them. Just like everyone else on the internets.

The easiest way I see it is to use the pupload module and make our own interface for uploading masses of images. Then use views to make galleries. They are easy to style. The old ones were ugly only because I suck. Other then that we get stuck with crappy implementations of galleries that look ok but don't offer much versatility.

The other (drupal) option is to make a cheesy php script that turns images into nodes and moves them into the appropriate folder and calls the things for making thumbnails.

Or go wordpress... and somehow find a gallery system that makes images searchable. That is another option that seems just on the cusp of working.

Dupal gives us all the searching we want... wordpress gives up all the pretty and bulk uploading we want.... Pooot

On the wordpress front:
http://test.randomland.net/wp/media-tags/woods
http://test.randomland.net/wp/media-tags/miniature
http://test.randomland.net/wp/the-sick-light-from-a-fading-sun/

The two last links are showing the same tag.

EDIT:

• 
  I did a quick hack to make the images link to their media pages (a.k.a. nodes) rather then opening a lightbox.
  Here -> http://test.randomland.net/wp/the-sick-light-from-a-fading-sun/
  Now to add this to the lightbox instead. This is still not ideal. If you want to comment on an image you have to go to its page and then hit back. It would be better to have next>> <<back buttons on the media pages... but they are media references not gallery items. Oh drupal.... get your act together. This was all so easy over there. But the tasty, tasty uploads make wordpress look so shiny.

Those are both from the 'media tags' plug in and the 'media tag gallery' plugin and a generic lightbox plugin (there are other options for the boxzez.)
Its supposed to be easy to control things via the templates. It should be possable to make a views-style (?tags=boots,cars,ziggons) search using php in the templates. I think I will try messing with the templates when I have some time. Lunches and evenings are just too short. And I get no sun behind a computer :(

There is no integration of the media-tags into the site-wide search.

Also on the wordpress front:
Moving all the content over :P
But that goes for drupal as well... they haven't finished the migration tools yet.
I think 7 might have exited RC a little early.

Again... we could just work on making 6 look nice. Its not like its not a viable platform. It just has ugly admin interfaces.

Well, we can almost guarantee we'll lose all picture references again, no matter how we play it. But aside from that, Randomland doesn't really have much content. Nevertheless, I'd still rather not port it over by hand. (I did find a how-to a while back, but it still involved writing a few queries)

Migration is never fun, but I do think it's time to move on. Drupal 6...bothers me. Yes, a lot of it is admin menus, you're right. [useless rant removed]

Then there's Wordpress. With its shiny, simple appeal that promises everything we already have. Except [Drupal rant removed]. If I remember right, the primary reason we dropped it was that our hosting server had really horrible query speeds. A point now moot.

I say we should go with whatever gets us the most functionality while being as lazy as possible. I have other projects :) And we have survived without all the cool image gallery features we keep mentioning...

Ok :) Just pick one then. They both offer their own headaches. With wordpress we (or I) will have to screw with a few plugins to get them to work how I would like (then we cant upgrade them easily) and with drupal a bulk image node creation page needs created. (I know, I just keep repeating myself here)

I am up for either challenge. I will even have some time in the next few days to work on something.

Personally, my vote goes to drupal. Mostly because I am used to it. And I like its versatility. But shiny simplicity has its own allures.

Anyone up for an rlimg-upload module?

Edit:

• Another lunch messing with the junk and I think the media module might work (for drupal) I will try and make a proof of concept for it. Basically using views to display the media and media *nodes* (Note: The 'media' items seem to be in nodes... but ugly ones that display all dumb.) I will have to give it all a try. But I would still rather have images be their own nodes for the purpose of mass browsing and easy workings with.

Well, if you want images as nodes, just try the module I made (RandomCore (http://test.randomland.net/drupal/admin/modules)). I just got distracted and then buried by a heavy pile of apathy...wanting something that worked.

As it is, it does do the basics. And most everything there is functioning, at least at a basic level. Like I said, I just got [a]pathetic.

• Images are nodes (title, teaser, long desc, tags, collection).
• Collections are made by a separate taxonomy, which is dynamically created when the modules is installed.
• Single upload works fine; it uses file field.
• I incorporated PathAuto, so you can a preset SEO-friendly URL. I think I was doing collection tags as gallery/[name] and ignoring single images.
• EXIF data half-way works. Select fields are stored as tags on the current images. (Doing every field is nightmarish overkill)
• And of course the rlimg input filter (slightly broken?)

And that's how I remember it. If we do go that way, go raid your patience stash; there's sure to be misbehaving features. I'll be happy to explain the code (http://randomland.net/repos/randomland/modules/rlcore/) and everything I know. True be told, it'd be nice to put it to use, as there a dozens of hours poured into those few little files.

...crap, I just convinced myself to write an image gallery again  :-\

Ok, afterthought #47: I remember now. It was my attempt to dynamically create views for galleries that brought on apathy's full wrath (if that's not oxymoronic). My feeble attempts to create a simple view using the Views UI made me feel like a toddler trying to reassemble a pocket watch. Idiotic analogies aside, if you can master Views...heck, if you can even use Views, we can wrap this this up and use it.

Views are better then they were. They just redid the UI a little. I can make a view it I think (the RL guy.) The only reason I would go with the Media module is its bulk upload capability (the only one I know of for 7) If we just add an upload page to the RLimg module and use the pupload module with that I would be happy. Making views of RLimg nodes will be easy as pie. Not that I know how to make a good pie. But I am sure I could grad a few modules out of the cupboard and plug them into the mixer and come up with something :)

Mix away, o' chef of Randomland.  :)

There is always the wikimedia-type solution.

http://commons.wikimedia.org/wiki/File:Snaildance764.ogg

True, that does have everything we need. For unknown reasons, I still like the Drupals better...

Here is with the dupals using the rlImg. With the views you see the grid that it is. Only issue being is never the bulk creation of node.
You see this here? Link! Link! (http://test.randomland.net/drupal/collection/18)

Although, the module 'feeds' may offer some reprieve for the time being. In regards to the mass creation of node that is. It will create nodes, taxonomy and more from a rss feed or a cms file. This could be used in conjunction with wordpress to create images node (by feeding off the rss feed from a wordpress install to get the image URLs, descriptions and possible taxonomy. Though this would be far from ideal.

Better, our efforts should be on creating a simple system for mass creating image nodes from a pUpload uploader. I will get to work on that... at some point. As it is presented above, it works (based on taxonomy ID. But listing taxonomys with links is easy.) Its just very time consuming to upload images one at a time.

Whatever you did, I like it. Should I try to automate that in the module code?

Its just a view module 'view.'  It needs some CSS added to make it pretty and perhaps some light/thin/thick-box added.

Now if only you could add more then one at at time.

You can also add collections together
http://test.randomland.net/drupal/collection/35+20

If you put some random numbers in there you will get odd results. Like all the images that have iso 200 or something. Its not filtering very strictly at the moment. But that's easy to change.

This is more or less the same this I set up on drupal last time, before we got frustrated with uploading options.

Well, we need a new theme anyway...

I am apparently really sucky with using the Views module. So I'm glad you're not. Aside from the mass upload issue, which seems to be a problem with every image module, does this do enough of what we need? Is there a way to combine terms, like the 35+20 (http://35+20) example you gave? I mean, we could write our own queries, but then apathy starts sounding appealing again.

I need some woods.  :-\

"You can enter multiple values in the form of 1+2+3 (for OR) or 1,2,3 (for AND)."
Or so says the views module. This only works for node IDs, not their textual names. We would have to set up a template with some PHP in it to do that. Or wait for support for that to be added.

Oh yes. I remember that vague promise of "this feature will be implemented some day." It's really quite a shame, and made me frustrated because it was close...but not quite good enough. Then other things, like staring at the carpet, quickly became more productive.

Anyway, what do you suggest?

PHP and a template. I am not 100% sure on how to do it, but I don't think its hard. Might have to make it a module that works with the view (the module would just parse the URL and convert the names to IDs to pass to views).

A list of all the collections (30 per page)

http://test.randomland.net/drupal/collections_list

Can be made into a grid. Will take some PHP to get preview images for the gallery.


This is how we setup custom templates:
http://views-help.doc.logrus.com/help/views/using-theme

I will make a test one for the collections_list view

Cool. I'm full of apathy today.

Did you do something to the test server, or did I break it when I was trying to make a tar-ball of all the sites?


-----
Ok, it was me. An unknown portion of pages are now .gz files.
Uggg. We should change the database password now.

-----
It might be fixed now.

I spent my lunch playing with some dupal API functions and this is what I have for a page that would list all the collections. It even has a preview image of the most recently added image for that collection.

http://test.randomland.net/drupal/collections_list

You will notice the collection-list looks allot like the view for an individual collection:
http://test.randomland.net/drupal/collection/18

Comments? Suggestions? Any way we can differentiate a list of collections from a single collection better?
Perhaps showing more then one preview-thumbnail overlapping? Like one of these:

Cool, good job. This is looking usable :)

I'd say don't worry about the look too much right now. We ought to write a site-wide theme anyway.

But I've seen people use folder icons for collections; the highlight picture is a nice touch! Then use three fanned out folders (or similar) to show multiple collections. That's what pops into my head...

It should be easy to make a few <spans> with borders to make the stacked-images effect behind the 'highlight' photo.

There is currently no way of grouping multiple collections, so there would not need to be any representation for them. We would have to change how the images are related to do that.... unless you can add taxonomy terms to other taxonomy terms. Or use a child->parent relationship. I guess the child->parent relationship would work just as it is now, we would just have to make another view for it.

Yeah, let's not bother with grouping collections right not. I don't really see a point unless we dive into an unmaintainably complex image tagging system (aka what I designed in college :))

I need to play with stuff on a bigger screen :)

Edit: and yes, I believe the taxonomy system has that parent/child hierarchy built in already (see ISO tags, unless I killed that). But I say that's too much work for not much benefit...at the moment, at least.

As a major player in the field, flicker might be a good place to look for inspiration.
http://www.flickr.com/photos/14012135@N04/tags/

Their tag cloud is nice, and their presentation of lists of sets is extremely plain and standard. I also like their view of a set. Though I wold do it a little different for our format.

Now to get some king of bulk node creation going on. Maybe tonight I will try a little.

Tag clouds are nice. A bit bulky, but still my favorite way to represent tags. Probably not entirely useful at the multiple collection level though.

I was thinking just having a tags section someplace to show the frequency of tags. Just as an exploration tool. Probably could do it for user, collection and site-wide.

Right not tags and collections are two separate fields. That way you can have a 'my vacation' collection and tag a picture with a green truck in it without inadvertently creating a green truck collection.  I think images should still be filterable/searchable by tags both inside and outside of viewing collections. Like wanting to see all the green trucks in your vacation collection and then wanting to see all the green trucks on the site.

But that's just what I was thinking. Who knows how it will turn out :)

Any suggestions on what to use to display the tags? I could try to code these tag clouds. There are a few out there already, for sure. And there shouldn't be any problems, since the tags are just basic, flat taxonomies. Let's do it!

Have a link to a tag page along with the other collection/image links? Not sure where those would go just yet.

But have a look at this and see what you think.
http://test.randomland.net/drupal/collection/35+20

I got it to show the terms that were used to 'filter'... 'search'... whatever the collections. So now there is some feedback as to what the numbers on the top are. This will work with as many collections that one wants to stick together.

I screwed around with the templates a lot for this as there seems to be no way to do it with straight-up views.

So I guess all the parts now exist in a useable form. A little more tweaking should be done but I am happy with how things are as a rough-draft. If we wanted to start moving the site to 7 and worry about getting bulk-uploading done later I would be ok with that. Or we can wait for the bulk-uploading to get hashed out. I am 13.4% more comfortable working with drupal-guts then I was last week... so it all seems that much less daunting. And also make we wonder even more why such a module doesn't exist already. (For the bulk uploading that is)

BAMBLEDIT!
Should we make the
| TERMNAME | ANOTHER_TERM |
things into links to their respective collections?

Dude man! That's pretty awesome. We can definitely work with this. What exactly is the node shown there? Something dynamically created by the Views module? A page with a query? Can we specify a special tpl.php file? However it's done, it seems to be working well. I'll have to play with it some time.

As for the blambledit: yes. Making those term names into links would be excellent.

The node shown there is a view that does a quary for all the image nodes with the taxonomy terms 35 or 20 attached. It checks to make sure the the terms passes in are in the collections taxonomy (so you don't get odd results)

Its 5 different tpl files with names like 'views-view--image-collection.tpl.php'. I have edited most of them to get it to leek better then the (rather ugly) default. They are located under /themes/bartik/ at the moment. The default output was commented out. So changing the settings on the view for the displayed fields wont do anything (other then break it :))

And cool! No duplicates when combining collections that overlap:
http://test.randomland.net/drupal/collection/18+20+35

So where are we at? The last post on here makes it look like we have 85% awesome of an image gallery. Assuming mass-upload and prettifying (theming) can wait, what else needs done?

Has everything been created as "views"?

Obviously, we all have better things to do with our time...yet I still feel so compelled to make this work in some fashion.

Yup, everything is a view. We can easily make more for user galleries and for any other way that you might want to group pictures. If we want we can start moving everything over. We can try their upgrade scipt or with the feeds module.

A user gallery view would be sweet. Views for user, tag, and collection, "latest", and "random" are the ones that comes to mind. Those may not all be efferent views necesarily, but they have different functions.

Did I make a "private" field on the Image node? Seems like there was...or a "display in ImageStream", rather.

Is there a way to export the view's source (fields, filters, etc)? The reason I ask is that I think it'd be nice to store them in the module repo...possibly even make them "install" via the module, just to make things easier if we ever shuffle stuff around.

Yes there is a way to export them and load them. I will export the latest version and toss them into randomlands google-docs thing.


On another note. Randomland expires in two months. We can renew for 9 years for $64.40 using a coupon for 30% off. Should we?

Is this where we talk about the test site? There have been so many threads...

Anyway, I played with the Pressers (http://test.randomland.net) a bit more. It's quite a lot less painful to use than Drupal. Mostly because there are tons of plugins written...AND working.

To do our standard image system thing, we'd need to do a little tweaking, but it's looking comparatively simple to a Drupal solution.

So, check it out and let's find out what we need to do! I discovered there are a bunch of unused hours between 11pm and 5am. Who knew?

Most people use those hours for sleeping...

As far as the pressers go: it seems like it will be an ultimately easier solution then the druples. Though a single module for drupal could change that.

As for all this, we should come up with some standard for posting content that will make moving from one system to another easier in the future. 

Agreed. That's the entire reason I made the little rlimg syntax thing in the first place. Of course, our image references (numbers) are bound to get lost/screwed up, so it's kinda moot :-\

As for text input, I'm partial to the Markdown or Wiki markup syntax (they're very similar). I got nice automatic syntax highlighting going on with Markdown on the test site. Which should be good enough for anything we ever write.

With that, plus a simple way to embed images and video, we should be set. With the "Media Gallery Shortcode" (or whatever that's already installed), it pretty much works already. But I wouldn't mind tweaking it to have more styling options.

If we reference all the images by some kind of naming convention then moving them to a new system would only require that the /relativepath/imagename.jpg was the same. This line of thinking makes me want to just offload all the images to someplace other then the content again. Or make a new subdomain media.randomland.net with a wordpress install (perhaps the same one for now) that is the source for all local media. Then in the future we just keep the wordpress (or whatever) install around to keep the paths the same.

I've had that thought before, too. Then I come back to, "uh it's just a blog that gets posted to like four times a year..."

Either way, a consistent way to reference images would be good. Numbers are...not awesome, but it's short. And I haven't come up with something better. I avoided filenames (originally) because it'd be easy to for them to conflict. And prefixing it with a folder/gallery name has essentially the same problem, with the added detriment of having a longer input string. Plus it implies hierarchy, where we are trying to abolish and replace that with meaningful tags.

Suggestions?

Allowing them to be referenced by id-numbers but committing to a repository system?

http://test.randomland.net/wp/

Made a minor addition to the test site. Not really worth noting, but its quiet in here :P

Just lists the image categories as links. The default page for showing the categories is rather unfriendly. I will take some PHPliers to it next and see if it cant be bent into shape.

Also, how does one not have a post/page show up on the 'news roll' thing?
Also, the header is gigantic.

I only tried it from the mobile site, but cool. Yeah, most of those things need some tweakings. I've been...otherwise occupied.

Also, WordPress has a longstanding, unhealthy obsession with gigantic headers. It has always bothered me. But we need to re-theme anyway.

So much to do, so little motivation.

I understand the being occupied. Though you may have more excuse then I.

Let camping be thy motivation!

I was thinking "campcamp" this morning, despite the rain.

Soon! Maybe. I hope. We should bring some tarps and get some campcamp in regardless the weather.

So, a basic gallery is working on the WP test site http://test.randomland.net/wp/galleries/ . I edited the media-tag templates so things look 10% nicer. Still not a finished product, but useable.

All this is well and good, but I have found that wordpress does not support synonyms in their taxonomies (they hardly support taxonomies at all, really) and this is a point of annoyance for me. So a picture tagged tree and one tagged trees will create separate gallery sections rather then appearing as one.
This won't be a problem if people are careful tagging things, but could lead to some frustration and maintenance in the future.

Grrrr. Does no one share our vision!

I somehow missed this post...anyway, I know there ate things out there to alias urls. I suppose that's different than tags, but yeah. I haven't really had time to mess with this stuff lately. :( I'll try to check it out soon...so I at least know what's going on!

I just installed the WordPress app on my phone and made a test post (http://test.randomland.net/wp/2011/11/29/test-post/). Pretty sweet. We should try some content shuffling! And wrapping up whatever it was we were doing with the images.

I played with drupal 7 a little again today. There is a working (if slightly broken) bulk upload module available. It has fewer features then the one we used to use, but is young and being developed. At the moment there is no menu item for the upload page.... there is a bug report for that too.

But I managed to find the page to upload files:
http://drup7.randomland.net/?q=admin/content/media/bulk_upload/
Username: root
Password: Something to do with super rice....

Remember to hit "Start upload" under the upload box before hitting "Create Nodes"

It takes you to a page to edit details of the new nodes. It would be nice if the fields were exposed on this page so you didn't have to click 'edit' for each item. Adding taxonomy fields to the image node (I will do this soon) will allow you to set a default set of terms for all the images uploaded and then you would have to add terms to individual files if you wanted more terms, but only on some items.

With this, taxonomy terms and views we can create as good of a gallery as we had before. The only reason  not to move to the sevens now is lazytimes.

Edit (again) I added a shortcut to the content creation page (as they made it so easy that I could not resist) so there is easy access to the bulk page now.