November 2, 2006MOD Compatibility Engineâ„¢
Here’s another teaser about an upcoming offering from the phpBB Doctor: our MOD Compatibility Engineâ„¢ or MOD CE. This system is built off of the foundation provided by our MOD Managerâ„¢ mentioned in a prior post. This system is designed to check to see if a collection of MODs are compatible with each other, meaning it checks to see whether they can all be installed at the same time.
If you manage more than one phpBB board, or even if you only manage one but it is heavily modified, you will probably recognize the value of this system. There are several challenges in running a modified board. The first is managing / merging code from different MODs that may or may not be compatible with each other. The second major challenge is upgrading your board when updates to the core phpBB code are released. In some cases an update from the phpBB Group can break a MOD, so wouldn’t it be nice to know that? Wouldn’t it be nice to be able to apply the “fast” upgrade process of overwriting your board and then reapplying your MODs all at once?
Our MOD CE is the first step towards solving these issues, and it’s built on the foundation provided by the MOD Managerâ„¢. The core purpose of this system is to allow someone to select a set of MODs from the phpBB Doctor catalog and then run a check to see if all of the selected MODs can be installed together. This system does a series of checks on the selected set of MODs, and returns a report that identifies potential conflicts. It should be noted that this is only a potential list; it is possible that an identified conflict is not, in fact, an issue. But there are limits to what can be done to review program code with a program. 
The first step is quite easy… finding the common files that are shared across one or more MODs. If there are no common files, then there should not be any conflicts. For example, let’s consider a package of MODs named MOD 1, MOD2, and MOD 3. MOD 1 alters memberlist.php, MOD 2 alters index.php, and MOD 3 alters viewtopic.php. Clearly there are no conflicts, and all three MODs can be installed on the same board.
Now suppose that MOD 1, 2, and 3 all modify index.php in some way. The next step in the compatibility check is to see which lines of code are included in FIND commands. If there are no conflicts in the FIND commands, then the assumption is made that there is no conflict with installing the set of MODs. Our MOD CE is smart enough to detect overlapping FIND operations during this process, so if one MOD looks for line 10 – 12, and the next MOD looks for line 11 – 13, then this will be detected as a potential conflict.
The reason for looking for overlapping FIND targets is simple. If the FIND operations don’t match (or overlap) then the subsequent operations (like adding or replacing) will be performed on different areas of the code, and therefore should be compatible. For example, we have two very simple MODs in the phpBB Doctor catalog that all modify index_body.tpl. One of them makes the forum icon clickable, and the other makes the “view online” icon clickable. While they both modify the same file, they do not modify the same code, so they are compatible with each other.
Finally, if there are FIND commands that potentially conflict between the 3 MODs the next step is to see what is actually done after those FINDs. If there are any REPLACE operations (in-line or otherwise) then a flag is raised. Any ADD operations (before or after) are not considered conflicts.
This system is not guaranteed to be 100% foolproof. It may highlight potential conflicts when, in fact, there aren’t any. But we believe it represents a quantum leap forward in MOD management in that you can quickly and easily check to see if a collection of smaller MODs can be combined into one larger one.
And that, coincidentally, is the purpose of the next custom feature to be offered by the phpBB Doctor, our MOD Package Builderâ„¢. Details on that in a future post. 
Comments (4)
This sounds very promising.
However, there will also be false negatives. When a piece of code is replicated by MOD A (e.g. a subforums MOD), you won’t be able to identify MOD B (e.g. a tooltip MOD) missing it.
Comment by damnian — November 4, 2006 @ 8:03 pm
I certainly agree that there will be things that fall through. However, I am not following your example. When you say “replicated” that means to me “repeated”, as in there is some code that is repeated along the way. And since you mentioned subforums I think I see where you are going… as there are lines of code within the (for example) simple subforums MOD for index.php that are the same as code from the regular index.php. I have two ways to address this.
First, I have my own subforums MOD that is similar in functionality but substantially different in code from the subforums MOD released at phpBB. I intend to offer (here at this site) very few MODs that are not written (or rewritten) here. I don’t plan to rewrite the attachment MOD, for example.
But by doing that, and by keeping this process in mind while writing those MODs, some of these issues can be addressed.
But the real solution to this is that the MOD CE doesn’t go by FIND commands, but by the results of the FIND commands. When a MOD is added into the MOD Manager (which is the source data for this system) each FIND is tagged based on the core code from an unchanged phpBB board (current version). The results of that process drive the compatibility check.
In other words, the MOD CE does not attempt to install every MOD that is selected, it anticipates what would happen and records conflicts (or at least potential conflicts) based on that process. So it’s a bit different approach than what I think you were envisioning.
Thanks for your comment. It’s refreshing to see one actual comment mixed in with the 30+ spam comments that my spam-catcher is processing.
Comment by dave.rathbun — November 7, 2006 @ 9:47 am
Yes, I certainly meant “repeated”. However, replication isn’t always limited to a single file.
Guess what, I also have a subforums MOD of my own, and it has major portions of index.php replicated in viewforum.php. Now, try adding the last topic tooltip to the forum list – and you’ve missed the subforums…
I realize that subforums are an extreme (this is probably the reason for CH to eventually become a phpBB2 fork), but more common examples can be thought of, the Attachment MOD being a good starting point
.
Comment by damnian — November 7, 2006 @ 1:50 pm
But you’re looking at a different issue.
If you have subforums with code replicated / repeated in other areas, that’s one issue. If you have a MOD that installs a “tooltip” for the topic that’s another MOD. Unless that MOD is written to be compatible with subforums, it won’t be. That’s not what the MOD-CE is designed to do.
What it is designed to do – at it’s most basic level – is determine if two (or more) MODs can be installed without conflicts. It doesn’t attempt to – nor will it ever attempt to – see if two MODs will function together, that would be nearly impossible.
For example, consider the following two mythical MODs. One opens index.php, finds a specific line (let’s say line “300″ because it doesn’t really matter what it is) and before that line adds this code:
Next, MOD #2 also finds line 300 and before it adds this:
Now clearly these two MODs will conflict functionally, but they can both be installed at the same time. Whichever MOD is installed last will “win” as to which value is set to $myvar.
The purpose of the MOD CE as I plan to deliver it is to find a set of MOD and determine if they conflict with their installation instructions. There are rules that I have determined and coded that say exactly what a conflict was, in short it’s based on detecting replace operations that update overlapping blocks of code (where a “block of code” could simply be one line.)
In other words, there’s no way that I can see – short of writing some sort of code parsing engine that actually understands what the code is doing – to detect and react to the situation you describe.
Comment by dave.rathbun — November 7, 2006 @ 7:26 pm