mod_dphpbb3_last_topics php warnings


Today after installing such pretty tool as  mod_dphpbb3_last_topics I received a ton of such errors

Warning: cannot yet handle MBCS in html_entity_decode()! in helper.php in line 130

After googling I found this article. I tried to replace:

$title = html_entity_decode($title, ENT_QUOTES, 'UTF-8'); with $title = utf8_decode($title);

but it brakes UA/RUS lang. After brainstorm I made following changes in code:


$title = html_entity_decode($title, ENT_QUOTES, 'UTF-8');


$title = html_entity_decode($title);


pf changes

List:       openbsd-misc
Subject: pf changes
From: Henning Brauer
Date: 2009-09-01 15:12:37
Message-ID: 20090901151237.GA11326 () nudo ! bsws ! de

[Download message RAW]

I have just committed a monster pf diff that is basically a rewrite of
the entire NAT part.

seperate rules for nat, rdr etc are gone.

nat and rdr become actions on regular rules.

simple rulesets are converted like this:

nat on $ext_if to ($ext_if)
match out on $ext-if nat-to ($ext_if)

more complex rulesets require some thought. since the weird
difference in matching order is gone (nat/rdr were first match) you
might have to reverse things and use your brains :)

the new NAT code is very very very flexible. every matching "match"
rule changes the adress on the fly (not really, but that is what it
looks like for subsequent rules), and you can nat or rdr multiple times.
for pass rules, only the last matching one matters.

so given
match out on $ext_if nat-to
match out on $ext_if to nat-to
both rules will match and will be the new src address.
however, with
pass out on $ext_if nat-to
pass out on $ext_if nat-to
ONLY the second one matters for NAT. same semantic that match rules
have for a lot of other stuff (altq, rtable, log, scrub).

the core logic, that relies on the big state table rewrite ryan and I
(with help from otehr developers of course) did last year, allows for
nat and rdr in any direction, but for now we prevent that in pfctl and
force nat outbound and rdr inbound, there are nontrivial implications
for the routing afterwards - if you rdr outbound, the packet will go
out on the interface it was seen on, even if the route for the address
rdr'd to actually points to a different interface. with NAT there are
similiar implications for the return traffic. since they are useful
nontheless I tend to remove the check in pfctl and document the
implications, but one thing after each other.

the diff is over 3000 lines, and makes pf about 800 lines smaller
than it was before. more cleanup is possible on top of this, but as
said before, one step at a time.

to add another data point how important hackathons are... this was
almost entirely written at c2k9 in edmonton and "finished" (minus a
few bugs fixed later) the week thereafter on bob's couch. while the
diff was almost entirely written by me, getting this actually into the
tree was a concerted effort by many developers. claudio adjusted ftp-proxy,
sthen ported that adjustment over to tftp-proxy, reyk adjusted relayd.
many people were testing a lot, I'm sure I forget a few, but at least
krw, sthen, claudio, reyk, dhill and dlg (who was insane enough to
throw this on production firewalls with significant importance) helped
a lot. igor did most of the manpage work. theo helped getting it in, a
lot. thanks guys.

and now it is your time. test this as much as you can, to avoid
surprises in 4.7, and bugs showing up after release... we really want
to find them beforehands, right?


Henning Brauer, hb@bsws.de, henning@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam