When you use latin2 (or perhaps any non-latin1) encoding you probably bump into the issue of not having the desired punctuation in the character set. In the Hungarian language, for example, such characters would be:
- the "ndash" HTML entity –
- the quotation characters „ and ”

So how come you didn't notice it yet? It's because your browser recognizes that you aren't using utf-8 so it encodes those values to their HTML entity equivalents before sending the request to your server. Your server may store these values in the database and when rendering an HTML page, they simply get handed over to the browser in the HTML source and they appear properly on the user interface. Or aren't they?!

You sure want to use htmlspecialchars() to properly encode database values before outputting them to the browser (especially if your DB consists of any custom user input). The problem with htmlspecialchars() is that it converts the first character of any HTML entity (&) to its HTML entity equivalent as well, which is &. Thus, for example, – becomes –. What happens is what we might call "double encoding".

In some special cases you may trust the data you are displaying and remove htmlspecialchars() so no escape is happening. This isn't the desired behavior either though, because then you cannot enter less-than (<) or greater than signs (>), for example, since they will end up in the HTML source unencoded and produce undesired results because the browser will recognize them as HTML tag markers. Sure, you can still enter their HTML entity equivalents &lt; and &gt; but that's not too convenient.

The issue has been addressed in PHP 5.2.3 by a quick fix: it introduces a fourth htmlspecialchars() parameter, bool $double_encode, which is true by default to stay backwards-compatible. You can set it to false, so any HTML entity occurence in the string you pass to it won't get encoded again but the rest of the values still will.

This seems to work fine: the browser recognizes the use of a single-byte character set, which, in our example contains a special punctuation character (like „ and ”), so converts it to the HTML entity equivalent, and the server, when displaying the value, converts any "standard" special HTML characters (like < and >) to their HTML entity equivalents. This is fine for most applications.

There are still (at least) two issues with this approach though: special punctuation characters will end up encoded in your database, and, because of this:
a) your searches will not be consistent: if you submit a search for "ash", you get back all records which contain an &ndash; "character" also
b) your field length isn't accurate anymore: if your field is declared as varchar(100) in MySQL, for example, you can't store 100 characters in it unless the value contains no special punctuation.

So, if you want to create websites and/or applications which are totally perfect from a linguistic point of view as well (and you want, because you want to Set Higher Standards for yourself and those around you), you need to use utf-8 even if there's a native character set available for the language you are using.

We have some capacity for the following months over at phpXpress thus we are looking for more business partners with PHP development needs. If you happen to be one of them or know somebody who might be interested in our services, please drop us a line.

WACT 0.2a users, you might need this form postback fix.

Update: in the newest versions of dokuwiki it is now much easier to simply extract the files and visit /install.php in a browser instead.

In my opinion DokuWiki is the best wiki software out there (see features). In addition to all those cool features like namespaces, it stores pages in plaintext files, thus no database backend is required. Setting it up is pretty easy also. I promised to investigate the steps needed to set up DokuWiki with the simplest authentication scheme for a friend and I thought others might benefit from it too, so here it is.

The current versions of FCKeditor (around 2.2) contain a bug that prevents the Quick File Uploader to work by default.

The solution is to search FCKconfig.js for "FCKeditor.QuickUploadLanguage" and replace it to "_QuickUploadLanguage".

If you ever need to debug FCKeditors file upload functionality, remove target="UploadWindow" from editor/dialog/fck_image.html to get some feedback with uploads.

(I am posting this in the PHP category because I needed it when developing a webapp, maybe others benefit from it as well)

Basically I wanted to store multiple values in a single field to avoid additional tables with table links and unnecessary complexity in my already-2-screen-long queries.

I needed to store the 5 possible values A B C D E in this field (and 20 values in another case) then compare the fields with each other in the WHERE clause of the queries. If you start thinking about this, it isn't common sense at all because neither LIKE or = works here.

To make it more clear, we are talking about values like ABC, BCDE, ADE, BE, CDE etc and we need to tell if any of the characters are identical in two strings. For example:
somefunc('AB', 'AB') = true
somefunc('AB', 'BCD') = true
somefunc('ABE', 'CD') = false
somefunc('ABCDE', 'E') = true

The first thing came to mind was to create this function but it wasn't possible in my case.

I was about to create those additional tables and add another couple of lines to my queries when I realized that the SET datatype can help. I was in heaven when I found the FIND_IN_SET() function. It isn't enough though. FIND_IN_SET() allows you to compare a single value to a list of values (e.g. 'A', 'ABC'). I need to compare list of values to list of values ('ABC', 'CDE').

Here comes the fact that values with the SET datatype are stored as binary and can be used as integers.

Finally the solution:
SELECT * FROM tt
WHERE field_a & field_b

This is the most elegant solution I can come up with. It also decreases the development time from 1 days to 1 hour.

There is a limitation though, from the MySQL manual: "A SET can have a maximum of 64 different members."

Hope this helps somebody. Happy coding!

Next Saturday I'm gonna talk about the great new features of PEAR 1.4 on the Hungarian Web Conference 2006 in Budapest. Everybody is warmly welcome to visit the event (entrance is free but registration is required - hurry up, not too much seats left).

The Hungarian Web Conference is the official continuation of the Hungarian PHP Conference event series, being more widely open to other languages, tools, specifications and recommendations used for web development.

Some of the keywords that the program will cover: PEAR 1.4 (PHP), ASP.Net, Web Forms 2/XForms, Macromedia Flex, Textarea++, Icecast+AJAX, Django, Ruby on Rails, Perl, W3C, Web Accessibility, Java, High-Availability System, Semantic Web etc.

I will talk about PEAR in overall, 1.4+ features, the CLI installer, creating packages, roles/tasks/post-install scripts, setting up a PEAR server and local PEAR installations.

My personal opinion is that the conference offers a very compelling program to everybody interested in web development.

A special part of the program is a round table discussion about the future of web development.

See you there!

P.S. Don't be surprised, the talks will be in Hungarian.

I agree with Sean, it's very useful to discuss the tools we use for development.

When I started PHP development 4-5 years ago, a simple texteditor and an FTP client was enough to achieve my goals. During the years I've quit my job and began freelancing. I needed to set up a stable development environment without changing to unix at that time. Starting with w98, then changed to w2k, now I'm using WinXP and I'd like to give some good advice for those who work in a similar environment. Most of the tools I use are cross-platform so hopefully everyone can benefit from these ideas.

Joshua is currently finishing his talk on php|architect's php|symphony series. It was available via a live webcast. I'm very impressed, both by the quality of the content and the simplicity of launching the stream. Joshua talked about AJAX in general and showed us examples using JPSPAN. The technology itself is very easy to learn, I'll take a closer look into it in the near future. I'd like to thank for the php|architect team for their free offer to be part of this show. I'm now convinced that this kind of learning really works and will probably subscribe to future courses.

Looks like everyone's occupied preparing for the Third Hungarian PHP Conference that will be held in Budapest. This is the first time for the conference inviting speakers from other countries, Derick and Lukas are already on the way and will arrive in the afternoon to talk tomorrow about Multi-Lingual development, PHP and Performance, PEAR and Database abstraction.

I have two sessions, an introduction to WACT and I'll present some PEAR packages in my other talk.

The WACT session looks like being a "hardcore" session for experienced PHP developers. Because I have a very limited timeslot, I'll talk about WACT in general and present a "simple" tutorial, including DataSpaces/DataSources, Handles, Delegates, the Controller Architecture, Front/Page/Form/ButtonControllers, Views/FormViews, Validation including Rules and ErrorLists, Templating including Pagers and more importantly DB access. Everyone is strongly encouraged to bring multiple brains because the 45 minutes will take at least 3 per person :)

In my PEAR talk, I'll cover two template engines, HTML_Template_IT and HTML_Template_Flexy, HTML_QuickForm, DB_DataObject and DB_DataObject_FormBuilder, HTTP_Upload, Image_Transform, Mail_MIME, Mail, Mail_Queue, Auth, Auth_PrefManager and Log. One could talk about them probably for days but I only have 45 minutes so similarly to the WACT talk, this will be a short introduction for those who want to see some part of the packages that PEAR offers and/or want to extend their existing knowledge.

As far as I know this event is unique in that it's free to visit (pre-registration was needed), opposed to other local events and the international conferences. We expect around 500 visitors to come. Hopefully most of them will learn a lot during the day and it means lots of fun to everyone of course.

update: there are many other talks of course.

I'm always looking for good points that I can mention if someone asks me whether PHP is enterprise-ready or not. My primary interest in the industry is enterprise web portal development in PHP, so I was glad to read Marco's plans months ago. Hopefully he's still interested and works on this.

Today I found some convincing lines on the Zend website that one can use as a reference:
"PHP has proven itself across a range of large enterprise deployments at companies worldwide including: Hewlett-Packard, Boeing, Lufthansa, Dresdner Bank, Disney Online, Yahoo!, Lycos, Sprint, T-Mobile, Orange, Nortel Networks, Lucent, WallStreetOnline and Siemens."

There's actually a discussion in the Sitepoint forums about Advanced PHP Programming in Corporate World for those of you who are interested.

Update: Top 20 IT mistakes to avoid: Underestimating PHP in Harry's blog entry.

After writing some initial lines about ZDE 4 beta in my language, I considered it being a good idea to do it in English as well.

I used Zend Development Environment 4.0.0 beta + Zend Studio Server for 20+ days now and I have to say I'm very satisfied. I tried many IDEs before, including the previous versions of ZDE, Eclipse + Xored Trustudio, Eclipse + phpEclipse, NuSphere PhpEd, PHPEdit and many others, and actually ZDE 4 is what I like the best. I run it in WinXP.

pros:
- code completion scans for classes inside the project; very useful when using external tools like WACT and PEAR
- multiple directories can be added to projects
- inspector displays classes in a tree
- installs almost silently
- debug works right after installing (a reboot was needed?)
- project data is stored in a single small XML file for each project

cons:
- no SVN support (although it supports CVS afaik)
- cannot ignore directories under the project root dirs: compiled templates, SVN & CVS directories get processed as well (scanning for classes - code completion)
- doesn't deal with the environment while Trustudio does; ZDE doesn't scan files for classes in my include_path set in php.ini -> I have to import the same include directories (PEAR, WACT) to each project - but at least ZDE doesn't copy anything, just remembers the path
- made me some headache; modified apache's httpd.conf (added PHPIniDir "C:/php", while this directory didn't exist at all (among other lines? dunno))
- editor: auto-indenting is nice, auto code formatting works fine, but auto-indenting creates lots of unnecessary spaces in empty lines

I plan to buy it. Others are impressed as well.

I'm thinking about this for two weeks now and I cannot decide. I need a permission management system preferably with an existing web UI to control the rights. I may create one on my own; it can be a great benefit for the project, because this provides unlimited flexibility. The project itself is a very complex portal which will hopefully get hundreds of thousands of hits every single day - sooner or later that is. I shouldn't depend on other projects at all.

At the same time, I'm an open-source guy, so I'm also leaning towards using existing systems; I selected LiveUser and phpGACL for the purpose. The big question is, if I should:
a) use LiveUser, which means including PEAR on every request, which wouldn't happen if I didn't choose LiveUser. I prefer LiveUser because I already know it (well, the last version I used is 0.3.0-beta, they actually have 0.14.0-beta) and because I know many of its developers personally plus I tend to like them and trust their knowledge.
b) use phpGACL - it needs ADODB but I don't use ADODB at all and I don't plan to do so. It doesn't need PEAR though. You are right, I'm a PEAR developer but I don't use PEAR in this project at all. phpGACL is also very promising: "GACL class: Designed to be very small (517 lines of code including comments) and very fast, this class strictly takes care of the permission checks."

LiveUser has LiveUser_Admin and phpGACL has its own "Admin Interface" as well. The latter is currently more advanced as far as I know.

Oh, and if it counts, the project is based on WACT. I need to access the permission system both in the PageControllers and inside the templates, so I will have to create some new tags as well, which is an exciting task - hehe, code generation rulez :) I also know that Ian White has already started working on a LiveUser implementation for WACT.

Actually I think I will choose one of the systems above, run profiling tests at the end of the development and create a custom system if they aren't as fast as they should.

LiveUser vs phpGACL - PEAR vs ADODB.. what should I choose and why? Any tips are greatly appreciated :)

I didn't really like the Horde project until now--mainly because not knowing its details, except their webmail client. Today I had to install the Horde framework to some unix box and I'm amazed because its internal structure. Horde is a great (and huge) collection of projects using the same framework, don't believe what those people say who only tried the mailing client.

The goal was to install Whups for ticket management; the process was clear and straightforward after installing Apache, PHP and mySQL on the server and finding out that I need Horde 3.0 & Whups from the CVS.

I must admit we have some great talks for the Hungarian PHP Conference in 2005. If you feel you can talk about some interesting topic(s), join us now!