1. I’m thinking the time might have come to write a wrapper around DOMDocument which actually makes it usable. Thoughts:

    • automatic conversion of various encodings to HTML entities to scoot round encoding issues
    • XPath queries still work but querySelector and querySelectorAll are implemented for both the document and individual elements via Symfony XPath → CSS converter and relative XPath queries
    • A DOMNodeList which actually implements ArrayAccess instead of acting like a fake array
    • Perhaps some javascript-inspired property names like innerText, innerHTML for consistency
    • Maybe some jQuery-influenced shortcut goodness for doing things like removing/replacing elements
  2. I’m rather impressed with guzzlephp.org’s HTTP Link header abstraction. Parsing Link headers and providing a simple API to check for the existence of/fetch links by rel is welcome attention to detail and cements it’s position as the only PHP HTTP client I will likely ever need.

  3. Need to use require.js to load a bunch of scripts compiled via assetic into a PHP file, annoyed by auto-append of .js, don’t want to set up irritating routing? Add a ? to the URL, require.js will add a .js to the query string, loading the file correctly.

  4. Turns out that performing a GET request on a data URI from PHP works if file_get_contents is used, not if cURL is used. I wonder what support is like for other server side languages — using data URIs in with could be the basis of some interesting .

  5. New CRUD fetcher/saver design coming on well. Decided on per-semantic-indexing, with abstract indexes and APIs so I never have to think about the SQL under the logic (which I do with ORMs like Doctrine).

    Implementing the whole lot using traits, too — mixins FTW.

  6. Finally decided that symfony Security component is way too complicated for my little , so ditching it — but I’ve learnt a lot from digging through it and my further efforts will try to provide some of the amazing flexibility it gives whilst being more performant and easier to understand #php

  7. Made some updates to my note autolinking flow — instead of lots of unstable regexes, only one runs now (courtesy of cassis) and the rest manipulate the XML–compatible HTML which results. Much more robust, much more extendable

  8. Aral Balkan: Sexist? Want to learn PHP? We’ve got just the book for you: SexyPHP: A Fun Way to Learn Object Oriented PHP http://t.co/nz1650vr

    aral hideous. That makes me more embarrassed to be a PHP dev than all the bad rep it has as a language. And they're teaching SVN! It gets worse :(

  9. I love that now has shiny namespacing and a thriving code sharing community, but I think the heavily hierarchical namespacing practises used by some of the community (e.g. symfony components) are unhealthy.

    They are difficult to memorise, relying on (often slow) IDE autocomplete, and encourage a use statement for each class. That’s pretty much a scoped equivalent of from x import * in python — not a good practise! It’s still namespace pollution, it just takes longer to write.

    I am trying to use a more python–like, package-centred approach with much fewer subnamespaces. The outcome of this should be that you use the package name:

    use BarnabyWalters
osse;

    …and then using all the classes/subnamespaces from that root, e.g: $t = Posse\Helpers::convertHtmlToTwitterFormat($s);