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
6316
Off-topic / Re: New here!
« on February 26th, 2012, 04:57 PM »
I think it should be an Anti-Spam page feature.
How many posts before we start showing everything for the user -- website link, signature, etc.
And possibly, choose what you want to show exactly. But it'd make it more complex.
How many posts before we start showing everything for the user -- website link, signature, etc.
And possibly, choose what you want to show exactly. But it'd make it more complex.
6317
Features / Re: New revs
« on February 26th, 2012, 01:40 PM »
rev 1385
(3 files, 1kb)
* Replaced the one @remove with @replace in Warm, and moved it to the end, to make it more prominent as a simple example of CSS replacements. Did the same for Wuthering, and also moved the one remaining @remove to the end. (Warm/index.css, Wuthering/index.css)
* Turning that h6 header into my current font of choice -- if only to keep the number of different fonts used to a minimum. The fallback is still acceptable, although I had to settle for less weight. (index.css)
(3 files, 1kb)
* Replaced the one @remove with @replace in Warm, and moved it to the end, to make it more prominent as a simple example of CSS replacements. Did the same for Wuthering, and also moved the one remaining @remove to the end. (Warm/index.css, Wuthering/index.css)
* Turning that h6 header into my current font of choice -- if only to keep the number of different fonts used to a minimum. The fallback is still acceptable, although I had to settle for less weight. (index.css)
6318
Features / Re: New revs
« on February 26th, 2012, 01:26 PM »
rev 1384
(5 files +1, 4kb)
* Moved thought.png to the image attic, and replaced it with a much smaller thought.gif. I challenge anyone to spot the difference at first sight. (thought.png, thought.gif, index.member.css)
+ Added query_see_topic to Feed, SendTopic and SplitTopics. (Feed.php, SendTopic.php, SendTopic.php -- didn't I just say that?)
! The CSS parser incorrectly added an extra slash to $root paths. (Subs-Cache.php)
(5 files +1, 4kb)
* Moved thought.png to the image attic, and replaced it with a much smaller thought.gif. I challenge anyone to spot the difference at first sight. (thought.png, thought.gif, index.member.css)
+ Added query_see_topic to Feed, SendTopic and SplitTopics. (Feed.php, SendTopic.php, SendTopic.php -- didn't I just say that?)
! The CSS parser incorrectly added an extra slash to $root paths. (Subs-Cache.php)
6319
Features / Re: Privacy options
« on February 26th, 2012, 01:19 PM »
I have this fear all of a sudden... If t.approved=0, then m.approved=0 where m.id_msg=t.id_first_msg...
Which means that if you do a m.approved=1 test on any query, it WILL correctly ignore unapproved topics...
As a result, I think that there's a big problem with query_see_topic, in that it can and will only be called on queries that have a topics table in them, and if there's no need to access the topics table to see if it's actually approved... It means we have to add inner joins on every single friggin' table.
Hopefully, I'm wrong.......?
(Bump for this last post. And a friendly reminder for the one above, but it can wait a bit longer :P)
Which means that if you do a m.approved=1 test on any query, it WILL correctly ignore unapproved topics...
As a result, I think that there's a big problem with query_see_topic, in that it can and will only be called on queries that have a topics table in them, and if there's no need to access the topics table to see if it's actually approved... It means we have to add inner joins on every single friggin' table.
Hopefully, I'm wrong.......?
Posted: February 26th, 2012, 03:16 AM
(Bump for this last post. And a friendly reminder for the one above, but it can wait a bit longer :P)
6320
Off-topic / Re: Introduction
« on February 26th, 2012, 10:01 AM »Hi guys, I'm Klokinator. I'm actually a friend of Norodo's and I run one of his sites, soon to be two. He keeps telling me how awesome this Wedge is and how he'll be implementing it into his other sites once it's released, so by damn I'm gonna come onto the only site that has it and test out the features of it xD
(This site IS run on Wedge right? Beause if not, I'd be a little disappointed)
But you're in at the right time. I promised I'd use Wedge on wedge.org once we'd reach 200 friends on FB (as good as any other promise really :P), I released the first screenshots at 100 friends, so here we are... We passed 200 friends yesterday and I promised myself to use Wedge here by the end of the month, so it's very likely that it'll happen on March 1st. (It's symbolic more than anything, but it's my 'Internet use birthday' date. My online persona will turn 16.)
So... Whether it's ready or not!
Wedge! Used here! Right here! Starting Thursday, March 1st! Stay tuned!
6321
Off-topic / Re: New here!
« on February 26th, 2012, 09:56 AM »
Definitely a spammer, BTW - he edited his signature with a spam link yesterday.
Little did he know that Wedge/Noisen won't show signatures before he posts at least a bit... :P
Hmm, where do I set this up in Wedge already, BTW...? :lol:
Little did he know that Wedge/Noisen won't show signatures before he posts at least a bit... :P
Hmm, where do I set this up in Wedge already, BTW...? :lol:
6322
The Pub / Re: Trying something a bit new
« on February 25th, 2012, 06:15 PM »I like the idea of the regex but I suspect it's going to be a bit much for themers. Heck, regex is beyond most mod authors too.
If I provide an example for a simple div replacement, then it should be alright. Maybe I could even document it in comments, or something. Coming up with a recursive regex is hard. Adapting it to other tag types is easy.
Regarding @replace, what are the benefits and problems with doing it before parsing and what are the benefits/problems to doing it after?
Pre-parsing, I don't know. The main issue with doing it at the same time as @remove is that it does add a bit more processing time compared to pre or post parsing. That's really the only thing... I'd like to move @remove to pre-processing, but technically it's not doable, because if you remove an entry and its selector only had that entry, you end up with an empty selector entry which usually means parsing problems in WeCSS...
Posted: February 25th, 2012, 05:52 PM
In the end I went for the pre-parsing way. Works perfectly, and its only costs a preg_match_all. (I could make it a bit faster though, by preventing @remove from having tabs or spaces before it.)
6323
Features / Re: New revs
« on February 25th, 2012, 06:13 PM »
rev 1383
(1 file, 1kb)
+ Added support for a new WeCSS command, @replace. It acts pretty much the same way as @remove, except that it requires a third line for a replacement string, and it can accept partial strings such as url($images/something.png) (if you want to replace it with an image of your own), instead of a full line to remove. Tested on a few strings, works perfectly. (Class-CSS.php)
(1 file, 1kb)
+ Added support for a new WeCSS command, @replace. It acts pretty much the same way as @remove, except that it requires a third line for a replacement string, and it can accept partial strings such as url($images/something.png) (if you want to replace it with an image of your own), instead of a full line to remove. Tested on a few strings, works perfectly. (Class-CSS.php)
6324
The Pub / Re: Wap is that?
« on February 25th, 2012, 05:48 PM »
A few years ago, Wap was already next to nothing compared to Wap2.
But still, I'm not re-introducing Wap2 support anytime soon... :P
But still, I'm not re-introducing Wap2 support anytime soon... :P
6325
Features / Re: Going backwards to go forwards (aka dealing with an inheritance)
« on February 25th, 2012, 05:47 PM »
Well, as long as this remains in the Boards template, I have no problem with adding some extra tags.
Never been a fan of tbodies and theads though, personally...
Never been a fan of tbodies and theads though, personally...
6326
Features / Re: Going backwards to go forwards (aka dealing with an inheritance)
« on February 25th, 2012, 03:36 PM »
Any reasons to reproduce them exactly?
6327
Features / Re: How about PMs being listed in Core Features?
« on February 25th, 2012, 08:23 AM »
Yes.
6328
The Pub / Re: Trying something a bit new
« on February 25th, 2012, 12:39 AM »
So... I've been thinking about it a bit more... Couldn't find a perfect solution. Right now the best realistic code I have is this:
Code: [Select]
If <from> is used, a simple replace is done. Otherwise, Wedge would build a recursive regex out of <from-end>, or it would simply step through the code until it meets an unmatched closer, which has my preference these days (it's probably not faster, but at least it's not subject to any security problems.)
Maybe use from-opener and to-closer etc instead of start and end, although it'd imply we only support one tag in these, when there could be more. Or perhaps it could be made simpler for skinners...
Code: [Select]
Replacing a "node" would look into the HTML in 'from', extract the tag name, and look for the closer. Then it would replace the opener normally, and would replace the closer with the tag extracted from the 'to' entry.
That one, obviously, would require having only one tag.
Finally, there's also the possibility of giving freedom to skinners, but they'd also need to learn regex...
Code: [Select]
Would obviously require that skinners know how to encode the request for preg_replace. *And* know how to do a recursive regex... (I suppose I could provide one for inspiration. But it would still require work on their side...)
BTW, I also have in my to-do-list a @replace command for WeCSS... Although it's a bit on the backburner for now, because I'm not sure where best to implement -- in the same way as my @remove code, possibly, although it might be smarter to do it either before the parsing, or after the processing.
<replace>
<from-start><aside id="sidebar"></from-start>
<from-end></aside></from-end>
<to-start><div id="sidebar"></to-start>
<to-end></div></to-end>
</replace>If <from> is used, a simple replace is done. Otherwise, Wedge would build a recursive regex out of <from-end>, or it would simply step through the code until it meets an unmatched closer, which has my preference these days (it's probably not faster, but at least it's not subject to any security problems.)
Maybe use from-opener and to-closer etc instead of start and end, although it'd imply we only support one tag in these, when there could be more. Or perhaps it could be made simpler for skinners...
<replacenode>
<from><aside id="sidebar"></from>
<to><div id="sidebar"></to>
</replacenode>Replacing a "node" would look into the HTML in 'from', extract the tag name, and look for the closer. Then it would replace the opener normally, and would replace the closer with the tag extracted from the 'to' entry.
That one, obviously, would require having only one tag.
Finally, there's also the possibility of giving freedom to skinners, but they'd also need to learn regex...
<replace>
<from-regex><aside id="sidebar">(.*?)</aside></from-regex>
<to><div id="sidebar">$1</div></to>
</replace>Would obviously require that skinners know how to encode the request for preg_replace. *And* know how to do a recursive regex... (I suppose I could provide one for inspiration. But it would still require work on their side...)
Posted: February 25th, 2012, 12:38 AM
BTW, I also have in my to-do-list a @replace command for WeCSS... Although it's a bit on the backburner for now, because I'm not sure where best to implement -- in the same way as my @remove code, possibly, although it might be smarter to do it either before the parsing, or after the processing.
6329
The Pub / Re: Trying something a bit new
« on February 24th, 2012, 08:31 PM »
<from><div I'd="sidebar">{match}</div></from>
If match is met in the request, and is followed by a closer, turn it into a regex with recursively. Can be done. Just doesn't feel very natural.
<to><i >{match}</i></to>
I hate the iPod when it comes to typing HTML in...
If match is met in the request, and is followed by a closer, turn it into a regex with recursively. Can be done. Just doesn't feel very natural.
<to><i >{match}</i></to>
I hate the iPod when it comes to typing HTML in...
6330
Other software / Re: Finally, they've made an announcement
« on February 24th, 2012, 08:25 PM »
So basically it's just.... Like v2.0!?