Probably less major effort to merging customizations into this update, partly because it wasn't that long ago that I merged 5.0.9 into my site. When there are diff patches, I tend to merge those into my site...while the bigger releases its figure out how to reapply my customizations to it. Though there wasn't a huge amount of change between 5.0.x and 5.1.x, within the areas that I had made customizations to.
One area of extra work was updating my skins to the new versions, not as bad as 4.x to 5.x was, but there were enough changes that I had dig around a bit to see what was going on and what was still needed.
The old skins should still work unchanged, but sometimes things break between versions...or things change slightly. I use three main skins for this setup. I had some time ago, made my own copy of 'custom' to avoid constantly recustomizing it after any update. And, I had settled on making a skin based on 'evocamp' for another. It was originally based on 'emerald' which was a 3rdparty skin, so there hadn't been a separate copy then. Which is probably why I didn't make my own copy of the 'photoblog' skin. Though since I used the Advanced tab and such to make most of the customizations to it, there was minimal adjustments to make to it. So, after updating my copies of the 'evocamp' and 'custom' skins. I shoved the new version up to my web host.
Ran the updates, and it largely worked. There were some oddness with
$allow_redirects_to_different_domain. Eventually came up with values of the first two that seemed to work right, and set the last to 'always'. Multidomain is kind of messy still. If
$baseurl, changes with HTTP_HOST, Blog URL doesn't work unless none of my blogs use $baseurl. Plus there were oddities with logins or backoffice. Perhaps there needs to be another option for
$allow_redirects_to_different_domain, and that is to allow them to a configured list of allowed domains.
The final bit was to make some readjustments to
style.css, for my main site (based on 'custom'.)
And, then one more bit...the more and next-page toolbar buttons are missing....back patch those into
_quicktags.plugin.php, even though the internal version didn't change.
Pages: 1· 2
This weekends project was to update the skins to 5.x.
From the early 0.8x days of this blog, I had settled on a customized version of the custom skin. Recustomizing it each upgrade was annoying, until I found that I could make my own version of it and it would likely work. Though if there were (bug/security) fixes, it was easier to find out what those were and apply them to my version of the skin.
So, I created an LKC skin for the blog.
This worked surprisingly well, when I upgraded from 4.1.7 to 5.0.5 last weekend. In that I made no changes to any of its files, and it pretty much worked. There was some breakage which I later found was due to some reorganization in global css files due to global css (which I could've fixed by copying the global css files from 4.1.7 down to the skin directory level. But, it was easy enough to fix up some html tags in
index.main.php and "free html widgets". Plus I also removed some other widgets in the process, such as no more Flash Tag Cloud, or the flash twitter widgets (which I guess were broken since the twimg.com incident anyways, and doesn't seem to be available anymore).
This single instance of b2evolution, is also home two a couple other sites now (I used run separate instances, of the heavily customized nature of the early days for this blog, but the work in maintaining them all was a pain, and since they're all with the same hosting provider...going multidomain seemed the better way to go, though it has its challenges.
So after I updated 'LKC', all the code I had changed to get around the css problem needed to be changed back now that it wasn't a problem anymore. Well, it didn't have to be, but the HTML tags I used had been deprecated for quite some time, so it was kind of strange using them again to make things work for a while.
The I turned to the other sites, first is the photoblog site, which is using the included photoblog theme directly...with minor tweaks. I should probably split that off someday. But, only one file changed between 4.1.7 and 5.0.5, though I had pulled up some files from global into it to make some customizations. Though in 5, there's back office means to do the same thing...so to update this skin, I removed those specific customizations and moved the information into the back office. In fact, I'm not sure what if anything I've changed to it for its current appearance. Though there's some things I think could be done better if I had some time to put into it.
Then the other was using 'emerald', which was a 3rdparty skin. I mainly wanted something simple with 3 columns, with the level of customizations that fit my desires at the time. It was originally released for 2.4, but somebody else had updated it for 3.0 or newer. And, while it suffered from similar problems to other old skins that I could work around, I had a desire to make it consistent with 5.x themes. I had checked the forums, and there was one post of somebody who was working on updating their theme which had been based on this to fit 5.x. Though looking at their site, I wouldn't have know it was emerald .... and, there were any details on what he had done to making 5.x...or not sure if it was the issues that I was having.
So, I looked around at other 3 column themes to try. Soon, I decided that I would just use 'evopress', an included theme...and make customizations to it. So I copied it into a different directory and changed
_skin.class.php appropriately. And, then made some code changes, namely to
Now its late, and I have road trip to UNMC tomorrow....
Well, I got the upgrade from b2evolution 4.1.7 to 5.0.5 done today. There had been a few failed starts over the previous few weekends.
I had a plan on how I was going to do it, which was aided the 3 way diffs between my site, the b2evolution-4.1.7 code and the b2evolution-5.0.5 code. Later I did a diff of just my site and the b2evolution-4.1.7 code.
Since it was easier to spot what I had done this way, since pretty much everything in the 5.0.5 side was changed... making it hard for the tool to show where my site differs from the 4.1.7 code.
I did that there was some cruft from previous updates or files that weren't part of the diffs. Perhaps diffs only contained files that had changed between point releases, and omitted files that were new. Or diffs and releases were different on how they handled reorgs. Hmm....
Anyways...in the end it was find what customizations I had done, and apply those changes to the 5.0.5 code. Though I later found that there is now a place in the 5.0.5 code to insert custom data instead of editing the _html_header.inc.php and _body_footer.inc.php. Wonder if I'll go back and try that. Currently, that only affects one skin. The other skins I use, I made copies of so I'll may need to see if they need to be brought up to 5.x. One of the custom skins is based on one that comes with b2evolution, but I've changed it so heavily that it was kind of painful patching it as part of every upgrade....until I went with making it separate. Don't know why I didn't do that with all of them. Though the other skin I may or may not need to update is not one that comes with b2evolution, so it may or may not have been updated for 5.x. Especially, since the current is for 3.x.
Kind of frustrating thing with b2evolution....the lack of current 3rdparty skins and plugins for it.
...to inject bad SEO and links into Google. And, possibly collect info on my visitors?
Not entirely sure how it got in...the timestamp of the affected files is Apr 1, 2012. But, that was also the date that I upgraded to version 4.1.3, previous version was 4.1.2 done on January 16th....before that I was on 3.3.3 (Feb 14, 2010).
I do weekly backups of my site, so I narrowed down the alteration to having taken place between May 21st and May 28th.....though it wasn't easy...since I expire stored backups after 6 months....though fortunately I still had backups of my backups, so I could go back to before April 1st...and see that the file did change between March 26th and April 2nd, but php code wasn't prepended until later.
Perhaps I need to keep up on updates closer...
In the 4.1.0 line, the release dates were:
2011-09-08 - 4.1.0
2011-10-03 - 4.1.1-beta
2011-11-02 - 4.1.2
2012-03-02 - 4.1.3
2012-04-03 - 4.1.4
2012-07-24 - 4.1.5b
2012-11-23 - 4.1.6
Currently anything less than 4.1.6 isn't recommended. I see that 4.1.4 contained fixes against SQL and JS injection. Hmmm....
Wonder if I need to do some kind of change detection to my backup process....
Its hard to upgrade when there aren't diff bundles (which is why I stayed at 3.3.3 for so long), though I'm getting better at keeping my customizations out of the core (or fixing bugs on my own...) Plus discovering Meld has helped as well. Was interesting that one time, it showed diffs between releases, but no diff between latest release and my version. The bug I fixed got fixed the same way.... Though I think I have Meld ignoring differences in end of line and white space.... since the distribution files are CRLF, and I'm on Linux/FreeBSD...and the files are apparently such that vim can't figure out if its DOS and hide the ^M's or not.
Hopefully the upgrade to 5.0 will be simple...
In the history of my site...I was on 0.9.2 on June 7th, 2006 (released May 22)....from 0.9.0.12 on July 23rd, 2005 (released May 6). And, then finally upgrading to 2.4.1 on April 27, 2008 (released Mar 16), though prompted in part because I switched hosting providers....worked up to 2.4.7 on September 6, 2009 (released May 27)....and then to 3.3.1 on September 8, 2009 (released August 8). I did the upgrades to 3.3.2 and 3.3.3 on February 14, 2010 (3.3.2 was released Nov 9, 2009 and 3.3.3 was released Dec 15, 2009).
Guess it was good that I have my sites with Google's Webmaster tools...so that it could send me a "Notice of Suspected Hacking on ..." and stopped crawling my site until I address the problem.
And, looks like only my sites that are b2evolution were affected, my other sites are also 4.1.3 and hadn't been upgraded since.... Though its strange, since those sites were setup with fewer customizations with the intent that upgrading them would be easier. But, I had been thinking of shutting down the sites....
Pages: 1· 2
From 4.1.3 to 4.1.5b.
Maybe I'm getting better at these small patches, because it didn't seem as hard to do. Or perhaps because I was able to figure out my own customizations and back patch them into the patch or that I'm getting better at where I put my customizations....
Plus one of them matched one of the patches....resulting in just shifts in line spacing and newer comments.
Though was getting worried considering I put off applying 4.1.4 so long that 4.1.5 came out, and became 4.1.5b. Though I would have to do them separately, but then it occurred to me that if 4.1.5 changes anything in 4.1.4 it'll overwrite those files. So, all I had to do was three-way diff and figure out what from mine goes into 4.1.5b and lay that down on top.
Though I did see that I have files that don't exist in either 4.1.3 or 4.1.5b...probably left overs from much earlier 4.x versions. Though was surprised to see that a plugin was newer in 4.1.3 than in my version. Not sure how that got overlooked until now.
There's other plugins that need updating, but I'll do that later....
Some how I screwed up copying the diffs over top of the site, so that when I put the new index.php...it didn't work. But, the updated conf files made it. (backpatching the multidomain stuff)
Oh I see what I did....I had copied into the top level the other dirs the first time.
Guess I need to clean that up before calling it done.
Stumbled on the domain name, by chance....just typing Chen variations that might work as a new site, and .ws (web site) was offered as an available suggestion. After mulling it over for a while...and then finding 'cause to move lhaven.net, I threw in the order for the new domain while I was at it.
After the upgrade from 3.3.3 to 4.1.2, I was troubled that I wasn't seeing submission responses for reporting spam to b2evolution's central antispam blacklist.
I finally dug into the code this morning...and figured out the problem...here's my quick fix:
This is because in the "blacklist_locally" section it says:
// We have EXITed already at this point!!
I suppose the alternative is that local backlist and reporting are mutually exclusive, so don't blacklist locally if you want to report? Though the interface should reflect this.
Wonder if this is why the amount of data coming from the antispam blacklist each week dropped off a lot in the last year or so....while the amount of spam has been ever increasing....
So, following the upgrade of my other b2evolution site from 3.3.3 to 4.1.2, and having the burst of wakefulness when I should be going to bed...I decided to start updating this site to 4.1.2.
I think I was almost done, except for updating my custom skin...but I forgot. If that's all I had left or if there was something else. But, I uploaded what I had done. And, figured I'd get some sleep and switch over in the morning....
Well, I switched in the morning...and it didn't go as well.
I had forgotten to update my skin, plus not all parts of the site (only one), was actually using my custom skin. The rest was pointed at the former custom-custom skin. Which had been updated when I overlaid 4.1.2...so it wasn't right. I switched everything else over...and that kind of go things working.
But, I wanted my customizations to the current custom skin....so I noted the diffs, and applied them to the new skin. Some of it worked, some of it didn't...the rest of it was just a mess.
Turns out some of the div classes/ids had changed, so my dynamic elements couldn't find the elements it needed to make things work. At least it didn't blow up. Also the css changed...so I had to figure out how to remake the tweaks I had done before. The stock custom skin is a fixed width skin, while my custom skin is a variable width skin. So, there were css elements that don't work in a non-fixed situation.
Now that I had upgraded, I wanted to check out some new-ish plugins. Main two, reCaptcha & socialbuttons. The old captcha image plugin had broke a long time ago...and I don't know why I didn't replace it. I turned off the broken parts at least.... Don't know how well the new reCaptcha works or doesn't work... registered users are exempted Hmm, I seem to have fewer smilies, I only added back in the ones that I had added...didn't diff to see what had changed between 3.3.3 & 4.1.2....perhaps I need to now.
But, next up was the socialbuttons plugin....that required a bit more work to get working .. you can read about it here.
Meanwhile, now that the twitter plugin is working, wonder if I should turn off twitterfeed? The new b2evolution, does a sort of url shortening, but its internal...doesn't use my Yourls service, like twitterfeed does.
And, it seems notification is or something core is broken.... because I'm getting emails from cron_exec.php
This being Cyberweek...I tried to cram some stuff in other than just recovery from Chicago Tardis into this week.
Though I haven't actually gotten to all the things yet...I felt that I should start this post before I forget all the things I wanted to cover. Too late
Anyways...one of the important items was new CO detector. I used to have a First Alert CO400?, battery operated CO detector that took a couple AA batteries and didn't do much else. I was looking to buy something like it again, except reading the negative reviews on amazon.com... a number of other people were complaining that unit disintegrates when you try to change the batteries. Which is why I was needing to replace my old one. So, I decided that maybe I would look at a different brand this time around.
Also noted that these things have like a 5 year life expectancy...though my First Alert CO detector was only a year old. I noticed that Kidde CO detectors claim a 7 year life span (though only a 5 year warranty). Though (in part due to Amazon 'recommendations') I got the Kidde KN-COPP-B-LPM, which has a digital display....showing current CO levels and historical levels, etc. Which I debated on whether I would want to know if there was a CO level, that wasn't alarming.
Don't know if I paid attention to the fact that it uses 3 AA batteries....one odd thing I've noticed, is that it doesn't say if I should replace batteries regularly....but I suspect it'll be part of the same routine with replacing smoke detector batteries.
Though I don't think I'll replace the CO batteries along with the smoke detector ones on December 25th (because of long DST, I had changed my bi-annual to be on or around June 25th and December 25th.) Though, I've already replaced the battery early in one of the smoke detectors. Odd, because there hadn't been any nuisance trips in some time...and it isn't one that is typically set off by these situations. (usually ones that nuisance trip is the detector in the living room [near the kitchen or the first bedroom from the kitchen. Yeah...something I'm burning on the stove or in the microwave is usually the cause.)
But, getting a new set of 4 9V batteries was something I got in my recent cyberweek purchasing...
Latest Poopli Updaters -- http://lkc.me/poop
|<< <||> >>|
freebsd lhaven linux virtualbox voip zen «doctor who» upgrade tivo «hd movie» ubuntu eyeglasses usb «watch instantly» amazon.com ebay raid1 «sans digital» replaytv batteries box «chicago tardis» newegg 10.04lts raid ups prescription «windows 7» orac «amazon prime» «instant streaming» tardis «air purifier» netflix cpap twitter dvd appletv mdadm cox dsl boinc cfengine3 «windows xp» b2evolution woot backuppc «tivo hd» tv «powersource 400»