right, that would require js customizations. certainly possible to do with inclusions, though I can't guarantee without looking that any given library would work out of the box. important thing would be to make sure the triggers are set to work even on dom objects reloaded by ajax.
But code can only work on certain kinds of cards, right? HTML? So if I made a new Cardtype, I'd have to set its default to HTML instead of Basic so that it wouldn't erase the javascript?
I think Shadowbox should work? It has a mode that they say you can use if your page has ajax. There are a few ways to use it. One is by adding an attribute to the link markup. But could you mix something like that with an inclusion? The other method is to define a class that would automatically work with Shadowbox. So I guess if images are already all associated with a particular class, that might work?
http://www.shadowbox-js.com/usage.html for reference
Ethan, any ideas on this?
I don't have time to dig into those docs. all cards included in content view (or any dynamic view) have several useful associated classes.
Okay. That gives me a trail to follow.
Well, uploading a .js as a file renames the file, so I'm not sure if I should expect it to work if I've changed the name of the script. Can I make Wagn not rename things? Also, the best I could see, the class would be card-slot.content-view.card-content.ALL.TYPE-image ? But can you actually stop there? Because the whole thing specifically references the particular image I use inspect element on. But the portion that says TYPE-image looks to be the only difference between an included image and an included basic card or card of another type.
renames it how?
you get to choose the name of the card, but the card itself can't have ".js" as part of the name. That's just one format. But in principle you should be able to render it with a .js extension (and the original name).
So I uploaded shadowbox.js as a File. I named the card shadowbox. The download link from that card tells me that the file is http://teenwolfwiki.com/wagn/files/shadowbox-16518.js
http://teenwolfwiki.com/wagn/shadowbox.js would work, but the optimized url will be faster.
Wagn isn't renaming willy nilly. The optimized names mean that you can break browser caches with each new version but still get all the performance benefits of browser caching. The non-optimized names mean simple urls will always point to the same card, regardless of how many revisions there are, but if you don't change the name, you can't be sure you're breaking the browser cache.
Technically, it's not actually storing the file with any of these names; the file name itself is numerical (id based) so that the files don't need to be moved if the card is renamed.
It's not storing it with any of these names... Would that mean that when I'm trying to link to these scripts and CSS in the header of a page, it isn't going to be there because the actual file on the server isn't called what I think it's called?
no. if the url works, it works.
The reason for all this magic is that Wagn supports actual permission checks on files. The name is processed by Wagn, Wagn checks permission, and then passes the file to the server. You can't get directly to the real file name without going through the permission check.
Since we process the names like any wagn card, you could actually go to shadowbox.js, SHADOWBOX.js, Shadowboxes.js, or shadoxbox!@!.js, and they will all work.
Should I need to specify the files/ subdirectory or no?
Hrm. Looks like this is all moot anyway. Shadowbox's CSS breaks the skin.
The most common way to implement this type of thing seems to be by adding an extra attribute into the link that you add to the image that leads to the larger size. Might this be something you'd consider adding to Wagn as built-in? It seems like something that would be just another attribute to the inclusion, like adding margins, only you'd be automatically applying a link to the image inclusion and passing along the attribute that the javascript is looking for (rel="shadowbox[Album]" typically)
Different sizes are supported in the URLs. The pattern is /files/ (filename)[-(size name)]-(version number)[.(extension as uploaded) Wagn supports a small number of size names that can also appear as inclusion options (i.e. {{image name|size;large}}. Without the optional size, the /files/... pattern seems to give the original file size (either 'full' or 'original').
There is a file uploaded for a background on my wagn that you can see this with too. In the *css card, it is: http://gerry.wagn.org/files/bg-10964.jpg which give the same as http://gerry.wagn.org/files/bg-full-10964.jpg, or you can go to http://gerry.wagn.org/files/bg-large-10964.jpg for a different size.
The mapping from the external URL to the stored filename is done in the application (ruby), so as Ethan says, if the URL works, it works.
it's a fine feature idea, but we've got a major backlog of those. We can create an Idea card for it, but I don't see it getting bumped ahead of all the vital stuff on our roadmap without funding.
Cool.
little more context: we're making a big push to get to 2.0 so we can promote the API and recruit mod developers. This is exactly the kind of thing someone should be able make a quick mod for. But in the meantime, the Grass Commons team's focus is on adding capacity, not adding features.
I understand. I wish I could be of more help.
I understand. I wish I could be of more help.