Randomland.net - Test Site Discussion

[zourtney]

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.

[zourtney]

Well, my documentation efforts sputtered because making crappy music is so much more fun! And I was looking into Drupal's Field API. 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?

[Nick]

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?   

[zourtney]

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.

[Nick]

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

[zourtney]

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?)

[zourtney]

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 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 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

[zourtney]

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 and notice how none of the image blocks have styling around them.
• Go in to the modules page, disable then re-enable Randomland Image Embedder.
• Reload the demo page. Image blocks should have styling around them because the @import url command got added to the page head.
• Reload the page 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.

[zourtney]

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.

[Nick]

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. 

[zourtney]

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.

[zourtney]

So, I got a crappy working version of the module up on 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.

[zourtney]

Regarding boring stuff, like testing:

I found this page 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.

[zourtney]

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..!

[Nick]

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.