Note: feel free to change the error message and general description stuff.
All the rss icons are feed uri's and can be added to your feedreader of choice. since they are generated per the user's read-rights, there won't be any wrong uri (per se).
But in the event that a user starts playing with the link, they'll get the following error message (configure as you wish in - language file)
I've included the general links as well:
1. PM inbox messages 2. Active topics 3. Active posts
Works outta the box for both 7.1 and 7.2 and fits with the standard structure: scripts, templates, language.
Enjoy!
ps: i added 3 < div id="xxx" > around the major chunks of the html side of the template, so you css'ers can go crazy with some fancy smanchy stuff. for those who don't know or care about it, the divs will be transparent anyway
It wanted full URLs? that's stupid... I have 5 domains for my site, and all have to work independantly; not to mention have to support SSL; so that's 10 domains that would have to work independant... so if a user was blocking (well, if their isp was) my main url, they can usually get in via my ssl, but if it was hardcoded all urls then i'd be sol lol...
the url is relative in the description, but when shown and you'd right click on it, you get full url.
it's just that the w3c validator wanted it to be full in the description to start with.
smileys as they are now are relative anyway. %%GRAEMLIN..%% is replaced by a relative URL (style array path) for display. you'd have uber-probs, if that didn't work.
no biggie
just add '$config[FULL_URL]' and poof done.
i ran into this same issue, when i was coding up the 'Email Thread' mod. All smileys puked (at first) in the received Html Email
by setting it to http host it reads the domain it's being accessed as; so you can set it to allow posts from any domain (as some portions will set you as the domain set in the forums); and the ssl stuff is a nessessity to bypass some more-stupid site filters
dude, you completed missed my point (or we are just off on some tangent not related) of why it's recommended for full urls in description or in an email and why w3c flagged it.
example: for smileys, the non-full url is '/images/graemlins/default/smile.gif'
that works well and good, if that url is on the site itself, but blows up in an email where it's NOT being read from the site itself.
example (i copied raw html from my initial post in this topic where i have the wink smiley):
Code
ps: i added 3 < div id="xxx" > around the major chunks of the html side of the template, so you css'ers can go crazy with some fancy smanchy stuff. for those who don't know or care about it, the divs will be transparent anyway <img src="/forums/images/graemlins/default/wink.gif" alt=";\)" title="wink" height="15" width="15">
assume i email that to myself and then try to read it ... dead smiley link
what you end up in an email is broken links for every smiley and where i didn't notice it in the feed was ok. and the feed will be ok with relative urls, but still not a w3c recommended practice. emails are prime example, where it just plain blows up.
so bottom line is w3c makes sense and the fix was a minor one to be in compliance.
no need for redir or whatever hokus pokus to fix this problem. i just needed to do it right in the first place and thank god for feed validators as well as the other ones.
Donate to UBBDev today to help aid in Operational, Server and Script Maintenance, and Development costs.
Please also see our parent organization VNC Web Services if you're in the need of a new UBB.threads Install or Upgrade, Site/Server Migrations, or Security and Coding Services.