Lewis' Blog Tales from the trenches of information technology


Working around the broken RSS feed code in Joomla! 3.2

I'll probaby backfill some more tips & tricks I've picked up this past week, during an upgrade of a client's site from Joomla! 1.5.22 to 3.2, but in the meantime, as this seems to be a nagging bug (well a collection of them; not necessarily a swarm or even a hive, but a colony, nonetheless), I figured I should get something posted about it to hopefully save someone else an hour or two of poking (and testing modules to just replace the built-in feed module, anyway).


Yet another method to grab download-disabled slideshows from SlideShare

Yes, I know. Horrible, horrible subject. The thought of stealing jpgs which are publicly viewable... Oh, well.

Standard disclaimer applies: Teaching someone how to steal a book does not make the teacher guilty of theft. If you get in trouble for following these directions, shame on you, not on me.


WordPress, WooCommerce, and the elusive WP_MEMORY_LIMIT issue

WooCommerce (and likely some other WordPress plugins - and non-WordPress apps - tend to be rather microcosmic when determining system settings. Case in point: the PHP memory limit.

Prior to PHP 5.2.1, the per-script memory limit available was set at compile time (via the --enable-memory-limit option). With 5.2.1, we got the php.ini directive:

memory_limit <integer>

to set this value at run time 1. In fact, it can even be overridden (if the server admin allows) so that specific apps may set it themselves, thus allowing for greater granularity across all running PHP applications on the server, even under the same instance of the engine.

  1. http://www.php.net/manual/en/ini.core.php#ini.memory-limit

Still more PHP 5.3 fixes for Joomla! 1.5

When you're on a roll, you're on a roll...

Almost done patching this particular old rowboat. This installment deals with quieting this bit of error log noise:

PHP Deprecated:  Function eregi() is deprecated in blahblah\components\com_htmlmap\views\htmlmap\tmpl\default_map.php on line 20


Updating the TCPDF library in Joomla! 1.5

TCPDF is an excellent PHP class for creating PDFs from dynamic (or static, for that matter) web content. Unfortunately, the version of TCPDF bundled with Joomla! 1.5 (all 1.5 releases after at least 1.5.8 - someone please correct me if I am wrong - was version 2.6.000_PHP4, dated March 7, 2008. It's also not very PHP 5.3-friendly (there are other parts of Joomla! 1.5 which are not fully compatible with PHP 5.3, but this article will focus on TCPDF). Time to freshen up, methinks.


A sincere apology to users of my YUM repo mirror

You see, it all started in January, when I decided to do a good deed (I should have known better). I set up a YUM repository mirror for Netlabs.org, as OS/2 now uses RPM and YUM for (some) package management (I have a post in draft on that whole issue). It turns out, however, that for reasons which I shall explain, the xml (and related) files in my mirror weren't getting updated, so while I was doing a great job of adding content, I wasn't updating the repo information, so subscribers had no idea.

So, for all of you out there who have come to rely over the past couple of months on my US mirror of the Netlabs YUM repository, I most humbly apologize for the inconvenience. It's fixed now, though.


Mantis email fun – part 2

Well, this is embarrassing... I can't believe I started this draft back in January (of 2012), and let it sit so long. Sorry about that...

You may read up on my involvement with a particular Mantis Bug Tracker installation in part 1 of this series. This time around, I'm going to discuss adding the ability to discourage email recipients from replying to bug update announcements.


Multiple default routes / public gateway IPs under Linux

I recently had the need to configure a server for a client with multiple public IPv4 addresses routing to the internet and the requirement to switch between them at will while browsing (http traffic only).

There are a number of articles available on the net dealing with this type of situation, mainly focused on using iproute2, ToS tagging, and Squid (see references, below). However, I bumped into an issue with openSUSE 12.1 where it would stubbornly refuse to accept certain (otherwise valid) ToS (DSCP) values (see https://bugzilla.novell.com/show_bug.cgi?id=770785 for my bug report). This severely limited the number of possible values I could use, and thus, the number of possible public IP addresses.


Unloading an unloadable NLM

One of the frustrating things about NetWare has always been its distinct lack of a decent process killer. Part of this was perhaps over-confidence on the part of Drew Major (and others), thinking that we would never need a process killer because there would be no such thing as a runaway process on NetWare. Another (good) reason might be that killing a process can sometimes be as risky as letting it run, even if it runs until the next server restart.

With NetWare 6, we got a fairly useful bash implementation, along with some standard utilities (grep, egrep, fgrep, cat, etc.). We also happened to get kill and killall. Now, the problem with kill is, of course, that one needs a process id to feed it. Naturally, among the things we lack is a port of ps (don't ask me why!). Trying killall results in a slew of public symbol errors (at least for me). So, what to do?


On the over-use of HIGH PRIORITY in email today

For those of you who may not recall, the Priority: header was originally designed for mail servers to properly prioritize the routing of messages in the days when broadband meant 256K (wow!), and it was customary to move batches of mail from one place to another at different times, such that a notice about a meeting taking place next month would be assigned a lower priority than, say, a message concerning the temperature in the boiler room (reference to nuclear reactors specifically avoided, as the situation in Japan is non-trivial and surely not humorous - as several comedians have recently discovered). The Priority: header is/was analogous to the X.400 priority field. (For references, see RFC 2076, 2156, et. seq.)

Along came our good friends in Redmond, who decided that an X-MSMail-Priority: header was important, too, so that (idiot) users could jump up and down and yell "FIRE!" in the movie theaters...er...so that Outlook (Outbreak) users could prioritize their own messages (and of course, an emergency on the part of a client does not necessarily constitute an emergency for me).