Here's how I would do it, make a duplicate of your database. Install the new version on a seperate folder (or pref a sep domain), using the duplicate database. Redo all your hacks.

Once tested and working. Delete the copy of your database, overwrite your current install with your new (now hacked) install and run the installer agaian and upgrade your live database.

¥

I just started dealing with phpbb guts, and I gotta tell you: they have a GREAT method of 'approving' hacks. Basically a hack has to be written in a very specific style to even be considered. Next a group of phpbb people decide if this hack opens up a security hole or in some way damages the overall function of an installation. Finally, although I'm sure it's deeper than this, the hack must be written to apply to the default (sub silver) skin. Or theme I think they call it. Oh yeah one more thing: they publish 'approved' hacks with a version reference.

Unfortunately none of this will help the heavy hacker when phoenix comes out. The entire core is radically different. EVERYTHING is different. b2evocore as a folder name is going byebye! To my mind, as a simple user who likes to hack, it's like a whole new product that happens to be directly upgradable from an unhacked b2evolution installation.

I've seen that on phpbb, and it's a great system.

The beauty of the new system is you can do most of your hacks as a plugin instead, making them far more future proof ;)

¥

¥åßßå wrote:

I've seen that on phpbb, and it's a great system.

The beauty of the new system is you can do most of your hacks as a plugin instead, making them far more future proof ;)

¥

I think going forward I'll live to the phpbb model for hackage. Having said that, I sure hope someone smart (like you!) can help me make plugins for what my b2evolution needs in order for me to upgrade. Without getting too specific, check out [url=http://wonderwinds.com/flightblog.php/2005/06/04/the_forgotten_flight]this page[/url] and you'll get a hint at the depth of my hackage. I have a custom table for my sites, and custom fields for my posts - site and airtime and distance. All these come together when I post a flight so that my blog can track all my flying activity. Funky and personal, but important to me.

I'm WAY off topic! In an attempt to return to the focus of this thread, maybe between plugins and a "phpbb modeled" hack method jibberjab's issue is addressed? In fact I'll make it a point to produce a document that shows the "phpbb way" to document hackage and ask people to live to it. b2evolution is too small to expect a group to sit in judgment of hacks and 'approve' the good ones, but we certainly can ask users to follow a simple model if they're going to hack core files. ESPECIALLY in the post-phoenix world.

With a tad of imaginative thinking you could convert that into a plugin.

To continue on topic, the majority of the hacks that exist at the moment can be replaced with plugins in phoenix, with no need to hack the core files. As long as developers make as much effort as possible to create plugins then it'll make future upgrades far less painful.

¥

I totally lost track of this thread while involved with other projects.

EdB wrote:

Unfortunately none of this will help the heavy hacker when phoenix comes out. The entire core is radically different. EVERYTHING is different. b2evocore as a folder name is going byebye! To my mind, as a simple user who likes to hack, it's like a whole new product that happens to be directly upgradable from an unhacked b2evolution installation.

That's kinda what worries me the most. I'm still holding off rolling out a "corporate"-style blog because I'm wary of having to upgrade the whole guts of it while it's actually live, and it wouldn't be an unhacked version because in my opinion the antispam rechecker, disable comments after xx days, the pingomatic hack, among others, are essential. Oh yeah, the captcha too. I know you love the captcha, EdB! (A friend of mine saw your comment on my blog and was asking "what the h3ll's he talking about?." I told him never mind).

I suppose I could take the live blog (SOURCE) and make a complete duplicate of it on a testing server (WRKCOPY1), then make another copy of it (WRKCOPY2) on which to do the upgrade and the hacks, make sure everything works properly, and then repeat the upgrade rollout on WRKCOPY1. Basically just simulating the whole blog in another place.

I guess once WRKCOPY1 is running properly, as an exact mirror of the SOURCE blog, SOURCE could be backed up and WRKCOPY1 simply moved into its location, and then make the changes to conf/_config.php. The point is that with a fully mirrored copy of the blog, all of that procedure (either moving the blog and editing conf.php, or just doing an install/upgrade on the database), could be tested in a safe location while SOURCE continues on its merry way.

I feel like I'm just thinking out loud, but I'm trying to visualize a safe way to do an upgrade when it's more mission critical than a personal blog.

[edit: this doesn't even go into the particulars of upgrading to phoenix, which will involve skin changes as well. Ugh!]

jj.