Here’s a quick fix:


$_SERVER["REMOTE_ADDR"] ='127.0.0.1';
DebugBreak();


By setting the remote address, the DebugBreak function call will then call the local machine, and appropriately have the connection port-forwarded over your SSH connection.

One additional thought … if anyone has (or can create) an updated version of the DBG bar for Chrome and/or Firefox, let me know. The ones I’ve tried don’t work with the latest version of the browsers. I’d be willing to consider financially sponsoring such a project.

Through my Joomla work, I have influence over 10,000 Joomla 1.5 sites. Of these, about 200 of those sites are direct (or nearly so) clients of mine that I’ll have to upgrade if the time comes.

Unfortunately, the migration to Joomla 1.6/1.7/2.0/2.5 is not a very compelling story. Most of these clients have sites that work today, and while they are looking for incremental improvements, they are not looking to rebuild the site – pretty much ever. They are definitely not interested in losing functionality (due to incompatible plugins) or actually paying for such an upgrade. I need help in solving this dilemma – one that lessens or eliminates the impact of migration.

The Economic Impact of Migration

Let’s assume there are around two million Joomla websites, and nearly all of them are running 1.5 and plan to upgrade. Also assume that each migration will cost the client, on average, $250 to migrate by the time all is said and done. We’re looking a 1/2 billion dollar impact to the Joomla community. Halve both numbers, and a conservative estimate is $100 million impact. Not small change in any book, I’d imagine.

Other than “security concerns” because 1.5 isn’t being supported, what are the main reasons to upgrade current systems? Amy Stephens states, in her blog post about Molajo:

Because it sets the foundation for tighter integration through common events and creates an extremely extensible layout system adding in alternative layouts and alternative menu items. That is on top of ACL and nested categories.

Many of these same benefits: An extended API, tighter event integration, better menu management, a superior ACL model to what is in 1.6+, and even a better category system can be done in a way (in many cases backporting current 1.6 code directly) that does not eliminate compatibility with the 1.5 API, keeping current extensions working and not requiring a migration or break existing sites. This is what WordPress does on every release – it moves forward without (for the most part) breaking anything, and never requires a site-rebuild or “migration”.

What I’d like to say to my client is, “no, you don’t have to move off your current platfom” – and not even mention that any upgrade is required, just an option. If I don’t have an alternative, and force the move for the clients, I’m going to lose some Joomla customers to WordPress (even a few to Drupal), and very possibly lose some customers entirely. I know from talking to other webmasters that I’m not alone in this dilemma.

As I see it, there are three related issues that need to be addressed to keep Joomla! 1.5 viable going forward:

#1) Joomla 1.5 core support needs to be extended significantly past the April 2012 date. (security patches)

#2) Extension developers would need to commit to continuing to support the 1.5 API, for now and in the future.

#3) For long term viability, I’d love to see the Joomla! 1.5 core enhanced with significant new features, in a backward compatible way. Minor changes to the API, similar to what Molajo has done with 1.6.

I’m willing to contribute however it makes sense to do so, in collaboration with others of a like mind.

Joomla is a community project. Is it possible for the community to commit to supporting the current Joomla 1.5 API and extensions, and if possible, continue to improve the 1.5 code base in a backwards compatible way? Or are there other solutions I’ve missed?

Having just returned from Wordcamp Louisville 2011, I’ve come to respect WordPress … and the organization behind the software, even more. So much so I’m sure I’ll be doing much more with WordPress in the future. I already have two of my marketing sites running on WordPress (Integral Research and Hermes Mobile), though Joomla 1.5 is still my CMS of choice when doing complex, custom applications.

A shortcode is a WordPress-specific code that lets you do nifty things with very little effort. Shortcodes can embed files or create objects that would normally require lots of complicated, ugly php code in just one line. Shortcode = shortcut.

With this plugin, you can use the same API in Joomla.

Check out the Shortcodes for Joomla project page for documentation and download links.

I’d love to hear your thoughts on the project.

There’s been discussion about the Joomla! version release numbering scheme, and the current thinking about how the next version is to be numbered. Below I present a case for using either 1.8 or 2.0 … either of which logically follows the current 1.7.  I present the idea that jumping directly to version 2.5 will create additional and unnecessary confusion inside and outside the Joomla! community.

I read the reasoning, I understand it, and I don’t agree with it. And here’s why.

I sell Joomla! into enterprises on the cloud.  These companies are already somewhat fearful of “open source”, and need to see some consistency in order to be comfortable. They are used to traditional numbering schemes with major / minor / release versions, and are mostly comfortable with that scheme – as is the rest of the development world.

I argue that 1.7 -> 2.5 doesn’t make sense, except for what seems to be an arbitrary decision that no one outside of the Joomla! community knows. The fact is, people generally don’t expect  a x.5 version to be the LTS release. People do expect version numbers to be consistent, and not to arbitrarily skip versions. For both reasons, it seems to me that the next version should not be called “2.5″.

Here’s the way it works for most software, and the way it could work for Joomla!:

- Major versions are just that – major upgrades, that require significant effort to upgrade (new extensions, database update, etc). Components should mostly work within each major version, without upgrade.
- point releases are usually minor updates, not requiring  major work to upgrade and for the most part being backward compatible. Introducing new API’s an functionality here is fine – just don’t break existing components.
- sub-point releases are just new builds and updates, generally security and bug fixes, and should always be backward compatible.
- LTS releases (Long Term Stability) can come wherever you want, though usually at a specific major release (like 2.0). Just mark it”LTS” when you’re ready, and be done.

Yes, there are exceptions to these rules, but they are standard enough that many organizations actually require management approval to move from one “major” version to another.  When confronted with Joomla!’s numbering system, confusion prevails, and some organizations require management approval /testing / shakeout period for ANY Joomla! upgrade (this stems in part from some seriously bad releases in the 1.5.x series)

Let’s go back to the beginning and look at the way Joomla! could have been numbered:

1.0 – Great, it was mostly a revamped Mambo, but starting with 1.0 is usually not  a “bad” idea. Though from a maturity standpoint, Joomla! 1.0 was really closer to a 5.0 product.
1.0.1 – that was good, all releases were extremely minor, and broke very little backwards compatibility. These releases were fine, though I think we all wished for some additional movement forward in those days.

1.5 – this is where things got screwy. It was NOT a minor update, rather a rewrite and losing compatibility with Mambo.  This needed to either follow Java numbering system, and been 1.1 – or , considering a “database migration” was necessary rather than just an update, and it became later a “LTS” release, this probably could have been 2.0 LTS. I prefer the 2.0 LTS route, and will stick with it in the rest of the discussion.

Note that there was a big debate on whether a specific version of Joomla! (1.5.16? I forget) that  upgraded the core mootools version should be included. Using the proposed numbering system, that could have become J! 2.1 in  the proposed scheme … a point release being more than a bug fix, but less than a full, incompatible, release … similar to what we have in 1.7 today. This could have also been a point release with php 5.3 compatibility was introduced.

1.6 – a black sheep, with short life cycle, yet a full “migration” was needed, so this could have been version 3.0,

1.7 – for the first time, a point release of Joomla! not requiring a complete database migration, this was the  best candidate for a point release so far. I call it 3.1

Next Version – Do we have to “migrate” our sites? Do components cease working as they did with 1.5 and 1.6? Yes – then this needs to be a major release, esp. since it’s a long term release. Given my numbering scheme, it either becomes 3.2 LTS or 4.0 LTS, completely depending on whether I can use my existing extensions with it, and whether or not I have to “migrate”. The reality is that it will probably be 1.8 LTS (if compatible with the current 1.7), or 2.0 LTS, if not.

The idea of numbering Joomla! LTS relases “x.5″ should be dropped. Where that came from, I can only guess. But continuing it means that there will always be a time when Joomla! arbitrarily jumps from it’s current version “up” to the nearest .5 … skiping a major release opp (like 2.0).  And, what happens if we were ever to get to, for example 3.4 and wanted to go to 3.5, without doing an LTS?

There’s no way to to read the future, and arbitrarily saying that a specific minor release is a “stable” and long term supported release is a certain way to guarantee more weird numbering schemes and skipped versions for the lifetime of Joomla! – resulting in continuing confusion and missed opportunities.

Given where Joomla! is and the numbering decisions made to date, the key question seems to be: a) is a database migration required and b) will all current 1.6 / 1.7 extensions continue to work? If yes, then this release is 1.8 LTS. We can wait on 2.0 until more functionality is available, and have a killer 2.0 launch party.

If not, and another migration is required, then this version is Joomla! 2.0 LTS . We still have a killer J! 2.0 launch party and a major marketing event.

Or, use the numbering scheme above, and let’s jump directly Joomla! 4.0 LTS (which really is where Joomla! is today), and leave all the numbering mistakes behind. Let’s let the Joomla! team take credit for the awesome work put into 1.5 and 1.6, and put Joomla! stability wise where it is … as  mature, 4.0 product (or 8.0, if you want to consider the Mambo roots).

When I say to a potential client, “think of it this way. Joomla! started out as Mambo, when they forked, it became Joomla! 1.0.  The next version, still used today, they called that version 1.5 but think of it as 2.0.  Joomla!’s 1.6 release was also a major update, think of that as 3.0, but 2.0 is still being supported for the next few months. The latest Joomla! is what they call 1.7, but is really a minor update and “just works”, think of that as 3.1.  It’s the latest, but not all extensions support it yet – though they should in time. So we’re really looking at the choice between using Joomla 2.0 and 3.1 for your site, and here’s what the differences are …”.

People get that, though sometimes I have to draw a chart. They understand “big” update vs. “little” update. They don’t have to be told that extensions working on 1.0 have to be updated to 2.0 and again for 3.0, and that for the most part, stuff just works between 3.0 and 3.1. Such a numbering scheme makes sense and imparts valuable compatibility information.

Compare that to what seems to be the arbitrary: your 1.0 extensions will work on 1.5 (kind of), 1.5 extensions won’t work on 1.6, but 1.6 extensions works on 1.7. We don’t know about the next version, yet. [Then I have to answer the inevitable: what happened to 1.1, 1.2, and 1.3, and 1.4?]  It becomes a thought process no one really wants to have, and can help dissuade people from even using Joomla! (due to perceived uncertainties that aren’t there in reality, but are introduced by the current arbitrary numbering schemes.

Going directly to Joomla! 2.5 is, in my opinion, even worse – confusing for everyone the Joomla! community is trying to communicate with. Especially if for some reason 1.7 extensions actually work on the next version (and I hope they do).

What I would like to see is a numbering system follows industry best practices and that is easy to understand.
a) I don’t have to database migrations between minor releases
b) extensions mostly work between minor releases

To solve the LTS issue, Long Term Support releases could be designated simply by the term “LTS”, regardless of the version number at the time of release.

This is opinion, and I’m sure some will dissent. I welcome open discussion, here or on twitter.

In doing so, I’ve had a chance to revisit many of our service providers, including AWeber (aff.).

UPDATED: 12/28 … it’s a currently a reporting interface.

Further to my post, “AWeber Needs an API“, it seems that now AWeber HAS claims to have an API!. (nearly) Awesome.

Being one of the first to port our current systems to the presumably better and more stable API (vs. the email parser) would be killer.

Stay tuned as I explore the capabilities of the new AWeber API and report on them.

UPDATED: The api information is actually pretty easy to find at http://labs.aweber.com. Unfortunately, it isn’t usable for much as-is.

I think this interface is more aptly called a “reporting interface” rather than “programming interface”, because in reality all you can do (right now) is create reports – you can’t actually program anything.

From the site:

The 1.0 release of the AWeber API is the first version of this system made available to our customers and developers. Currently, only read-only access is supported; however, the ability to modify account data is planned for future versions. Keep an eye on this site for announcements about new features and API upgrades.


In this case “read only” means that while you can look at your data, you can’t actually change anything: i.e., still impossible to an email address to a list, unsubscribe someone or automatically start a broadcast. So, it’s not actually usable in it’s current form to program applications.

That said, AWeber has put in some work to the object model, and in future versions it may be usable for more than trivial applications.

Disappointing, but at least we’re moving in the right direction.

You can click to find out more about AWeber for Joomla! and AWeber for MWG.

Recently, I had the chance to re-visit the need to create a vertical search engine portal for a project I’m working on. I was pleasently surprised to find out the mnogosearch is still one of the “better” search engines for small to medium sized sites – up to a few million documents (though I’ve scaled it well beyond that in the past ;->).

The PHP native extension has recently (late 2010) been updated with new features, and I was able to get it compiled and running – including a few test sites indexed – in just a few hours.

The php example code worked right out of the box. A problem, though, was that looking at the very functional style of coding, it was somewhat difficult to extract what actually was part of the search process and what was UI.

So, as a learning exercise I set out to create a basic “object oriented” wrapper around the extension. While the class is somewhat verbose, it does better encapsulate the actual functions and settings available within the extension.

This directly allows my ide (Nusphere PHPed) to tell me what functions I have available from the class (and underlying mnogosearch extension) directly from the IDE. It also helps with code completion, and makes displaying results in a template very easy.

I’ve uploaded the class, as well as a mostly-complete rewrite to github, you can find it here:
https://github.com/ntemple/Mnogosearch-PHP-Search-Class

I’d call this a “version 0″ piece of code – it works, but hasn’t been cleaned up, and is very much subject to change. The interface needs some features, should be a little more consistent, and the resultset code needs some more options. The updated search.php has a few places that need some work, most notably in [not] handling the cached files nor dictionaries / stopwords. Additional inline documentation could be a bonus improvement as well.

Feel free to clone the repository on github, and I’ll merge changes back as they are available.

If you are using mnogosearch, and if you find the extension class useful, please comment here.

It seems that like Joomla!, WordPress has an FTP mode for when it doesn’t think it can access files.

This manifests itself in a mesage that says: “To perform the requested action, connection information is required.”

If you want to fix the error on your site, take a look at this article on rootzone.net

Here I’ll show you how to disable this “feature”.

Unfortunately, the auto-detection logic fails in some edge cases, particularly in the case of one of my main servers, and what I want to do is to permanently disable FTP mode in wordpress.

After a little digging, it seems that there is a way to tell WordPress to ignore FTP Mode.

Simply add the following line to your wp-config.php file:

define( 'FS_METHOD', 'direct');

Direct is native PHP. Note that you can also use other values, such as ‘ssh’, ‘ftpext’ or ‘ftpsockets’.

So with interest, I’ve been watching the “no SQL” movement and various software and techniques they’ve released.

One problem with “playing” with some of these technologies is that most shared hosting accounts aren’t going to allow you to install the required application servers (for example, redis) on your account.

Given that fact, I’ve implemented a small PHP library that supports the very basics of the Redis command set using … MySQL.

Ok, so the concept is s a total oxymoron, but useful anyway.

It’s not fast, it’s not particularly scalable, and keys are limited to 256 bytes, while data is stored as a long blob. Those limitations asside, it does allow you to play with some of the concepts without any additional technology investment or tools. When you’re ready, you can run a redis server and pretty much drop in the Predis client.

Where possible, I’ve implemented each function in terms of the get / set primitives, with optional mysql locking.

I’m hoping other people will improve the code, remove the reliance on the mysql class, and implement additional features like sets and hashes.

Code is available from git-hub:
http://github.com/ntemple/mysql-keyvalue

Anyway, I found some posts that made me realize … I’ve never fully described the power that our AWeber software has. It really is the best bridge from AWeber to Joomla available. Ok, so as a proud “dad” of the software I may be a little biased.  But really, it rocks.

So I decided to write a post … over at the Intellispire blog … on exactly why it rocks.  And how, over the years, it has evolved from a “scratch” of approximately 12 lines of code to a complex, robust bridge to one of the most popular email services in the world.

Do, spend a moment and hop over to the Intellispire blog and check out this post:
Why the AWeber to Joomla Link (jomlink) rocks.

UPDATE: AWeber has an API!

Let me add one to it: Aweber needs an API.
(an API – or application programmiong interface – is a way for programmers to write software that talks to each other.)

Not only don’t they have one, but they shut people down for “scripting” the form.

Yes, they need the users IP address, but they can get that when they click on the confirm link … like the rest of their competitors do.

Most other autoresponders out there make integration easy with simple API capability: GetResponse, iContact, even MailChimp.

Their alternative “email parser” works – usually. But it’s a pain to setup and seems flaky, not always processing the messages sent to it.
A simple API to add subscribers would sure make things a LOT easier to integrate.

That said, I do have a whole series of Aweber based solutions – mostly for Joomla, but some training videos as well – on the Intellispire site.