Category naming problem

iamback

Since my SmugMug site will hold mostly travel photography (some of which is to be tied in with my travel blog), I thought a logical organization would be to have a top-level category for each of the countries visited (with a "places" subcategory for each, and possibly others). That also ties in with one "view" of my blog.

So I started to enter country names as category names and to my amazement ran into this error message:

You can only have spaces, dashes, and alphanumeric characters in Category names.

That's really surprising since I already know I can even use Unicode for Gallery names (any Unicode characters get converted into numeric entity references). But many country names actually require an apostrophe to be spelled correctly! Needless to say I'm disappointed (as well as stuck, since I want to use official names, not nicknames, for countries).

• Why this limitation?
• Any workaround?
• Any chance for an update that makes at least apostrophes valid in category names?

(Virtual galleries might be a solution - if we had them :cry)

PBolchover

iamback wrote:

(Virtual galleries might be a solution - if we had them :cry)

Power and Pro users _are_ able to implement virtual galleries.

Andy

Sorry, iamback, I wish I had a better answer for you, but I don't. There is no workaround.

iamback

PBolchover wrote:

Power and Pro users _are_ able to implement virtual galleries.

I'm a power user and this the first I hear of it. I even see people having it at the top of their wish list and advertising that fact in their signature... I'm not looking for any JavaScript hacks, just a facility on the server to create galleries that have links to photos physically located in other galleries.

How do I use this if it is already possible?

(And it would only be really useful to me if I could query such a virtual gallery from the API to get a list of all photos it contains. That would go a long way to alleviate the lack of keywords support in the API.)

iamback

Andy wrote:

Sorry, iamback, I wish I had a better answer for you, but I don't. There is no workaround.

Sigh...

Thanks, Andy. I've been looking at various way to structure it but keep coming back to a need for countries at the top level. I thought of an ugly JavaScript hack (using ISO country codes and dynamically changing them with JS), but of course that would make the result invisible to any search engine bots.

Can you tell me what the reason is for this limitation in category names? I'd like to understand where this comes from.

Andy

iamback wrote:

Can you tell me what the reason is for this limitation in category names? I'd like to understand where this comes from.

I am sorry I cannot. I wish I had a better answer for you.

jfriend

iamback wrote:

I'm a power user and this the first I hear of it. I even see people having it at the top of their wish list and advertising that fact in their signature... I'm not looking for any JavaScript hacks, just a facility on the server to create galleries that have links to photos physically located in other galleries.

How do I use this if it is already possible?

(And it would only be really useful to me if I could query such a virtual gallery from the API to get a list of all photos it contains. That would go a long way to alleviate the lack of keywords support in the API.)

Since I've been a long time proponent of virtual galleries (first posting about it several years ago), I've followed the various work-arounds. The only one I know about is to set up keywords that define a virtual gallery and then use custom HTML somewhere in your interface to launch the keyword search that will display the keyword results that are sort-of like a "virtual gallery". I don't use this myself because my galleries have to be password protected and keywords don't work with password protected galleries, but I think there are some people here using this.

If you search for "virtual keyword" here at dgrin, you will find some description of how people have used this.

I'm not even hinting that this is a substitue for real virtual gallery support that would be easy for all users, but it can be used as a bit of a work-around in some circumstances.

iamback

jfriend wrote:

Since I've been a long time proponent of virtual galleries (first posting about it several years ago)

Hehe, I was a proponent of virtual galleries before I'd even heard of SmugMug. It seems so utterly obvious to me (I even did a logical design for a site of my own based on that idea) that I was simply astonished that SM does not have anything like that. (Zenfolio does, and they have a very nice object model, but in other respects they're far inferior to SM.)

jfriend wrote:

I've followed the various work-arounds. The only one I know about is to set up keywords that define a virtual gallery and then use custom HTML somewhere in your interface to launch the keyword search that will display the keyword results that are sort-of like a "virtual gallery".

Ah yes, that hack. Which of course is going to break for several people using it now that keyword usage suddenly got limited to 15 keywords (though you still can store more and there's some hackability there).

My problem is that - while I really need virtual galleries for their own sake, another thing I need is API keyword support. That not being here, I thought virtual galleries might provide a workaround - if they existed. Which they don't. Obviously a keyword hack for virtual galleries as a replacement for API keyword access isn't going to fly.

<rant>By now (after days of puzzling and trying to figure out workarounds for workarounds) it looks like I'm going to end up with a truly horrible mishmash of PHPserial (my preferred), JSON (when I need JS), parsing XML from feeds :sick and (worst of all) screen scraping :puke, to accomplish the things I have in mind. Doesn't look like an API anymore, if you have to combine (and parse) at least three different data formats to get at the data you need. :bash</rant>

jfriend wrote:

I don't use this myself because my galleries have to be password protected and keywords don't work with password protected galleries, but I think there are some people here using this.

Glad you mention that - half my use of virtual galleries would be private, too.

jfriend wrote:

I'm not even hinting that this is a substitute for real virtual gallery support that would be easy for all users, but it can be used as a bit of a work-around in some circumstances.

True, and thanks for jumping in. Unfortunately not a solution for me, but that's not your fault! Hope it helps someone else.

jfriend

iamback wrote:

Hehe, I was a proponent of virtual galleries before I'd even heard of SmugMug. It seems so utterly obvious to me (I even did a logical design for a site of my own based on that idea) that I was simply astonished that SM does not have anything like that. (Zenfolio does, and they have a very nice object model, but in other respects they're far inferior to SM.)

Ah yes, that hack. Which of course is going to break for several people using it now that keyword usage suddenly got limited to 15 keywords (though you still can store more and there's some hackability there).

My problem is that - while I really need virtual galleries for their own sake, another thing I need is API keyword support. That not being here, I thought virtual galleries might provide a workaround - if they existed. Which they don't. Obviously a keyword hack for virtual galleries as a replacement for API keyword access isn't going to fly.

<rant>By now (after days of puzzling and trying to figure out workarounds for workarounds) it looks like I'm going to end up with a truly horrible mishmash of PHPserial (my preferred), JSON (when I need JS), parsing XML from feeds :sick and (worst of all) screen scraping :puke, to accomplish the things I have in mind. Doesn't look like an API anymore, if you have to combine (and parse) at least three different data formats to get at the data you need. :bash</rant>

Glad you mention that - half my use of virtual galleries would be private, too.

True, and thanks for jumping in. Unfortunately not a solution for me, but that's not your fault! Hope it helps someone else.

Have you asked DevBobo over in the API forum whether it's on his list to add keyword support to the API? While he seems to have responsibility for a bunch of different developer kinds of things and he just did an update to the APIs, he does seem fairly responsive in general. I know that Nik (author of the StarExplorer uploader) just discovered that there were a bunch of capabilities in the API that hadn't made it into the documentation.

iamback

jfriend wrote:

Have you asked DevBobo over in the API forum whether it's on his list to add keyword support to the API? While he seems to have responsibility for a bunch of different developer kinds of things and he just did an update to the APIs, he does seem fairly responsive in general. I know that Nik (author of the StarExplorer uploader) just discovered that there were a bunch of capabilities in the API that hadn't made it into the documentation.

No, or rather not yet. I've seen several responses (including from OneThumb) to the effect that using a keyword feed would be a replacement for the lack of keyword support. The thing is "API keyword support" is too vague a term - it might be a replacement for just one type of query but that's all, and even that is a hack.

So what I'm planning to do is to write up a full spec of what I had expected to see - from the client end - and that's a lot more than "get me all photos that match one keyword" (which is all the keyword feed can do).

PBolchover

jfriend wrote:

The only one I know about is to set up keywords that define a virtual gallery and then use custom HTML somewhere in your interface to launch the keyword search that will display the keyword results that are sort-of like a "virtual gallery".

I would personally use a gallery redirect to display the keyword results, since they will appear in the categories alongside regular galleries.