Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Nao
8176
Features / Re: Blogging features
« on August 11th, 2011, 01:44 PM »
As i said: admins only by default. So it's not a problem.
8177
Features / Re: Blogging features
« on August 11th, 2011, 01:21 PM »
Yeah but I'd rather see sites that actually bring traffic than sites that use or abuse XML rpc to spam or just get backlinks.
8178
Features: Posts & Topics / Re: Merge Double Posts
« on August 11th, 2011, 12:40 PM »You could do that with existing merged posts if the merge code has been retained.
True, though it would make the actual process of handling threaded replies a lot more complex overall.
The difference on InnoDB isn't particularly significant.
Yeah, that to me is quite a big con; personally if posts are merged, I'd expect them to be treated as atomic units, i.e. as a single post.
Here are two quickly made mockups.
The first has the same layout as on the blog here. The second shows what it would be with an alternating color. You'd basically get the exact same layout and results as a regular page -- the only thing is that the avatar, user details and signature aren't repeated on each and every post. Which, I think everyone will agree, is the main reason why we hate double posts with a passion... :P
8179
Features: Posts & Topics / Re: Merge Double Posts
« on August 11th, 2011, 12:10 PM »
Hey.
I've been thinking of an alternative way of doing double-post merging... One that might be less disruptive, although needs discussing.
Instead of actually merging posts, we could simply show them together... i.e. if the current post is by the same author as the previous one, we don't 'close' the postbox for the previous message, then we add our message, and we close the postbox, only if the next one is not by the same person. Etc.
We could keep showing buttons for each individual post, meaning we'd show a link, a date and quote/edit etc. buttons on each post inside the pseudo-merged post.
Pros:
- you can easily split posts into new topics, even after they're been pseudo-merged with others...
- you can answer a sub-post and its parent ID will be easily found, i.e. you can track a conversation's parents more easily.
Some cons:
- doesn't fix database space
- can't easily determine if you want to pseudo-merge your posts, it's all automatic. Maybe we could have a 'merge' field in the message table though.
- if someone posts 15 messages in a row, the entire page will be filled by their pseudo-unique post, and then the next one will be on the following page.
The latter is a pro rather than a con, to me. I'm not a big fan of overly long topic pages!
I've been thinking of an alternative way of doing double-post merging... One that might be less disruptive, although needs discussing.
Instead of actually merging posts, we could simply show them together... i.e. if the current post is by the same author as the previous one, we don't 'close' the postbox for the previous message, then we add our message, and we close the postbox, only if the next one is not by the same person. Etc.
We could keep showing buttons for each individual post, meaning we'd show a link, a date and quote/edit etc. buttons on each post inside the pseudo-merged post.
Pros:
- you can easily split posts into new topics, even after they're been pseudo-merged with others...
- you can answer a sub-post and its parent ID will be easily found, i.e. you can track a conversation's parents more easily.
Some cons:
- doesn't fix database space
- can't easily determine if you want to pseudo-merge your posts, it's all automatic. Maybe we could have a 'merge' field in the message table though.
- if someone posts 15 messages in a row, the entire page will be filled by their pseudo-unique post, and then the next one will be on the following page.
The latter is a pro rather than a con, to me. I'm not a big fan of overly long topic pages!
8180
Off-topic / Re: To fork or not to fork - in other words: Hi :)
« on August 11th, 2011, 12:03 PM »JBlaze has in his git account a folder for a SMF fork...
@Pete> Oh, please share the juice about other forks :P
Posted: August 11th, 2011, 12:01 PM
What happens if users add them themselves? (It's in the admin panel, even if it is convoluted.)
When it comes to smileys, the cache is automatically rebuilt when changes are made to the smileys (order, additions, ...)
8181
Off-topic / Re: To fork or not to fork - in other words: Hi :)
« on August 11th, 2011, 10:38 AM »Now convert the post and topic icons into CSS sprites (or something equally efficient) and you might reach 90, but once you don't see any more red or yellow suggestions you can stop. Trying to improve on the green ones is usually not worth the hassle.
Post icons: you mean the action icons...? They're already CSS-compressed. :)
8182
Features / Re: Blogging features
« on August 11th, 2011, 10:35 AM »
I really think we don't need to use XML-RPC for trackbacks... Rather work on the REFERER. That's basically the difference between opt-in and opt-out... :P
8183
Off-topic / Re: An old Friend
« on August 11th, 2011, 07:51 AM »
I'm sorry. I don't believe I remember your nickname...? Where did we talk before?
8184
Features / Re: Blogging features
« on August 11th, 2011, 12:45 AM »
Stop words?
Quote from Nao/Gilles on August 1st, 2011, 04:21 PM And bump.
Posted: August 11th, 2011, 12:44 AM
Bump!Quote from Nao/Gilles on July 25th, 2011, 12:05 AM Also re: beginning of the topic:
- XML-RPC, what's your current opinion on this? Our discussion on trackbacks made me want to implement this without using that protocol. I still think it'd be best to avoid it, but we could 'simply' add it, and allow blog authors to be the only ones allowed to view a trackback.
- Posting from email: did you look into their code, then? Is there any magic behind it?
8185
Off-topic / Re: To fork or not to fork - in other words: Hi :)
« on August 11th, 2011, 12:19 AM »
Welcome to Wedge, Nightwish :)
Hey, following your suggestions on your forum, I became quite obsessed today with getting the best possible PageSpeed number...
So I went ahead and wrote that friggin' smiley CSS cacher!
Heck, it was harder than expected, *and* it doesn't work perfectly yet (post editor is screwed up). But pages show smileys as expected etc.
It really saves a lot. I went from 65 to 85/100 on the online tool (for my topic page), and in the Chrome extension, it jumped to 98/100!!! W-O-W. I think SEO guys are going to like me. And us. :P
Hey, following your suggestions on your forum, I became quite obsessed today with getting the best possible PageSpeed number...
So I went ahead and wrote that friggin' smiley CSS cacher!
Heck, it was harder than expected, *and* it doesn't work perfectly yet (post editor is screwed up). But pages show smileys as expected etc.
It really saves a lot. I went from 65 to 85/100 on the online tool (for my topic page), and in the Chrome extension, it jumped to 98/100!!! W-O-W. I think SEO guys are going to like me. And us. :P
8186
Features / Re: These two bytes may not matter to you...
« on August 10th, 2011, 10:22 PM »
Wondering about the database tables...
I was looking into them, and found an awful lot of INTs (small, tiny, etc.) that are not unsigned, even though they're assigned to things like id_* where you rarely get a negative number (only on a few exceptions.)
Shouldn't we change these to unsigned...? Or whatever?Quote from Arantor on August 7th, 2011, 01:01 PM Yup...
OTOH, maybe files shouldn't get a @version at all, in these conditions. I mean, if we set up a system where users can automatically update their files to the latest version, based on their Wedge version and ours, we don't want them to have files with 'outdated' version numbers. (Of course if we remove the version check, they won't see that in the admin area, but that might still look odd if they open the files manually.)
(Or we just don't care and leave files with their old version numbers.)Quote Hmm... Could be doable.
I was looking into them, and found an awful lot of INTs (small, tiny, etc.) that are not unsigned, even though they're assigned to things like id_* where you rarely get a negative number (only on a few exceptions.)
Shouldn't we change these to unsigned...? Or whatever?
It's only really useful in the core if we provide patches, I think, and if we don't provide patches there's not a lot of value in keeping the complete list of files and versions (or signatures) - not in the core anyway.
OTOH, maybe files shouldn't get a @version at all, in these conditions. I mean, if we set up a system where users can automatically update their files to the latest version, based on their Wedge version and ours, we don't want them to have files with 'outdated' version numbers. (Of course if we remove the version check, they won't see that in the admin area, but that might still look odd if they open the files manually.)
(Or we just don't care and leave files with their old version numbers.)
In fact, could go one step further - as part of an add-on's install if it requires (and is permitted to perform) raw edits, we could do md5 before and after and store that somewhere so that we do have the signature available for testing.
8187
The Pub / [Archive] Re: Logo Madness
« on August 10th, 2011, 06:17 PM »
Hi. Welcome and thank you.
However I'm afraid this tends to break the #1 rule: readability :P
I myself am starting to get fond of the series of logos I built these days so I can't decide between the header logo, the one in my signature and the one in the footer. ;)
However I'm afraid this tends to break the #1 rule: readability :P
I myself am starting to get fond of the series of logos I built these days so I can't decide between the header logo, the one in my signature and the one in the footer. ;)
8188
Features / Re: New revs
« on August 10th, 2011, 06:15 PM »
rev 921
(3 files, 6kb, not a very interesting commit I know...)
* Renamed cache keys to use Wedge instead of SMF. There are going to be a lot of minor renames like this overall... (Subs-Cache.php)
! Category headers could be pushed to the right (e.g. by the menu) when reducing the window width. (index.css)
* Approve button was a bit off, too. (sections.css)
(3 files, 6kb, not a very interesting commit I know...)
* Renamed cache keys to use Wedge instead of SMF. There are going to be a lot of minor renames like this overall... (Subs-Cache.php)
! Category headers could be pushed to the right (e.g. by the menu) when reducing the window width. (index.css)
* Approve button was a bit off, too. (sections.css)
8189
Features / Re: Core/Not Core
« on August 9th, 2011, 06:51 PM »
That's probably true...
Although Facebook & co. mostly borrowed ideas from earlier implementations, too. Social networks have been around since 2000 or so. Forums had time to adjust, at least to match the earlier implementations...
Although Facebook & co. mostly borrowed ideas from earlier implementations, too. Social networks have been around since 2000 or so. Forums had time to adjust, at least to match the earlier implementations...
8190
Features / Re: New revs
« on August 9th, 2011, 04:16 PM »
rev 920
(32 files, 45kb)
* Updated 'div ul.buttonlist' to 'ul.buttonlist'. Saves some space. (index.template.php, index.css, sections.css, topic.js, Media.template.php)
* Updated the button strip visuals to something a tad less gloomy. (sections.css, index.rtl.css, media.css)
* Harmonized and simplified approvebg, stickybg, lockedbg. Also cleaned up half a dozen unused classes. (index.css, sections.css, index.rtl.css, media.css, Wuthering/sections.css, Display.template.php, MessageIndex.template.php, Recent.template.php)
* Harmonized pagesection divs, and turned pagelinks into .pagesection nav. (Aeva-Foxy.php, Aeva-Gallery2.php, Media.language.php, TEMPLATES: Display, GenericList, ManageMedia, ManageMembergroups, Media, Memberlist, MessageIndex, ModerationCenter, PersonalMessage, Profile, Recent, Reminder, Search, SplitTopics, Who)
! Undefined $merge_safe variable in some situations. (Display.php)
! Fixed text colors in viewquery mode. (ViewQuery.php)
- Removed the default 'right' parameter from button strips when still used. (TEMPLATES: BoardIndex, Calendar, PersonalMessage, Recent, Reports)
- References to .align_* classes were left in. (Reminder.template.php)
! SMF bugs: if a topic is stickied and locked, the Search template won't generate the correct class. Also, the template never actually uses it... (Search.template.php)
* Spacinazi. (Profile.template.php, Xml.template.php)
(32 files, 45kb)
* Updated 'div ul.buttonlist' to 'ul.buttonlist'. Saves some space. (index.template.php, index.css, sections.css, topic.js, Media.template.php)
* Updated the button strip visuals to something a tad less gloomy. (sections.css, index.rtl.css, media.css)
* Harmonized and simplified approvebg, stickybg, lockedbg. Also cleaned up half a dozen unused classes. (index.css, sections.css, index.rtl.css, media.css, Wuthering/sections.css, Display.template.php, MessageIndex.template.php, Recent.template.php)
* Harmonized pagesection divs, and turned pagelinks into .pagesection nav. (Aeva-Foxy.php, Aeva-Gallery2.php, Media.language.php, TEMPLATES: Display, GenericList, ManageMedia, ManageMembergroups, Media, Memberlist, MessageIndex, ModerationCenter, PersonalMessage, Profile, Recent, Reminder, Search, SplitTopics, Who)
! Undefined $merge_safe variable in some situations. (Display.php)
! Fixed text colors in viewquery mode. (ViewQuery.php)
- Removed the default 'right' parameter from button strips when still used. (TEMPLATES: BoardIndex, Calendar, PersonalMessage, Recent, Reports)
- References to .align_* classes were left in. (Reminder.template.php)
! SMF bugs: if a topic is stickied and locked, the Search template won't generate the correct class. Also, the template never actually uses it... (Search.template.php)
* Spacinazi. (Profile.template.php, Xml.template.php)