Just a short note to say Tuskfish 2 is in the works. It's going to be a partial re-write of the back end, but there will be minimal changes on the front end or from a user experience point of view. The database schema will also remain unchanged to allow seamless upgrade. Tuskfish 2 will be designed as a strict MVC architecture to improved separation of concerns, rather than the loose MVC it currently has. Components will be assembled through composition and inheritance will be fully dispensed with. A test suite is in the works.
I'm very happy about Github's decision to grant unlimited free private repositories. It's not that I objected to Github charging people for the services they provide, but to qualify for free access you had to make all of your repositories open source and public. The problem with that was that the world is actually better off with some repositories remaining private. Do you really want access to the scratch pad repository I'm using to learn a new language? I think not.
Sick of low quality clickbait articles about "the best" and "the most popular" programming languages? Everyone seems to play this game, even otherwise reputable sites. I suppose they do it because "what language should I learn" is a question that every aspiring programmer has to ask. There's a lot of traffic in it.
I have one more refactor of Tuskfish planned. The goal is to break down some of the more monolithic methods into smaller logical components that are easier to test. This will not involve adding any new functionality as the core system now does what I want it to do. From here on changes will largely focus on refining the structure, simplifying and clarifying the code to make the project more robust and easier to work with.
I was playing around with different password hashing algorithms and came across this password hash cost calculator. It's a simple script you can use to measure how long it takes to calculate a given hash on a particular machine. Since web hosting accounts often come with limited resources compared to your local dev box, it's useful for tuning the cost of your hashing algorithm (how many times you iterate the calculation) to keep it at a sane level.
Tuskfish has had a substantial internal restructure. Static methods have been removed in favour of dependency injection, and modularity has been added (beginning of course with the content management module). The documentation needs extensive revision, when it's all ready the result will be released as Tuskfish V1.1.
I just finished reading Clean Code: A handbook of agile software craftsmanship, by Robert C. Martin. It’s a highly regarded book and contains many useful ideas; I have started refactoring some aspects of Tuskfish based on things I learned from it. This will include improving names, shortening and splitting up some of the larger functions into smaller logical units, replacing magic numbers with named constants and so on.
It feels strange to criticise PHP after developing a substantial (for me) project in it. Obviously I like the language and the recent performance improvements have given it a significant boost. But there are a few things that grate on the nerves and make me wonder about its long term future. Here are some of them, presented in no particular order.
I almost forgot to say, welcome to the Tuskfish CMS Project. It's a personal project that I created to solve a number of problems I was having at work revolving around ever-increasing maintenance overheads and ever-decreasing free time. I needed a robust and flexible but low-maintenance solution for web publishing, and here it is.
The Tuskfish API is now available as an online reference developed with ApiGen. Every class and method is documented and an explanation of its function and operation provided. This is the first version of the API reference and there is still room for improvement, but it will improve with time. The API will be updated alongside every release of the project.