A long time ago I wrote a MOD for my phpBB2 board that puts a nice red banner at the top of the posting screen if you are getting ready to “bump” your post. Bumping is defined as posting two (or more) times in a row without someone else replying in between, and without waiting 24 hours first. Does it work? From a functional standpoint it certainly does. From a procedural standpoint, not so much. More…
September 27, 2009
July 12, 2009
One of the reasons I wasn’t around much earlier this year was I was in the process of moving a bunch of sites over to a new server (including this one). In most cases the move went without a hitch. In one particular case there was an interesting bug that didn’t show up right away. It was related to the banner system I wrote for my largest board. Fortunately it was an error on the “good” side, so I didn’t make any sponsors angry. More…
March 4, 2009
Here’s a tip: if you encounter a problem with code that someone else (such as myself) has written, and you write to them asking for help, try to be more descriptive in your error report than this:
On localhost works but not works in linux server.
Localhost: all pages works
Sever linux: none pages works
So basically they’re telling me that the MOD works on their localhost installation, but once they upload it to their linux server “none pages works” which, I guess, is a bit of a problem.
But without my ESP module addon for the PM system, I am unable to determine exactly what the problem is, so I was forced to ask them for a specific issue. So folks, if you have a problem with my code, tell me what it is. If it’s supposed to do X and it does Y instead, tell me that. If it’s supposed to do X and it’s not doing anything, tell me that.
But don’t tell me “it doesn’t work” and expect much help.
November 11, 2008
I got an interesting request for a feature on a new board I’m working on tonight. This is a phpBB2 board (of course ) and I am using a variation on subSilver. That template is “fluid” meaning the width will expand to fit the size of the window. Years ago having a site expand to fit the window was okay. Now that some people are using 1600×1200 pixel resolutions it can be hard to read. The human eye / brain simply can’t scan a line of text that far without losing track of where you are. I solve this myself by running my browsers at less than full screen, but that’s my choice. If someone else chooses to run their browser window stretched over two high-resolution monitors that should be there choice as well.
Where is this going? Based on the remarks made earlier tonight I worked out a really quick and easy MOD for phpBB2 (and the idea would work just as well for phpBB3). It’s a few bits of code that allow users to set a fixed width for the board (by pixel count) or opt for a full screen display. It took about an hour from initial concept to execution.
September 17, 2008
Have you ever received an email with an advertisement for something unsavory followed by a paragraph of seemingly nonsense text? The reason for the extra text was the spammer was trying to get past one of the more common email spam filters known as Bayesian Spam Filtering. The process of adding text is called “poisoning” the filter, and it’s yet another tactic in the ongoing war between legitimate content providers and spammers. I was asked at Londonvasion 2008 whether I felt that there would ever be an effective way of dealing with human spammers. My comment at the time was that the best defense against spammer posts (human or otherwise) is an active and effective moderator team. Could this sort of algorithm be adoped as an anti-spam technique for board posts? Yes, I believe it could. To the best of my knowledge nobody has yet tried to do that for phpBB2 (my google-fu may have failed me, but I did look). I would be very interested to hear of such a project if it exists.
The problem with this and other anti-spam techniques is that it’s based on words rather than content. This may seem like splitting hairs… after all, isn’t my content made up of words? Yes, yes it is. And that’s the problem. Confused yet? I hope so, because it gets worse from here.
September 10, 2008
I started this series of posts talking about various ways to manage the update / select process used to manage a sequential counter. The primary goal in rewriting my board banner system was to ensure that it was both accurate and efficient. I accomplished that task by using the LAST_INSERT_ID() function provided by MySQL as detailed in the prior post. That function would allow me to update a counter and record the resulting value as a session variable, and then retrieve that session variable value without being worried about updates from other pages.
The next design delima I had to overcome was: How was I going to store and manage the banner data? The obvious choice was to create a table called phpbb_banners and store everything there, but that would have required me to do a lot more work. Don’t get me wrong; I did create that table. But that’s not the table that drives the banner display logic. That table is called phpbb_banner_instances and I will show what it looks like and explain why I created it next.
August 29, 2008
In the first post in this series I talked about the design process for my new banner system. I wanted it to be 100% accurate so I eliminated any sort of random number generation process. I also eliminated a SELECT … FOR UPDATE because I was concerned about deadlocks affecting the efficiency of my code. At the end of the post I introduced the MySQL LAST_INSERT_ID() function. Today I will cover it in much more detail.
MySQL offers an interesting function called LAST_INSERT_ID() that – once I figured out the proper syntax – provided exactly what I needed for my accurate and efficient banner system. What does it do? Simply put, it provides a shortcut to return the result of a previous SQL statement without having to worry about intervening updates. Before I explain the function, I want to share a bit of the database design and how the process will eventually work.
August 20, 2008
I recently rewrote my banner management system for one of my boards. The board is fairly active (in fact we’re averaging over 100,000 page views daily now) so with multiple page views per second taking place during the busiest times of the day it would make sense to be concerned about performance. And I was. But I also had to be concerned about auditing my banner and page statistics, and ensuring that if I said a banner was going to be displayed every 10 page views that it was. So the system had to be 100% efficient and just as accurate. That presented some challenges.
August 3, 2008
In the first post about this MOD I introduced the basic concept of a daily digest and described how the scheduled process worked. The other half of the system is the user interface that allows the user to mark which forums they want to subscribe to. I will cover that (and a bit more about the database design) today.
August 2, 2008
In the first post in this series on working with recursive data I talked about several different ways to store the information in a database. Some of them were promising, but they all had complications of some kind or another. I was using the phpBB Doctor Project Manager database design as an example, but there are quite a few different scenarios where recursive data will be found. Since SQL is not a recursive language, I am trying to find the best way to model the data so that I can access it with minimal fuss.
As an example, in my project management system I need to be able to quickly and easily identify the parent task, if the task has any sub-tasks (child records), and which tasks are at the same level (siblings). I would like to be able to traverse the tree in either direction (up to the parent or down to the child) without using recursion. In order to do that, I need a model that is different from anything presented in the prior post.