> GP : we have already discuss of the uninstall process at phpBB.com, and I think I have proved than no way was 100% reliable (even 75% I will say) with an automatic process. From there, you have to give the user the ability to achieve it by hand, and this doesn't concern only the last mod applied (that's for backups).
> Nuttzy : really, I can only requote what I wrote : you have actually in the jumpbox func (functions.php) some lines commented, managing the auth for the jumpbox and allowing to add private forums in it.
A mod more advanced than the phpBB func comes on it, add the auth search, but the line can't take place where the commented ones are (why not ? It is the author choice and the mod requirement). As there is no need to touch the original code, it remains unchanged, and then the final state is a commented line, and a new line non commented similar, later in the code. Then another mod comes, and have to modify this added part. It will issue to the first commented line if you doesn't consider the line is commented (error a hand-user won't do). Not a big deal you gonna say, just add the previous line to the find. Result : you have artificialy raised up the required stuff for find rather than decreasing it, and you are not sure at end you won't get to the line expected (as this can be repeated). More : this is a silent issue : even if the same line take place further in the file, in another function, you will never be able to reach it, and easymod won't complain. It will just say all is okay, although a human doing it won't certainly do the same mistake. The worst is it would be certainly very difficult to track and fix, even for an advanced user.
IMO :
is unique, and
is also unique, and doesn't adress the same line at all.
You can link this to the consider a find shouldn't achieve on an explicit commented line, as long as the find statement itself doesn't include the comment tag ( // ). You will be so able to handle quite all states of code.
The [MUTE] is only there to avoid a replace-by-nothing deleting the original code (loosing the ability to step back), and falls in the case of explicite commented line rather than using /* */ which would be much more difficult to track (it will require to analyse the way the code will run) : it is not the same discussion, although it is linked.
And at the end, you guys are explaining me I can't set the comments I want to appear in the scripts (whatever they are), and that of course can't be accepted from my programmer's point of view. Comments through a developpement is the first indicator of the quality of this developpement : I won't trust a script without any comments, and my first move is to add the missing comments in order to find the logical bugs that are everytime presents in those kind of scripts, and believe me, I have always found some in those cases, even on my own scripts.