@aitf311: Just a suggestion/idea but what about including these little rss link functions to have them in line with the other template tags/functions instead of using the variable?:

Sorry, the forum software does not like me, the code example gets all messed up, but I think you may know what I mean...

`

`

Ah, it finally did work...

acrylian: thats great! I'll get it put in with the next one

I posted the package with acrylian's new rss functions.

acrylian: What would be really cool is if it could be one function that does a couple other things like the printAdminLink function. Something like a printRSSLink() function. It could then be supplied with a type of rss feed wanted, [gallery, album, comments] and a spacing character ['|' , ',' , '' , '-'].
ex: would print "Gallery RSS | "

You're right, I'll update that as soon a I have the time.

So, why put this little thing off, here it is:

`

function printRSSLink($option, $prev,$linktext,$next) {

switch($option) {

case "Gallery":

echo $prev."".$linktext."".$next;

break;

case "Album":

echo $prev."".$linktext."".$next;

break;

case "Comments":

echo $prev."".$linktext."".$next;

break;  

}

}

`

acrylian: that is setup beautifully! I have implemented it into my build but I am not getting the albums to work correct

aitf311: My fault! Just a typo, there was a "&" missing between album id and albumname in the link of the album feed. Here is the correct one:

`

function printRSSLink($option, $prev,$linktext,$next) {

switch($option) {

case "Gallery":

echo $prev."".$linktext."".$next;

break;

case "Album":

echo $prev."".$linktext."".$next;

break;

case "Comments":

echo $prev."".$linktext."".$next;

break;

}

}

`

Now it should work.

Works like a champ! The new build is up that includes your work.

Glad to help! I thought of expanding the comment feed with an option for album and images. I personally will not need this, but maybe others. What do you think, useful? The rss functionality would be absolutly complete then ...:-)

Might as well, I just worry about the new developers keeping with trs's less is more philosophy. But the code that I have seen you do is right on par with that way of thinking, so I say it would be great to have it.

I am absolutly in line with the less is more philosophy. So I think there is no need to include everything that is done permanently in the zp core, some things could and should stay as custom functions. Just added when needed. Nevertheless there are many users without any code knowledge who like things working "out of the box". And at last these things are Tris' decisions then.

I will just do it, it's not that big deal. Everything else can be decided later.

By the way, I wonder why you are not on the volunteer list?

I don't know much php at all and it looks as if all the administration positions are well taken care of by thinkdreams. My main reason for creating the build was just to make sure that zenphoto didn't die!

I think that the trac wiki should definately be a better source for a lot of custom functions, much more than there is now. But some sort of custom function loader should be built into the core, for non-php people. Just my thoughts.

@aitf311-

That's why I think the plugin architecture should be developed as soon as it can possibly be. With a plugin API, hacks, mods, and custom stuff can be developed quite easily and then bolted on.

A plugin system would be good. I am not good enought with php for that. But a loader only for custom functions (the ones that work from within themes) is quite easy. I had this simple idea:

www.zenphoto.org/support/topic.php?id=1679&replies=1

Of course more a improvisation...

ait311f:

I have uploaded a new patch in ticket #6. This implements assigning any image from the "albums" folder tree as an alblum's thumbnail. Since the Admin interface is still outstanding, you have to use MyPHPAdmin to set the thumbnail name in the database. (See the description in the ticket.)

acrylian:

I think the drawback of automatically loading custom functions is the possibility for confilcting function names. Generally custom functions are associated with a particular theme so I think the best strategy is for the theme to be responsible for loading them. After all, the theme has to be modified to use the functions anyway.

sbillard: you are awesome, i'll have to check out your latest update. We have been discussing some possible ways to go with the plugin architecture. I really think that plugins/custom functions/hacks should be in 1 place. If you check out my post www.zenphoto.org/support/topic.php?id=1679&replies=1, I try to make my case. It really isnt up to me since I don't code much but it seems easier to manage if all of them are in 1 place. A simple way to avoid conflicting names is to do a check if the function is in the table already and if so, just throw an autonumber after it.

The package has been updated to include sbillard's ticket #6 update.

@aitf311:
I still think you should join the volunteer list, even if you are not a coder and "only" help with the trac documentation... You are the one that has the best overview, I guess. I am not that good coder too and not suited for real core issues, actually I am still learning the PHP basics (and my functions are sort of pratical lessons to me, I don't like learning these things theoretically).

@sbillard:
I agree and I think too we need the real thing. I made this auto loader mainly for testing my own custom function "experiments" and this was easier than pasting in and out in a custom functions file all the time. As I said an "improvisation" that I just wanted to throw into the discussion.

Updated the package to include what is in my opinion the most notable update since Tris stopped updating. Sbillard has fixed the admin to support subalbums and it is included in this build. More info here: http://www.zenphoto.org/support/topic.php?id=1697&replies=2
It also contains Sbillard's script to generate thumbs for all images, including subalbum images. Script here: http://www.zenphoto.org/support/topic.php?id=1169&replies=11#post-9710