flatpress-devel — FlatPress Development ML

[fp-dev] [Pre-Release] 0.612-RC1 out!

[NoWhereMan <now...@fl...>]

What's new:

[NEW] PLUGIN: akismet antispam
[NEW] PLUGIN: qspam quickantispam
[NEW] PLUGIN: prettyurls adds search engine optimized urls (e.g.
entryNNNNNN-NNNNNN.html instead of index.php?entry=entryNNNNNN-NNNNNN)
[NEW] PLUGIN: calendar, adminarea, categories Italian translation (still old
old dir organization)
[NEW] SETUP: Less questions when reinstalling
[EXP] You can now choose index.php to display a page different from blog
(experimental not fully implemented, some links may be broken): open
defaults.php and change the INDEX constant to anything you want (defaults to
blog.php)
[FIX] CORE: Wrong order of comments
[FIX] PLUGIN: archives: Wrong order of months
[FIX] PLUGIN: bbcode: standard javascript popup displayed images with same
proportions of scaled thumbnails

Many plugins are now disabled by default when installing, this is because FP
may look otherwise a bit slow; in particular many plugins are javascript
related; I mean here lightbox and jsutils. Without these plugins you'll
loose some of the eye-candy and usability-related features, so I recommend
to have them enabled even though this way FP is a little slower; in the next
versions I'll release two new, lighter plugins which will deprecated both
jsutils and lightbox.

bye

http://www.nowhereland.it/downloads/flatpress.0.612RC-1.tar.bz2 

Re: [fp-dev] [Plugin] QuickSpamFilter

[NoWhereMan <now...@fl...>]

----- Original Message ----- 
From: "Naoki Hiroshima" <n...@h7...>
To: <fla...@li...>
Sent: Monday, December 18, 2006 11:47 PM
Subject: Re: [fp-dev] [Plugin] QuickSpamFilter


> How about using hashcash?  Pivot took the idea from WP-hashcash and
> seems working great.  In fact, I have not been having any comment spam
> for long time with this plugin.
> 
> Requiring javascript may sound overkill but it really works to prevent
> from being spamed.

I may have a look at that too.
in the meantime I made work akismet
see http://flatpress.nowhereland.it 

Re: [fp-dev] [Plugin] QuickSpamFilter

[Naoki H. <n...@h7...>]

How about using hashcash?  Pivot took the idea from WP-hashcash and
seems working great.  In fact, I have not been having any comment spam
for long time with this plugin.

Requiring javascript may sound overkill but it really works to prevent
from being spamed.

Thanks,
-- Hiroshima

On 12/18/06, NoWhereMan <now...@fl...> wrote:
> situation is now even more allarming :/
> the code is not enough to keep'em out and I can hardly think of a quick fix
> to help us againts this spam attack; I'm calling you for help Hiroshima :D
>
> they already are using the www field of the comment form to leaforg the
> filter...
> have you got any idea?
>
> bye
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> FlatPress-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flatpress-devel
>

Re: [fp-dev] [Plugin] QuickSpamFilter

[NoWhereMan <now...@fl...>]

situation is now even more allarming :/
the code is not enough to keep'em out and I can hardly think of a quick fix 
to help us againts this spam attack; I'm calling you for help Hiroshima :D

they already are using the www field of the comment form to leaforg the 
filter...
have you got any idea?

bye

Re: [fp-dev] [Plugin] QuickSpamFilter

[NoWhereMan <now...@fl...>]

Sorry It got messed while sending :p
here it is:

-----
As spam is reaching allarming proportions even on FlatPress (it was a matter 
of time :'( ) I must create a plugin that can filter all the crap, blocking 
it. Now, as I don't have time to write something enough "strong", I must 
create something quick, dirty and - I hope - still effective enough.
It's quite weak, but I hope it will last at least for little while.
Blog spammers are always adding html or bbcode-like tags to be sure that 
their links are really clickable (so that search engines will index them). 
If you won't never add links in your comments using html or bbcode (as they 
are anyway converted to a clickable link) ALL the comments containing the 
words "href" or "[url" will be BLOCKED.

The list of banned words can be easily customized so that you could add 
other words... in the meantime I hope this HACK is enough :/

I'm sure it won't last a lot; while they're thinking about it (hoping they 
aren't reading this blog :'( ), I hope we'll block a bunch of that crap.

You can find it here:
http://www.nowhereland.it/misc/plugin.qspam.php.txt

remove ".txt" from the name, upload it to fp-plugins/ e and add 'qspam' to 
your plugin panel. Let's hope...

:/

 http://flatpress.nowhereland.it/flatpress/index.php?entry=entry061212-172915 if you want to improve it feel free. Keep in mind it is not meant tobe "huge" or nothing more than a hack; If I wanted to have a "great"antispam I would have use at least regex's and a whole bunch ofspam-wordsShare your thoughts--------------------Bye--ev

[fp-dev] [Plugin] QuickSpamFilter

[NoWhereMan <now...@fl...>]

As spam is reaching allarming proportions even on FlatPress (it was a matter 
of time :'( ) I must create a plugin that can filter all the crap, blocking 
it. Now, as I don't have time to write something enough "strong", I must 
create something quick, dirty and - I hope - still effective enough.
It's quite weak, but I hope it will last at least for little while.
Blog spammers are always adding html or bbcode-like tags to be sure that 
their links are really clickable (so that search engines will index them). 
If you won't never add links in your comments using html or bbcode (as they 
are anyway converted to a clickable link) ALL the comments containing the 
words href or

http://www.nowhereland.it/misc/plugin.qspam.php.txt

remove ".txt" from the name, upload it to fp-plugins/ e and add 'qspam' to 
your plugin panel. Let's hope...
:/

http://flatpress.nowhereland.it/flatpress/index.php?entry=entry061212-172915

if you want to improve it feel free. Keep in mind it is not meant to be 
"huge" or nothing more than a hack; If I wanted to have a "great" antispam I 
would have use at least regex's and a whole bunch of spam-words

Share your thoughts

bye


--ev 

Re: [fp-dev] Fwd: FlatPress

[NoWhereMan <now...@fl...>]

>> ---------- Forwarded message ----------
>> From: Tari Akpodiete <tar...@gm...>
>> Date: 24-nov-2006 8.37
>> Subject: FlatPress
>> To: sa...@gm...
>>
>>
>> greetings Samy:
>>
>> oh, i have already emailed the FlatPress link to several SPHPB-using
>> friends. one of them - http://www.cyberware.ca - made a great gallery
>> plug-in, and i got him to adapt it to work with LightBox JS. it's
>> only implemented on some of his gallery pages right now, for example
>> - http://www.cyberware.ca/blog/gallery.php?_cat=people - and it's a
>> work in progress, but i bet it would work on FlatPress too!

Hi Tari,

Welcome to FP ^_^


>> i would like to suggest the incorporation of a REAL editor, for
>> example, the very robust and free Tiny MCE -
>> http://tinymce.moxiecode.com/ - pppBlog (which mixes SPHPblog and
>> TFTgallery together) - http://tiedemann.ifastnet.com/pppblog/ -has
>> put in FCKeditor - http://www.fckeditor.net - but one can choose to
>> use the regular editor or the enhanced one.


Yes, I'm already working on this. The problem at the moment is that pppBlog 
just wraps the output (xhtml) of these cool WYSIWYG editors into 
[html][/html] tags; this tag, while handy, still forces the conversion of 
special html chars such as <, >, & into entities (then out into the entry 
txt), which are then reconverted back into normal char while parsing and 
doing output. As you can understand this is a behaviour that could be 
accepted for a few lines of html, while it is IMO a real waste of CPU time 
if becomes the *rule*, so [html] tags everywhere, always.
What I'm currently working on is adding a special field, fp-proprietary, 
called MARKUP, where FP will save infos about the markup plugin which is in 
use currently. Old versions will default to bbcode, to retain compatibility, 
while new ones will let you choose. Unfortunately I still have to fix some 
problem with entities, but it is already "in the pipeline" ;)
Once done, you could choose to use an XHTML markup, and eventually the 
beloved TinyMCE or FCKeditor :)

>>
>> also, it would be GREAT to have links that use words rather than a
>> combo of nonsensical characters and numbers. for example:
>>
>> http://www.reallygoodfriend.com/steve-irwin-has-died/
>>
>> instead of
>>
>> http://www.reallygoodfriend.com/index.php?entry=entry060904-041522
>>
>> and real permalinks.


This is something which should be discussed. using the "nonsensical" chars, 
give us the freedom to point directly to the entry file, and so we avoid 
searching for the title through our index (we use a cached index for titles, 
categories, and entry IDs). I could maybe hash the titles, but then I should 
add a further field to the cache, which is already big in my opinion...

>> it is nice to hear how themes can be made in what seems like a
>> simpler fashion. i was actually planning on developing some themes
>> for SPHPB. i suppose that there will soon be a tutorial on how to do
>> so for FlatPress, and i'm looking forward to that. maybe you can
>> also make a tutorial on how to port themes from other blogging
>> systems.

I guess this could be a work for Hydra :p she's good at converting themes, 
now :)

>> one thing i find very frustrating about SPHPB is that there is ZERO
>> documentation, so it is hard to look things up when there is a
>> question.

Yes, I do understand you. I would *love* writing docs; seriously, I like to 
write. But time is soooo little :(

>> already, i see some things explained on -
>> http://flatpress.nowhereland.it -
>> so that is encouraging. i'm a writer, and i'd be glad to contribute
>> in that
>> area if i can, once i learn more, of course.

How could I refuse?? :D
For me, you're in :P

[fp-dev] Fwd: FlatPress

[NoWhereMan <now...@fl...>]

CCing to list.


> ---------- Forwarded message ----------
> From: Tari Akpodiete <tar...@gm...>
> Date: 24-nov-2006 8.37
> Subject: FlatPress
> To: sa...@gm...
>
>
> greetings Samy:
>
> oh, i have already emailed the FlatPress link to several SPHPB-using
> friends. one of them - http://www.cyberware.ca - made a great gallery
> plug-in, and i got him to adapt it to work with LightBox JS. it's only
> implemented on some of his gallery pages right now, for example -
> http://www.cyberware.ca/blog/gallery.php?_cat=people - and it's a
> work in progress, but i bet it would work on FlatPress too!
>
> i would like to suggest the incorporation of a REAL editor, for
> example, the very robust and free Tiny MCE -
> http://tinymce.moxiecode.com/ - pppBlog (which mixes SPHPblog and
> TFTgallery together) - http://tiedemann.ifastnet.com/pppblog/ -has
> put in FCKeditor - http://www.fckeditor.net - but one can choose to
> use the regular editor or the enhanced one.
>
> also, it would be GREAT to have links that use words rather than a
> combo of nonsensical characters and numbers. for example:
>
> http://www.reallygoodfriend.com/steve-irwin-has-died/
>
> instead of
>
> http://www.reallygoodfriend.com/index.php?entry=entry060904-041522
>
> and real permalinks.
>
> kind regards.

> thanks for getting back to me.
>
> i did not know you were a girl. i am also female. and i am here in Canada.
>
> anyway, i do know HTML, XHTML, CSS, some JavaScript and XML, and a bit of
> PHP. i had also been picking up some MySQL too, because of WordPress which 
> i
> also like, although for my personal blog, i am not using it.
>
> i am not 100% sure how to add a third column. if you could explain, i 
> would
> be very grateful.
>
> THANK YOU VERY MUCH for showing me FlatPress!!!
>
> it's very exciting. are you working on it with NoWhereMan? it looks quite
> interesting. it has bothered me a bit that SPHPB has W3C validation
> problems. i am most wanting to know how to take my SPHPB content and put 
> it
> into FP. i was reading the FAQ on that. i see little graphics beside post
> titles. nice touch. great logo too! anyway, I have just subscribed to the
> mailing list.
>
> it is nice to hear how themes can be made in what seems like a simpler
> fashion. i was actually planning on developing some themes for SPHPB. i
> suppose that there will soon be a tutorial on how to do so for FlatPress,
> and i'm looking forward to that. maybe you can also make a tutorial on how
> to port themes from other blogging systems.
>
> one thing i find very frustrating about SPHPB is that there is ZERO
> documentation, so it is hard to look things up when there is a question. i
> mean, it's difficult to do stuff when you don't know what a particular php
> page is for. and when there is little commenting, well, it's not easy. 
> sure
> the people who made the system know what everything is for, but for people
> who want to teach themselves, well, it could be better documented.
>
> already, i see some things explained on - 
> http://flatpress.nowhereland.it -
> so that is encouraging. i'm a writer, and i'd be glad to contribute in 
> that
> area if i can, once i learn more, of course.
>
>

Re: [fp-dev] [PATCH] proper use of htmlentities

[NoWhereMan <now...@fl...>]

----- Original Message ----- 
From: "Naoki Hiroshima"

> NoWhereMan wrote:
[escaping with entities]
>> it looks like a way to unescape sequences of entities... something like
>> that...
>> if it finds &entity; it won't change it into &entity; maybe... :P
>
> I see...  Besides, today's WP seems to be using:
>
> $text = str_replace('&&', '&&', $text);
> $text = str_replace('&&', '&&', $text);
> $text = preg_replace('/&(?:$|([^#])(?![a-z1-4]{1,8};))/', '&$1',
> $text);

Code was from 1.5; probably they changed it in 2.0... ok maybe we could sync 
some of the code

[explicit accept-charset in forms]
> The thing is, browsers don't have to send a message in the same encoding
> of the page.  This used to be a typical problem in Japanese since even
> if the page encoding is "euc-jp", some of browsers can send a message in
> "sjis".  Maybe there is no issue nowadays but specifying explicitly is
> better, I suppose.

Oh, I see.

> I don't say there is no reason but I can't think of any compelling
> reason why someone really wants to use something other than UTF-8 unless
> it's UTF-16.

The only reason is retaining native compatibility with SPB which uses 
different encodings depending on your language, but I would really drop full 
compatibility. Files for the Italian language are already utf encoded (not 
ASCII!) so if you use an encoding other than UTF, accents will result in 
strange characters.

Maybe I could make the installer detect if the fp-content/content/ is not 
empty and ask immediatly if you want to perform a conversion, but the 
problem is that I can't guess the actual encoding of the files. I tried with 
all the mb_* function series but it looked like it didn't guess anything :(

Moreover I fear server timeouts, and I wouldn't want it to stop in the 
middle of a conversion, which would lead you to do a re-conversion next time 
you'll launch setup, and so mess with everything: it would try 
double-converting to utf-8, treating the already-converted TXTs as european 
ISO. I'll let you imagine what would happen.

bye

Re: [fp-dev] [PATCH] proper use of htmlentities

[Naoki H. <n...@h7...>]

NoWhereMan wrote:
> it looks like a way to unescape sequences of entities... something like 
> that...
> if it finds &entity; it won't change it into &entity; maybe... :P

I see...  Besides, today's WP seems to be using:

$text = str_replace('&&', '&&', $text);
$text = str_replace('&&', '&&', $text);
$text = preg_replace('/&(?:$|([^#])(?![a-z1-4]{1,8};))/', '&$1', 
$text);


>> I was using xemacs when I used to work on Windows :-)
> 
> cool, let's start a flamewar about vim (I use vim) :D

Okay, vim sucks, emacs rules!!  heheh.

Actually, I always use vim only when I am working as "root" because it 
forces me to be really cautious  ;-)


>> $ find . \( -name "*.php" -o -name "*.tpl" \) | xargs perl -pi -e
>> 's/<form /<form accept-charset="utf-8" /'
> 
> Is this really needed? I thought it would have better if the user agents 
> could figure it out theirselves from the page encoding. BTW if we really 
> drop other encs for utf... :/
> I'm not sure...

The thing is, browsers don't have to send a message in the same encoding 
of the page.  This used to be a typical problem in Japanese since even 
if the page encoding is "euc-jp", some of browsers can send a message in 
"sjis".  Maybe there is no issue nowadays but specifying explicitly is 
better, I suppose.

In terms of dropping other encodings, I am sure that it just makes more 
of people's life much easier than otherwise.

I don't say there is no reason but I can't think of any compelling 
reason why someone really wants to use something other than UTF-8 unless 
it's UTF-16.

Thanks,
-- Hiroshima

Re: [fp-dev] [PATCH] proper use of htmlentities

[NoWhereMan <now...@fl...>]

----- Original Message ----- 
From: "Naoki Hiroshima" <n...@h7...>

> NoWhereMan wrote:
>> wp_specialchars() work better?

> Ah, I didn't realize this function.  Yes, this works better.  But I have
> a question.  What is the below for?
>
>   $text = preg_replace('/&([^#])(?![a-z12]{1,8};)/', '&#038;$1', $text);

it looks like a way to unescape sequences of entities... something like 
that...
if it finds &entity; it won't change it into &amp;entity; maybe... :P

so the whole code for that func should be ok...

>> The reason for this mess is an horrible horrible editor on Windows (which
>> once I used to love, SciTE) which was supposed to handle correctly line
>> ends.
>
> I was using xemacs when I used to work on Windows :-)

cool, let's start a flamewar about vim (I use vim) :D

> Another oneliner I would like to suggest is:
>
> $ find . \( -name "*.php" -o -name "*.tpl" \) | xargs perl -pi -e
> 's/<form /<form accept-charset="utf-8" /'

Is this really needed? I thought it would have better if the user agents 
could figure it out theirselves from the page encoding. BTW if we really 
drop other encs for utf... :/
I'm not sure...

bye

Re: [fp-dev] [PATCH] proper use of htmlentities

[Naoki H. <n...@h7...>]

NoWhereMan wrote:
> I've been thinking about this issue today. As we finally are supporting 
> utf-8 (I would like to just not to support the others...), would 

Absolutely.  What on earth can be wrong with UTF-8 unless you want to 
discriminate many of languages?

I think I really like you to officially decide not to support anything 
but UTF-8 in order to make many people's life tremendously easier ;-)


> wp_specialchars() work better? you can find it in 
> fp-includes/core/core.wp-formatting.php
> I guess it would be even better than the PHP original, as it should do less 
> checks. What do you think?

Ah, I didn't realize this function.  Yes, this works better.  But I have 
a question.  What is the below for?

   $text = preg_replace('/&([^#])(?![a-z12]{1,8};)/', '&$1', $text);


Come to think of it, I think we don't have to worry about anything but 5 
characters in UTF-8 world and 1 character in FP world as below:

   $text = str_replace('|', '|', $text); // just for FP format
   $text = str_replace('&', '&', $text);
   $text = str_replace('<', '&lt;', $text);
   $text = str_replace('>', '&gt;', $text);
   if ($quotes) {
     $text = str_replace('"', '&quot;', $text);
     $text = str_replace("'", '&apos;', $text);
   }

All of other characters can be simply represented directly in UTF-8.


>>> By the way, I found that many of files are pretty mess with CRLF and
>>>  LF. I am not sure what you are using (probably Windows, eh?) and
>>> how this
>>> mess happened.  Having LF lines and CRLF lines in a file is little
>>> bothersome  :-(
> 
> The reason for this mess is an horrible horrible editor on Windows (which
> once I used to love, SciTE) which was supposed to handle correctly line 
> ends.

I was using xemacs when I used to work on Windows :-)

I have switched to OSX about a month ago and I am free from those 
Windows crap.... NOT :-(  Occasionally I need to run Windows in 
Parallels and deal with it.


> but that in fact it doesn't :/ Usually I work on Linux, but ATM I'm working 
> with Windows... thank you for the per oneliner. I've got cygwin here, so I 
> gave a a dos2unix on all of them. I didn't think about xargs... sometimes I 
> just forget the basics :D

Another oneliner I would like to suggest is:

$ find . \( -name "*.php" -o -name "*.tpl" \) | xargs perl -pi -e 
's/<form /<form accept-charset="utf-8" /'


Thanks,
-- Hiroshima

Re: [fp-dev] [PATCH] proper use of htmlentities

[NoWhereMan <now...@fl...>]

Naoki Hiroshima wrote:
>> Hello,
>>
>> Current version (0.611) has a chance to garble comment author's name
>> because of incorrect use of htmlentities().  For example, if I filled
>> out my name in Japanese, it never got through as it was and ended up
>> showing garbled characters.  So, this patch is essential for
>> languages other than ISO-8859-1.

Oh! Great. Thank you.
I've been thinking about this issue today. As we finally are supporting 
utf-8 (I would like to just not to support the others...), would 
wp_specialchars() work better? you can find it in 
fp-includes/core/core.wp-formatting.php
I guess it would be even better than the PHP original, as it should do less 
checks. What do you think?

>> By the way, I found that many of files are pretty mess with CRLF and
>>  LF. I am not sure what you are using (probably Windows, eh?) and
>> how this
>> mess happened.  Having LF lines and CRLF lines in a file is little
>> bothersome  :-(

The reason for this mess is an horrible horrible editor on Windows (which
once I used to love, SciTE) which was supposed to handle correctly line 
ends.
but that in fact it doesn't :/ Usually I work on Linux, but ATM I'm working 
with Windows... thank you for the per oneliner. I've got cygwin here, so I 
gave a a dos2unix on all of them. I didn't think about xargs... sometimes I 
just forget the basics :D

>> Thanks,

Thank *you* :)

[fp-dev] [PATCH] proper use of htmlentities

[Naoki H. <n...@h7...>]

Hello,

Current version (0.611) has a chance to garble comment author's name 
because of incorrect use of htmlentities().  For example, if I filled 
out my name in Japanese, it never got through as it was and ended up 
showing garbled characters.  So, this patch is essential for languages 
other than ISO-8859-1.

By the way, I found that many of files are pretty mess with CRLF and LF. 
  I am not sure what you are using (probably Windows, eh?) and how this 
mess happened.  Having LF lines and CRLF lines in a file is little 
bothersome  :-(

As you may know, you can remove all CR by the following command if you 
have those commands:

   $ find . -name "*.php" | xargs perl -pi -e 's/^M//'

I did this to my working files but better applied to original files.

Thanks,
-- Hiroshima

[fp-dev] Fw: First mail

[NoWhereMan <now...@fl...>]

----- Original Message ----- 
Subject: First mail


> This is a test.
> Hello world :)