Mirmo Dynamics

This is a little script I made to get rid of those damned short tags.

<?php
 
while ($file = trim(fgets(STDIN)))
{
  $content = file_get_contents($file);
 
  $search  = array('/<\?=/', '/<\?(?!php|xml)/');
  $replace = array('<?php echo ', '<?php ');
 
  if ($content != ($new_content = preg_replace($search, $replace, $content)))
  {
    file_put_contents($file, $new_content);
  }
}

Just put this in a file, short_tags.php for example, and run something like:

$ find . -name "*.php" | php ./short_tags.php

I would have done it with sed, but it doesn't seem to support PCRE, and I don't know how to do negative lookahead (the (?!php|xml) thingy) with POSIX based regexp (if it's even supported) :/

UPDATE: Actually, POSIX Regexps DO support negative lookahead (as well as positive lookahead and lookbehind) with the same syntax as PCRE regexps. But grep doesn't use POSIX regexps, it uses things called BRE and ERE that I've never heard of before. Too bad.

While setting up a test server for some software I wrote at the office, I eventually noticed the following notice:

Notice: Use of undefined constant self - assumed 'self'

That surprised me, because 1) I though self were some kind of "superglobal" constant or a special token of the parser, always automatically available in a static method and 2) the code works. So what's up in there ? Let's make a simple test:

<?php

class foo {
	static public function bar() {
		var_dump(is_callable(array('self', 'foobar')));
		var_dump(is_callable(array(self, 'foobar')));

		var_dump(class_exists('self'));
		var_dump(class_exists(self));

		self::foobar();
	}

	static public function foobar() {
	}
}

foo::bar();

Executing the above code will yeld the following result:

bool(true)

Notice: Use of undefined constant self - assumed 'self' in /home/geoffreyb/test.php on line 6
bool(true)
bool(false)

Notice: Use of undefined constant self - assumed 'self' in /home/geoffreyb/test.php on line 9
bool(false)

What do we learn here ? Not much actually. It seems like self as a constant is only available when used with the scope resolution operator, aka double-colon or paamayim nekudotayim. When you want to use it in, for example, a callback definition, use a string representation of self:

<?php

is_callable(array('self', 'bar'));
call_user_func(array('self', 'bar'));

Which, while making absolutely no sense at all, works. Another way to get around this is to use the get_class() function that, without any argument, will return the name of the class you're currently in (foo in my example).

After a bit more investiging, I found out that there is nothing special about the self token, which is actually a string token. You can check this very easily with the following code:

<?php

class foo {
	static public function bar() {
		self::foobar();
	}
}

var_dump(token_get_all(file_get_contents(__FILE__)));

Somewhere inside the output, you'll find the following piece of text:

  array(2) {
    [0]=>
    int(307)
    [1]=>
    string(4) "self"
  }

And the token id 307 is resolved by token_name to string.

A small bit of ruby to get a constant from an URL:

require 'uri'
def url_to_constant(url)
	return URI.parse(url).host.gsub(/^www\./, '').capitalize.gsub(/[^a-z][a-z]/i) { |m| m.gsub(/[^a-z]/, '').upcase }.constantize
end

Nothing exceptionnal here, just a pretext to post something.

Après de longs mois d'attente, le related by tags nouveau arrive enfin ! Au menu des réjouissances, une interface de configuration, ainsi qu'un widget font leur apparition. Vous disposez donc désormais de deux manières d'afficher les billets liés, directement en modifiant le template comme avant:

{{tpl:include src="_related_by_tags.html"}}

ou tout simplement en activant le widget correspondant, que vous pouvez configurer comme vous l'entendez. Bien sur, ce widget ne s'affichera que lors de la visualisation d'un billet.

Au chapitre des fonctionnalités / bugfix manquant(e)s, on notera le bug lié à l'utilisation de postgresql, ainsi que la traduction française, qui sera pour plus tard.

Encore une fois, n'hésitez pas à poster tous vos commentaires ici même.

I used to use this yaml_to_ar lib from christophe to load categories tree into my database, using acts_as_tree in the model that was perfect. Arrived the time when I felt the need to use acts_as_nested_set instead, for which I had to fill the lft and rgt columns. So I just rewrote the yaml_to_ar piece of code (put this in lib/yaml_to_ar.rb):

require 'yaml'
 
class YAML_to_AR
 
  def initialize(file, model)
    @data = File.open(file) { |yf| YAML::load( yf ) }
    @model = model
  end
 
  def process(data = @data, parent = nil)
    if data.is_a? Array
      data.each do |val|
        process(val, parent)
      end
    elsif data.is_a? Hash
      data.each do |key,val|
        parent = @model.create(:title => key)
        process(val, parent)
      end
    elsif data.is_a? String
      parent.add_child(@model.create(:title => data))
    end
  end
 
 end

This should handle both acts_as_tree and acts_as_nested. To ease things a bit further, I also wrote a rake task (to drop in lib/tasks/db_load_categories.rake for example):

namespace :db do
  desc "Loads categories defaults data"
  task :load_categories => :environment do
    require 'lib/yaml_to_ar'
    Category.delete_all
    categories = YAML_to_AR.new('db/categories.yml', Category)
    categories.process
  end
end

Now I just rake db:load_categories, and voila !

For some reason, $HTTP_RAW_POST_DATA does not seem to be set inside an action controller. You'll have to use the php://input stream wrapper to access raw http post data:

$raw_post_data = file_get_contents('php://input');

Having started a few applications using the Zend Framework, I came out with a few practices that I tend to use over and over. In this post I'll quickly expose some of them and explain why I do things the way I do them. As you'll notice, most of them are already widely known and used over the ZF developer's community. Please remember that these practices are just what I do, and come with no garanty at all to be best practices.

Today I ran into an issue that I already ran into a few weeks ago when I did not have time to dig up, but today I had this time (this plus it's a really annoying issue as you'll see). The main symptom is that PDO does not throws exceptions when you'd expect it to. It's very annoying. The reason, in my case, seems to be that I am querying an old mysql (3.23.x in my case but any 4.x will do according to this bug report). I was not able to find any info from google, so I'm posting this here so that people know :-)

A PEAR package for the 1.0.2 version of the Zend Framework is now available from the PEAR PHPMafia channel. As usual, to install just issue the following:

pear channel-discover pear.phpmafia.net
pear install phpmafia/Zend

When anyone on #zftalk ask about where controller plugins should be kept, we usually responds something like have your own library namesapce alongside Zend/ and put it in it like YourNamespace/Controller/Plugin/YourPlugin.php. But what about application specific controllers ? There's a time where you have to write a plugin that relies on the application at such a level that using it elsewhere would make no sense. In that case, where can we store this plugin ? The question arised this morning, and we ended up to the fact that having a controller-level plugin directory would not hurt, after all. So one could have the following directory layout (simplified on purpose):

/application/modules/default
    /controllers
    /library/Plugin
        MyPlugin.php

The drawback is that in order to use autoload you would have to have each modules Plugin dir in the include path, which is a bit of a hassle. Instead, we could have the much more simple folloing layout:

/application
    library/Controller/Plugin
        MyPlugin.php

Which is simpler but does not allow for modules specific plugins. Anyway, the former layout would require a bit more logic in the bootstrap in order to extract every modules path as plugins are registered pre-dispatch.

Hope it helps with directory layout organization :-)

UPDATE

What I've finally decided to do is the following:

/application
    library/App/Controller/Plugin
        MyPlugin.php

So that application specific code gets prefixed with the App_ namespace.