Using jUpgrade

Details

Category: Content Management Systems

Published on Sunday, 17 February 2013 18:37

I’ve upgraded a few sites lately from Joomla! 1.5 to Joomla! 2.5 using jUpgrade. The upgrade from 1.5 to 2.5 isn’t exactly an upgrade, it’s more of a migration, so you really have to use tools like jUpgrade to make it work.

JUpgrade installs as a Joomla! Component and adds its own options to the Joomla! Components  menu. It essentially downloads a version of Joomla! 2.5, installs it in a sub-folder from your original Joomla! 1.5 installation then copies ‘all’ of your stuff to the new site. At the end of the rather quick and painless process, you have two copies of your Joomla! site; one in the site’s original location and another in a sub-folder called ‘jupgrade’. You maintain access to your original site, but have this new version to work with to test to make sure everything migrated OK (it didn’t, trust me) and to upgrade your template, extensions and so on. Chances are your Joomla! 1.5 template won’t be compatible with Joomla! 2.5, so no matter what, you’ll have to acquire, install and configure an updated template in your upgraded (migrated) web site.

You may have noticed that I said above that everything won’t migrate correctly – that wasn’t a complaint, simply a statement of the truth. jUpgrade is amazing considering what it does and how much it costs (it’s free). Unfortunately, there’s so many plug-ins, components and modules available for Joomla! that there’s no way for any migration tool to be able to accommodate everything which might be running in your site.

The developer(s) of jUpgrade have done what they can to accommodate the most popular options, but after the conclusion of the jUpgrade migration, you’ll have all of your articles, categories and menus copied over into the new site, but not much else. When you go into the new version of the site, you’ll have to start adding back your extensions and putting everything back where it belongs. It’s a challenging task, but I found it to be a fun process. It forces you a chance to rethink your site’s structure, layout and configuration – and ultimately my ‘new’ sites look nothing like my original sites when I’m done.

What Didn’t Work

Having migrated three sites, I thought I’d fill you in on some of the things that simply did not migrate properly using jUpgrade.

Categories

The first thing I noticed was that Joomla! article categories got copied over to the new site, but didn’t work correctly. In some cases, I had to go in and edit then save each category before things would work correctly. In other cases I found that my top level categories were setup as sub-categories to the Uncategorized category. Either way, expect that you’re going to have to do some work on your categories before you can go live with your migrated site.

Newsfeeds

I also noticed that on several of my migrated sites, any Newsflash Module settings don’t make it across correctly. In several of my sites, I had a newsflash module rendering a random article on part of the site. After the migration, that module was still there, but was configured to show many articles in a particular order – rather than the one article with random as I originally had it setup.

SH404SEF

I use the SH404SEF SEO, analytics and security module from Anything Digital on several of my sites. I noticed that during the jUpgrade migration process, something goes wrong and SH404SEF stops working correctly. For this site, I’ve not been able to resolve the issues I have – even with support from Anything Digital. If you look at links on this site, you’ll notice that I have the external link symbol appearing to let you, my readers, know when I’m sending you somewhere else. It’s a feature of the SH404SEF component and I like it. If you look at some of the articles that precede this one on the site, you’ll notice that some links (but not all) that point to external sites have the symbol but not others. I can’t figure it out nor can I fix it.

Recommendation is to completely uninstall SH404SEF before starting the migration, and then reinstall it later. I’m not sure it that will help, but it’s worth a try.

Going Live

After you’ve completed the migration process and made sure everything is working well on your new site, migrating from the old site to the new one is quite painless. Simply delete the old site’s files (I download them first, then copy them to another folder on my server – can’t have too many copies) then copy the files from the jupgrade folder to the original site’s folder. With that done, you’re all set – just be sure to test everything before you decide you’re done.

After you’ve made sure everything is working OK, go into your MySQL manager and open your site’s database – you’ll find two sets of tables there, your original Joomla! tables plus a new set created by jUpgrade. It’s not required, but you will want to remove (drop) the original tables when you’re sure the new site’s working as expected.

Ignoring Mobile Email clients

Details

Category: Mobile

Published on Saturday, 09 February 2013 14:16

I’ve always been surprised at how major brands and larger organizations ignore smartphone users in their email blasts. I’m an American Express customer and get email promotions from them on a regular basis. When I open one of their messages, I see something similar to the screen shot shown below.

Figure 1

Everyone seems to think that you have to have lots of color and everything centered in an email blast, but at the end of the day that simply doesn’t work for mobile users – and I have to imagine that many if not most users read these types of emails on their mobile phones exclusively.

I need to do some testing on this, but since the email is in HTML format, can’t it do some work to understand the viewport it’s displaying in and adjust accordingly? Mobile users should not have to scroll past a bunch of junk to get to the content and the content should never be centered like it is in the screen shot. That email is useless to me and I simply can’t read it on my mobile device without scrolling around to view the content. If I’m reading on mobile, I should see all of the content flush left with natural wrapping.

In my mind, BlackBerry was the worst offender – take a look at the following screen shot. This was taken a while ago, but it was an email to BlackBerry users, with specific instructions that the message would look best on a desktop computer. At least they moved the content to the left margin so the email is at least readable on a mobile device.

Figure 2

Carrier APIs

Details

Category: Mobile

Published on Thursday, 07 February 2013 07:57

I have to admit that I simply don’t get Carrier-specific APIs. I used to work for RIM (now called BlackBerry), working with their largest carrier and later on worked at that same carrier. I know how desperately the wireless carriers don’t want to simply be a pipe (provide me with network access) – but instead want have all sorts of value-add products they can sell you. At the end of the day, all I want them to be is a pipe and I’d gladly pay them more money per month if they’d simply give me a wireless network connection for my devices and let me use them any way that I want to.

I know it costs a lot of money to create and maintain the wireless networks, and I know that some users use more bandwidth than others (iOS users vs. BlackBerry users for example), so just go ahead and charge me based upon how I use your network.

Anyway, I was at the AT&T Dev Summit last month and saw some interesting things there. AT&T has been working with Sencha and others to create a suite of APIs that mobile app developers can use in their applications. There’s some pretty interesting location based services (LBS) APIs available, plus services around SMS, billing and so on that could be pretty useful for mobile developers.

The problem is that these APIs are available from a specific carrier (the LBS APIs are a global product, available for most carrier’s devices, but in this case AT&T has their own ‘branded’ version of the service). If I’m building a mobile application, I don’t benefit from leveraging APIs that are usable for only a subset of my available customers. If I’m going to build functionality in my application, I have to be able to use it over all customer devices – having to implement a different system depending on which carrier a customer is on is inefficient and too expensive to implement for many smaller development shops.

In the Dev Summit keynote, one of AT&T’s partners demonstrated an application which allowed an application to type in their phone number then the application retrieved the mobile user’s account information from the carrier.  If you know all of your customers are on AT&T, then the API is useful, but I expect that the number of cases where that is true is…zero. That makes that particular API pretty much useless. On top of that, the demo included the user typing in their phone number, why? They were showing a native application running on the iPhone; native applications know (with the appropriate permissions of course) what the device’s phone number is. How are you helping me if I need to type in my phone number before you retrieve my account information from the carrier?

Use the local API to determine the device’s phone number then populate the rest of the form with the data from the carrier. I imagine they did it that way to demonstrate that all that was needed was the phone number in order to populate the entire form, but it was a silly demo.

What’s needed is a common, cross-device, cross-carrier on device app and API that allows a user to define common information about themselves (name, address, phone number, credit cards) then make it available to any application that asks for it (with the appropriate approval of the user of course). Then, when I get the device, I enter in all of that information once then any app I authorize can access that information. If I don’t authorize it, there is no reason the local API couldn’t simply prompt the user for authorization when needed. That would be a much easier system for mobile developers to implement and much less work for the mobile user. Everyone wins and there’s no need for cloud-based, carrier-specific APIs.

Too Many Eclipse Instances

Details

Category: Mobile Development

Published on Monday, 04 February 2013 08:29

I’ve been doing some more mobile development lately – building some applications on the SAP Mobile platform (what was formerly known as the Sybase Unwired Platform) and therefore cranking up some development environments for Android, BlackBerry and even iOS. In preparation for this work, I was updating my Eclipse instance on my Mac Mini plus creating a new Windows VM with Eclipse and all of the tools I needed. One of the things I noticed is that the whole concept of Eclipse plug-ins is essentially broken when it comes to mobile development.

Let me explain…

The Android development tools embraced Eclipse early on and worked very hard to make sure their stuff simply ran on most any version of Eclipse out there. There were some initial incompatibilities with the Java 7 SDK, but that’s to be expected with a big version upgrade for an underlying technology like Java, and although the Android SDK installer wanted to install its files in the Windows Program Files folder, that rarely worked. At the end of the day though, the Android SDK fit nicely into most any version of Eclipse.

I just downloaded the latest version of the Android SDK and noticed that the installer was gone (not sure I’m really a fan of that) and there was a new folder included in the download with a complete instance of Eclipse. OK, so Google’s now telling us that they suggest that you do your Android development with their instance of the Eclipse IDE.

The BlackBerry Java SDK is fickle, very fickle. Even though the Android DSK has embraced most any version of Eclipse, with the BlackBerry Java SDK, it supports only Eclipse version 3.7 (https://developer.blackberry.com/java/download/requirements/). That wouldn’t be that bad, except that 3.7 is pretty old. So, imagine you’re using the latest and greatest Eclipse stuff to do Android or some other development, you’re going to have to maintain a completely separate, older version of Eclipse simply for BlackBerry development.

Here’s some screen shots of what you get when you successfully install then try to run the BlackBerry Java development SDK in a current version of Eclipse.

• Eclipse 1 Eclipse 1
• Eclipse 2 Eclipse 2
• Eclipse 3 Eclipse 3
• Eclipse 4 Eclipse 4
•  

What was particularly maddening about this particular problem was that the error messages about the pre-processor configuration are cyclical, the one message appears, then you’re prompted to restart Eclipse then the error message appears, then you’re prompted to restart Eclipse. It never ends.
Notice too the error messages about missing a DLL? Unfortunately, that error was generated on a Macintosh – not sure there’s a lot of DLLs on a Mac.

The IBM Worklight developer tools have similar restrictions – I downloaded the trial last year and was having fits trying to get it to work. I expect everything to be like the Android tools – simply work in most any version of Eclipse, but after struggling with the Worklight plug-in installation, I finally looked at the system requirements and noticed it too only supported an older version of Eclipse.

The SAP Mobile Platform (SMP) tooling uses Eclipse 3.7, so it’s really easy to setup BlackBerry and Android Java development environments within the SMP development tools. At the end of the day though, you’re still setting up a separate environment just for SMP development – and adding yet another Android instance to your configuration if you want to do both Android and BlackBerry development in the same IDE where you’re doing your SMP development. I would be happier though if SMP was a plug-in as well, rather than a complete IDE installation like it is today.

The moral of the story is that it simply shouldn’t be this hard! Google’s making the investment to make their stuff work in most any version of Eclipse – how hard can that be? RIM (now called BlackBerry) and IBM I imagine have to have similar sized development teams, why can’t they build Eclipse plug-ins that just work? Granted BlackBerry has been really busy with BlackBerry 10, and has essentially abandoned Java development, you’d think they would want to make things simple for their developer community.

With so many of the mobile development vendors supporting restricted versions of Eclipse, developers can’t truly benefit from the plug-in capabilities of Eclipse. Either Eclipse has made making compatible plug-ins too hard or these mobile development tool vendors or the vendors are simply not trying hard enough. I’ve never built an Eclipse plug-in, so I really can’t say. At the end of the day though, what’s the value of an IDE with a plug-in architecture if I still have to install and maintain separate instances of the IDE just to use different plug-ins?

If you’re not going to do that – at least make the system requirements more visible so that people like me who don’t go looking for the system requirement before installing an Eclipse plug-in can know that what they’re trying to do won’t work. Why not include the supported eclipse version in the plug-in name?

Better yet, why not simply include version checking into the plug-in installation process? Let me know during installation that the plug-in is not compatible with the version of Eclipse I’m running? That would seem to make sense – why let me install something that you know is not going to work?