Quote:
I'm getting near to letting out some beta versions of the software, and _begging_ Alex to add in a "Preserve" feature to the installer, that reads the local config_preserve file, and during an upgrade does *not* overwrite those files, instead installing in the same directory with a _version_number extension.
Quote:
If a file is upgraded by Alex, and it's not upgraded by the installer, then it may not work together with the new release.
So I see in advance, that Alex will not accept this config_preserve file feature request.
Why would you say that? Currently, there are a number of files that are preserved, ignored, or otherwise not modified during an install, and as links gets more complicated, this becomes more important.
Most code is in libraries, which means the "supporting" code, that code outside those libraries, is more site specific.
A number of suggestions have been made over the years on how to allow significant user modifications to the site, without losing them during upgrades, and it's something Alex should seriously consider. The "core" libraries can be updated, without needing to make changes to other scripts. For instance, updating the GT modules to handle updated MySQL conventions would not require changes to the program that simply asks: $db->get() but then goes and does a lot of non-links-like stuff with the results.
The plugins system is good, it's not great, and it's not perfect. Sometimes, rewriting SiteHTML.pm _is_ a better option, even if it has to be done for each upgrade.
If you look at the code in SiteHTML.pm, not much should change, unless something major to links changes. If that happens, those changes should _still_ be backwards compatible in the core code, so the plugins continue to work. So, a modified SiteHTML.pm would still function, without the newer features, similar to how the older template sets function, but without some newer features (I'm having a heck of a time upgrading customized 1.1x templates to 2.12 templates in some _minor_ areas!).
User.pm, is another file that seemed to be where site-specific routines could be placed. I started using Plugins/PUGDOG/User.pm because it wasn't. But, grouping all my library routines into Plugins/PUGDOG is only a part of the solution. I extensively rewrite jump.cgi on every release of Links, to run the postcards site. I have to, since I have special needs (and I didn't do a good job the last time, I was too rushed). I've gone to writing separate scripts, and ignoring the built in scripts on many sites.
Anyway, there is a lot of stuff that could change/improve over time, just like Links 2.0 was a complete rewrite of 1.x. Each program GT/Alex adds to their list, modularizes the SQL engine and core codes even further. Which is good! The big job is going back and getting rid of legacy code, and logic, to make use of it.
Not a high priority, I'm sure, but something that needs to be somewhere on the to-do list.
PUGDOG� Enterprises, Inc. The best way to contact me is to
NOT use Email.
Please leave a PM here.