Here's 2 reasons I love to use embeded html.
Videos
http://www.pubheroes.com/thread.php?thread_id=32
Galleries
http://www.pubheroes.com/thread.php?thread_id=31
Now here's the problem I have with the way the forum currently protects posts. You allow people to enter pretty much anything into the db. Then strip it for disallowed characters just before output. I'd rather you stripped the bad characters and replaced them before input. So you could simply implicitly trust output from DB. This allows one to more easily develop safe methods of storing embeded html data.
That's just my thought.
Videos
http://www.pubheroes.com/thread.php?thread_id=32
Galleries
http://www.pubheroes.com/thread.php?thread_id=31
Now here's the problem I have with the way the forum currently protects posts. You allow people to enter pretty much anything into the db. Then strip it for disallowed characters just before output. I'd rather you stripped the bad characters and replaced them before input. So you could simply implicitly trust output from DB. This allows one to more easily develop safe methods of storing embeded html data.
That's just my thought.
can you explain "This allows one to more easily develop safe methods of storing embeded html data" please?
reasons to format data before inserting it into the database
-> faster, selects don't have to be formatted
-> what you're talking about
reasons to format data after selecting it from the database
-> user input is stored qua user input (no loss of information/data)
-> changes can easily be made to how posts are formatted
one of the goals of ttf is speed, however there is a superseding goal (mission!) of data obsession. i don't want to lose any information.
one thing i might do in the future is to store both raw user input and formatted posts in the database. that way, if a user want to edit the post, it can call the raw data. or if we decide to change formatting dramatically, we can run the new formatting function on the raw data and regenerate the formatted posts. this would maintain speed, because posts would be selected for threads from the formatted post table, so it doesn't have to run this intense function every time a post is displayed.
would having two tables help solve your problem?
reasons to format data before inserting it into the database
-> faster, selects don't have to be formatted
-> what you're talking about
reasons to format data after selecting it from the database
-> user input is stored qua user input (no loss of information/data)
-> changes can easily be made to how posts are formatted
one of the goals of ttf is speed, however there is a superseding goal (mission!) of data obsession. i don't want to lose any information.
one thing i might do in the future is to store both raw user input and formatted posts in the database. that way, if a user want to edit the post, it can call the raw data. or if we decide to change formatting dramatically, we can run the new formatting function on the raw data and regenerate the formatted posts. this would maintain speed, because posts would be selected for threads from the formatted post table, so it doesn't have to run this intense function every time a post is displayed.
would having two tables help solve your problem?
If you have a search replace table... you can simply ensure it is not "lossy".
But if everything ran through output(); is effected by the stringent demands of the user input acls... then you run into problems with possible future feature additions. Maybe you want multiple output functions instead... I don't know.
Just commenting on an issue I've been running into embedding stuff in posts.
But if everything ran through output(); is effected by the stringent demands of the user input acls... then you run into problems with possible future feature additions. Maybe you want multiple output functions instead... I don't know.
Just commenting on an issue I've been running into embedding stuff in posts.
well, how does the current method create problems for you? i don't quite understand
well some of the embed sequences are so complex coming up with exceptions to html search and replace on all output is almost impossible without compromising the value of the function.
which means either I need to use a seperate output function just for special posts containing embed data...
specifically params and some complex embeds are hard to know when they end... so my replace function will usually end up with all > being allowed.
plus allowing any parameters is probably unwise as is allowing any embed sequence... so putting variables in there can get rough.
which means either I need to use a seperate output function just for special posts containing embed data...
specifically params and some complex embeds are hard to know when they end... so my replace function will usually end up with all > being allowed.
plus allowing any parameters is probably unwise as is allowing any embed sequence... so putting variables in there can get rough.
your best off just modifying outputbody() in common.inc.php and making it do what you want with special syntax. i know it's a bitch, but it's probably the best way.
like if you can do a regexp on:
and make it turn into the necessary tags for your simpleviewer.
like if you can do a regexp on:
[slideshow: http://www.hi.com/pic1.jpg , http://www.hi.com/pic2.jpg , http://www.hi.com/pic3.jpg , http://www.hi.com/pic4.jpg ]
and make it turn into the necessary tags for your simpleviewer.