If I understand correctly, the procedure for updating from v6 to v7 has two main steps:
#1 Updating the v6 database to work with v7.
#2 Uploading the v7 code by uploading the code in the update distribution.
In step #2 new files replace old ones of the same name, which seems quite reasonable.
But what about files on the v6 site which have no identically-named counterparts in the update? They will be untouched, and --without a procedure for finding and removing them--they will accumulate indefinitely, right?
I'm bringing this up because of a V6 infusion my predecessor installed, apparently by direct DB modification. Even though I defused thoroughly before updating, the updated site continued to display the panel -- uselessly, as it has no hope of working in V7. (Could this incompatible infusion have been worse than useless, by interfering with the V7 code?)
With Daywalker's help (THANKS!) , I learned how deactivate this infusion by modifying the DB. But the useless code remains on the V7 site. (Also, the deactivated entry remains in the DB.)
If I had simply deleted all the infusions before uploading the V7 code (Step #2), I imagine I'd get an error message instead of an unexpected panel. Sure, I would have to figure out how to fix THAT, which would require more or less the same work.
There's a little compulsive tidyness behind this question, but mostly I'm trying to understand the big picture about long-term maintenance of PF.
* Excepting, of course, config.php, and perhaps a few others.
I just found another case in which deleting existing "old version" files might be a good idea. On my brand-new 7.0.5 site I was exploring my profile setting. What's my default theme? Hmmm, the list offered included Aztec, the original site default (I guess) when it was running 6.00.300. That theme is no longer supported, right? Why is it being offered to me here? Will it work? Try it...
D'oh! This 7.0.5 installation is completely broken now. All it will return is
Fatal error: Cannot redeclare opensidex() (previously declared in /home1/aaaa/public_html/bbbb/themes/Aztec/theme.php:164) in /home1/aaaaa/public_html/bbbb/includes/theme_functions_include.php on line 196
no matter what step in the history I try returning to. I imagine I can repair it by mucking around directly in the DB and changing my profile manually so that it no longer specifies this invalid theme.
I mentioned earlier that my predecessor apparently installed an infusion by direct DB modification. Could he have similarly welded the Aztec theme into the site similarly? If so, I'm clearly going to need to do some cutting in the DB, but in the meantime wouldn't I be better off deleting all the old v6 themes before installing the v7 themes?
Hmmm, I fixed the site by changing /themes/Aztec to /themes/foo. That seems to indicate that the code does much better with a theme that cannot be found -- it returns to using the default, and that's what my profile shows now. That's a lot better than throwing a fatal error.
How frequent is this kind of issue in your experience?
The best solution is not necessarily a technical solution !
You've got a point there.
One reason for NOT making a cleanup prior to uploading all the v7 files could be if you have special own-developed files somewhere.
But if you know them and where they are (hopefuly you do!) then it sure makes sense to clean the root out before uploading.
What I did a couple of times was to rename the existing directories; then upload; test, and then delete the renamed directories.
But you have to be careful, of course :)
Yes, there's always a problem with privately-developed files.. and mods to standard ones, which may or may not be applicable in the new version. It's a very difficult problem. I think a clean-up script that generates a second script of proposed deletions _might_ be helpful in many cases. But I have no idea how frequently and extensively people modify the standard file sets of a given version. If the answer is "often" and "a lot", then .. .never mind.
Suppose you find a file ("xyzzy.php") in your current installation that you think is never used. How can you find out if it is, besides renaming it ("qqqxyzzy.php") and fooling around with your site for a while to see if get an error message? The file in question may be referenced in other files, so a site-wide source-code search for "xyzzy.php" should find it. (Or without the extension, only "xyzzy"?) But is it possible/customary/likely that the reference is embedded only in the database? If so, how would you find it? (I don't know much about phpMyAdmin. Does it have a global string search?)
Note: I think this is still reasonably on-topic; it's about cleaning up and moving forward to the new version.
But I have no idea how frequently and extensively people modify the standard file sets of a given version. If the answer is "often" and "a lot", then ..
i am the one from the ppl who...well...can answer often and a lot ^^. In fact, i understand your opinion and i found too some files extra, if i can say like that, and deleted them. But for sure i can't do a total erase a v6 then install v7 exactly for the reason above..You have right in some way, but it is like yxos said.
You can view all discussion threads in this forum. You cannot set up a bounty in this discussion thread. You can start a new discussion thread in this forum. You cannot reply in this discussion thread. You cannot start on a poll in this forum. You cannot upload attachments in this forum. You can download attachments in this forum. You cannot up or down-vote on the post in this discussion thread.