In the last article we have discovered that our application is at a dead end: PHP 4 has officially been declared dead, we are facing an increasing number of issues with running our application and our code is cluttered. Maintaining – and probably extending – our application is becoming a task that wastes resources and decreases our teams’ motivation to continue this piece of software.

Now we are facing a simple question: what are we supposed to do to keep our application running and our customer(s) happy?

Rewriting our application

If you have been facing the above issues for a while it may seem appealing to start from scratch and rewrite your application. A fresh start, based upon current approaches, throwing away everything we have. There even is the chance to redefine the application specification.

While this may sound good from a developers’ point of view (don’t developers love challenges), it does not smell good from a business point of view.

• Rewrites are expensive: the teams’ resources will be bound to rebuilding everything from zero, and this is expensive. Man-hours are not cheap these days, and it will be hardly possible to convince the boss(es) to invest more money compared to the current maintenance costs of your application.
• Rewrites are a waste of investments: if your application ran for a few years, there is a huge investment involved. Consider a team of three or four developers and a designer in charge for maintaining an application. It is quite an impressive number of man-hours invested, and the Euros or Dollars (or whatever you are paid in) are not earned easy. After all, throwing investments into the thrash is no Good Thing.
• Rewrites ignore existing achievements: over the years the code in your application will have matured, as you very likely faced most issues that could raise during the application lifetime. This is of value, and should not be left behind. After all it is knowledge you gained.

Refactoring your application

Refacto-what? Code refactoring describes the process of “cleaning up” your applications’ code. By refactoring we refer to modifying our existing code without touching the functionality or any defined API.

Refactoring an application comes with a few requirements for your teams’ knowledge:

• refactoring usually is tied to test-driven development. This means for every functionality you refactor, there will have to be a test defined and executed in order to verify the functionality of the refactored code. It has to deliver identical results, even though coded with a different approach.
• refactoring forces you to revisit all skeletons in the closet. All the pieces of code giving you goose bumps will make a return in your teams’ code editor of choice.
• refactoring code and authoring test cases is different. If your team is used to procedural development, test-driven development may scare your team. Probably they read about unit testing in Java, C++, C#, etc. but unit testing in PHP?

Refining your application

Porting is the most lightweight process to refine your applications. While rewriting and refactoring will include lot of code changes, porting only comes with a few changes.

If your application has been developed with PHP 4 and MySQL 4, you might make the jump and switch to PHP 5 and MySQL 5. Both versions only require minor changes to your code, and the manuals of both applications contain hints:

• Migrating from PHP 4 to PHP 5: the PHP 4 to 5 migration will only require a few code changes. It is recommended to work through the list of backward incompatible changes first.
• Upgrading MySQL to MySQL 5: upgrading from 4.x to 5.x mostly consists of updates for table storage engines, and might require a change of engines, and rebuilding indexes.

Making the changes listed in the manual will require low effort, and can keep your application running for a few more years but it will not give you any benefits if you do not use new features introduced in PHP 5 and MySQL 5.

Summary

As we have seen there are a few options and the difference in effort and cost is huge. Before you decide on an option you will have to evaluate carefully what works best for you. Which option you chose will be different for every application, as no application will evolve equal to another.

In part three of our series we will develop a project plan for breathing new life into your legacy app.

Stay tuned for upcoming articles in “Porting legacy PHP apps ~ The Series.

Comments and feedback is more than welcome, of course.

GitHub finally added issue handling to their service, and I’d like to say: report your issues with phpArmory at GitHub.

As you read through the series, you might see code that could be written differently or improved. At least I do expect you to do so and comment on the articles to refine what I wrote or just tell me that I suck. After all this is intended to help commercial PHP developers, and there are a lot of us out there who would all benefit from this.

What actually is that thing you name “legacy app”?

Speaking of “legacy applications” or “legacy code” as some might say, there comes Wikipedia to the rescue with a broad definition of what we can consider to be a legacy in terms of code:

Legacy code is source code that relates to a no-longer supported or manufactured operating system or other computer technology. The term can also mean code inserted into modern software for the purpose of maintaining an older or previously supported feature.

Simply said, PHP is such a computer technology, and PHP scripts are source code after all, even though some may have considered PHP to be no real development language for commercial applications.

If you’re developing PHP application for a few years now, chances are good that you will have quite a few legacy applications in your companies portfolio and even a few that are still running on servers for your clients. As an example I have picked a PHP application developed for a commercial project which is dated back to mid-2000 when most of the PHP installations still were running a 3.x version of PHP and only a few early adopters made the switch to PHP4. The application is still running on a PHP 4.3.2 installation.

What about your projects?

If you are developing PHP applications for companies which sell services to consumers, chances are good that your application is still running. This is our first checkpoint for a legacy application.

What is the lifetime of your application?

Considering that PHP 4 was released in 2000, any PHP application older than five years can safely be stamped as legacy code. PHP 4.3.0 was released in December 2002, and it marked a point where the 4.x branch of PHP started to replace PHP3 installations in larger numbers.

How large is your application?

If you are using a Linux or Apple server, you can find out how many lines of code your application has pretty quickly. Open a console and enter

wc -l `find . -name *.php4 -print`

Of course, adapt the line for the file extension you used. In my case we had to use .php4 as .php still was pointing to an old PHP 3 installation. In my case this resulted in 312374 lines of code for an application that handles a few GB of user data, and ~300K users per month.

Now if I compare this with an application – written half a year ago – that comes with stuff like unit testing, UTF8 support, full i18n localization, separation of code and views and run the above command line again, I end up with whopping 116229 lines of code. This application does leverage what PHP 5 has to offer and leaves behind functions and language features from PHP 4 which have a replacement with a different approach in PHP 5.

They say, size does not matter. I say: size matters. It’s a combination of technique and size that wins the deal. After all size should be a sign for maintainability. Even if your code is well written, the larger the code, the larger the number of maintenance tasks will become as the years pass by.

Do you see an increasing number of issue reports?

As application get older, you may start to see strange errors happening, and the number of issue reports for errors that are hard or even impossible to track will rise. PHP has gone through quite an evolution since PHP 4 was released and with PHP 5 the number of errors may grow silently.

Is your application documented?

If your application is four or five years old, it is very unlikely that you will have documented your code in a style that will be helpful today. Documentation tools like phpDoc were not broadly used and while there may have been a specification for your application, commented code will be rather rare.

Missing documentation or aged documentation may be an issue, especially when you are tasked with updating the application.

Does your application make use of libraries / frameworks?

Most likely not. PEAR was not very popular back then, and for most applications there was no defined set of libraries used. From my own backlog it seems like the focus was more on which PHP extensions were used than what libraries one may use. E.g. extensions like GD and Freetype for dynamic image creation have been on the list.

This also may be a reason for large line counts for such an application. Code had to be written in multiple places even though it was identical. Personally the only “framework” I have seen in use back then was Smarty for templates.

Does you application have style?

Even in larger teams with source code control as part of the work-flow style guides for authoring PHP code have been a rare thing on the task list. It is very likely that the team was working on one large application, where each developer was assigned to a specific part of the application, e.g. one handled templates and views, the other one handled database usage, another one was assigned to the administration system.

While this may result in code styles being adapted and used, chances are good that there will be one code style for each part of the application. If you add team changes to this, code styles will start to turn into something that lacks style aka. spaghetti code.

Does your application separate code from views?

In the early days of PHP 4 application used to mix code to implement functions with code to display output. While this may seem strange from todays’ perspective it was perfectly fine back then. PHP development was mostly done in procedural fashion, and thus application logic and user interfaces were not isolated.

Today PHP and especially PHP 5 are used more in classical fashion of software engineering, applying architectural patterns like Model-View-Controller to PHP projects.

Deprecation and your application

Within five years of time a lot of progress and evolution happens in Free Software, and PHP was no exception. Language features have changed, new features have been added, experimental PHP extensions turned into mainline extensions which are available by default. On top of that you will see a lot of PHP functions which are considered to be security risks, and have been replaced with safer functions in PHP 5.

If you are using PHP 5, there is a chapter available in the PHP manual which describes potential issues when migrating from PHP 4.

Last but not least

By now you should have an idea what the signs are to spot a legacy PHP application, and with by looking at your application’s code you should know if it is legacy or not.

In part two of our series we will continue with exploring available options for breathing new life into your legacy app.

Stay tuned for upcoming articles in “Porting legacy PHP apps ~ The Series.

Comments and feedback is more than welcome, of course.

Introducing “Porting legacy PHP apps”, an eight part series of how-to’s, rules and recommendations, and a few bits and pieces of good advice to be published in the next weeks, with the first part of the series debuting this week. The term “legacy” in the title refers to code developed for PHP when PHP version 3 was common on most servers, and PHP4 was right around the corner, mostly used by “early adopters”. Wikipedia of course offers a definition of legacy code for us to read, and you will probably discover a few of those common criteria in this series.

Here is what you can expect to see:

• Part One: Spotting legacy apps. The first part of the series will briefly discuss what a legacy PHP application actually is, and how you can run a quick check on your own applications to see if they qualify for being “dinosaurs”.
• Part Two: Rewrite, refactor, refine. Since we identified what apps are considered legacy apps, it is time to consider the available options. What’s worth the effort, and what not?
• Part Three: How to move your app forward. Now that we know more about the available options for making changes to our beloved app, we can take a close look at the type of code which needs to be updated.
• Part Four: It’s all in the process. Making changes to your app should not be done without a plan. Part four will supply the tools and tasks for you to make your plan.
• Part Five: The foundation. With PHP5 and future versions you do have the unique option to apply common development methods to your workflow. Test-driven, agile development is not restricted to Ruby and Ruby on Rails, it’s an option for PHP5, too. We’ll explore available options, both available frameworks, and building your own framework.
• Part Six: Breathing new life into the beast. This is all about Getting Real. By now you should have a plan, and the tools to start refreshing you app, and we’ll make the initial steps together.
• Part Seven: Are you prepared? Now that our app has made its’ steps into the future, we will take a look at the tasks we will face, once PHP5 leaves the stage, and makes room for PHP6. of course, assuming your customers still love your refreshed app.
• Part Eight: Final thoughts. This is it. The last part of the series will feature a few recommendations and probably wise words by me featuring insights gathered during my own endeavors with legacy PHP apps.

Code examples of legacy code and new code will be supplied with each part, and some will probably be taken from a few legacy apps that I currently work on as part of my contracted work.

See you back in a couple of days for part one of our series.

So you have decided that multiboxing is the path you want to conquer, and have decided to create five characters? But what kind of multiboxer are you? I am not referring to being a casual gamer or a hardcore player here. It is not your gaming style that matters, it is your goals and intentions which we are looking into.

When I started my team a few months ago, this was the first question that was bothering me. Reading through the multiboxing forums, it was apparent that numerous intentions for becoming a multiboxer exist. Before starting to play my characters, it felt important to decide what I wanted to achieve in the endgame.

I basically had these options to chose from:

• Player vs. Player: there are quite a few battlegrounds to conquer and with Lake Wintergrasp, PvP in the world finally has become a real thing, too.
• Arenas: Arena games limit PvP to a fixed setting, and might offer another choice. Titles, great rewards, and a challenge to overcome.
• Achievements: a new addition with Wrath of the Lich King and one that leads to nice rewards, too. It seems like a giant world explorer book. Completing achievements definitely is a sign of exploring the world.
• Quests: Have you ever browsed one of the various WoW databases looking for quests? There are thousands of them and achievements like those for completing 1k, 2k, or 3k quests look achievable.
• Dungeons: Lore in World of Warcraft expands through quests, but just like it was from the very beginning of the game, most quests that continue game lore will lead you to dungeons. Most final quests will end in a dungeon. Prior to The Burning Crusade dungeons like Blackrock Depths, Lower Blackrock Spire, Upper Blackrock Spire, Stratholme, Scholomance, and Dire Maul presented a great amount of story lines, and this trend continued in the game addons.
• Professions: Making money is a viable option, too. Professions have received a great amount of love from Blizzard and with Wrath of the Lich King there are quite a few dailies to complete for gold, and every profession now has recipes that can be crafted to sell them on the auction houses for profits.

Looking at that list, I crossed PvP and arenas off the list. To be honest, I liked the old PvP system as it existed prior to the Burning Crusade, because engaging in a battleground had a result. Both titles and rewards did come with a meaning. It was fun. Now battlegrounds mostly feel like a grind for gear, and nobody really cares if battleground goals are achieved. I really miss the epic Alterac battles with people working to achieve quests for bonuses. Arena gaming does not really make a difference. It limits the amount of players and classes, and thus reduces everything to maths and gear.

This left me with achievements, quests, and dungeons. If you check WoWHead there are close to 1k of achievements for almost anything you can do in World of Warcraft.

• General achievements: this includes mostly easy to achieve stuff like picking up various vanity pets, mounts, reaching specific levels, learning various skill levels, or owning items that only have been available for a limited time frame.
• Quests: easy one. Reach a specific amount of quests per zone or continent for an achievement, and you’re done. Additional gimmicks include money owned through quests, and the number of quest. Personally I think the Loremaster achievements are tough but very tempting.
• Exploration: discovering zones and all their sub-zones… does not sound like hard work? Well, try to log in to one of your first characters. If happen to have one from the release of WoW in 2005, you will notice how many sub-zones you missed.
• PvP: this is one, where I am not sure if it’s for good or for bad. Some achievements are easy, just run arena or battleground matches over and over to get them done. Others… smell like a lot of luck and work.
• Dungeons & Raids: just run every available dungeon and raid in game. Some may need a normal and heroic run, and some even might need specific strategies. Not really hard but rather time consuming. At least you might get a chance to enter old world dungeons and raids like Blackwing Lair for the achievements. Those are still fun.
• Professions: awesome! Wanted to see how many fish you caught? How often you consumed cooked food? Bandages, crafted gear, it’s all here. Most of these achievements will happen to appear as you continue to play your character. There is no chance to avoid those but to not learn any profession.
• Reputation: cough prior to the first game expansion reputation was pure grind. With the Burning Crusade, this was eased, and with Wrath of the Lich King, there hardly is any grinding left. Except for a few old world reputations like the Timbermaw Furbolgs. If you want something hard, try getting as many reputations as possible up to exalted. This alone might take a few months.
• World events: this one is a bit misleading. Probably “Seasonal events” would have been a more suitable title. You will only find achievements for recurring events in here.
• Feats of Strength: yes, this is where world events appear. The Scourge Invasion, Ahn’Qiraj, etc. Plus various achievements for things that require a lot of work, or even money. Think of Collector’s Edition pets, Trading Card Game, and others.

Once I had digged through the list, I decided to just focus on achievements. Getting as many as possible would naturally lead me to doing all quests, and stepping into all of those dungeons and raids.

So, what is your game? What part of WoW does entertain you the most? For me, I can clearly state that I love to explore the whole world with all that’s inside.

0.4.2 – “Fishing Extravaganza” – Dec 17, 2008

This release should fix issues with character that could not be retrieved from the armory due to special characters in realm or character names.

Bugs squashed

• phpArmory5Cache: the setCachedData(…) function was called without prior checks if there was any valid data to cache. This has been fixed.
• phpArmory5: Strings used in URLs do not need a manual replacement of the space character. urlencode() handles this for us already.
• phpArmory5: fixed an issue in __construct, where required PHP extension have not been checked properly. Thanks to Gizzmo for the hint.

Features added

• phpArmory5: added getAnyData($searchType = NULL, $objectName = NULL, $filter = NULL). $searchType can be any of “arenateams”, “characters”, “guilds”, “items”. $filter needs to be an associative array of filter properties. For now, try out the armory item search page to see valid filter options.

• phpArmory5: added a third parameter to getCharacterData for retrieving only the basic character data. Defaults to false. Use the following to get basic character data only:

  $character = $phpArmory->getCharacterData($characterName = "Char", $realmName = "Realm", $onlyBasicData = true)
  

Download

Enjoy the 0.4.2 release, and either grab phparmory-0.4.2.zip or phparmory-0.4.2.tar.gz. Please note that all PHP files are formatted with Unix line endings, as I am mostly a Linux / Mac geek.

Feel free to leave a comment if you should end up having trouble with the classes. phparmory-042tar

The database client

While I am currently using .NET 2.0 / C# to prototype a client which takes care for downloading and updating the WoW addon for data gathering, I am of course aware that .NET 2.0 is not available on every platform where you can play World of Warcraft. There is Windows in various incarnations, and there is Mac OS X for us to play the game on, and some people even use Linux to play. I probably have not mentioned this, but I am using all of these platforms to play the game, and thus I am very interested in making the database client work on all of these platforms.

My current plan is to finish my .NET prototype, as I need some quick test tool, to define and build a proper web interface for managing the WoW addon, and to test the client updater. Once this is done, and the web interface works, I plan to turn the whole client functionality into a plain C++ library, which can be build and used on Windows, Mac OS X and Linux.

For now the library is supposed to contain the following features:

• Parsing the WDB cache: as many players know, the game client uses a simple data cache for books you have read, creatures you saw, game objects seen and used, items seen, and quests done. This data will be required for several reasons. E.g. if we want to display rendered views, we need the data from the WDB cache files.
• Detecting WoW: of course, the library needs to find WoW on your system, and there are various different methods to do so. WoW is e.g. installed in different ways for 32-bit and 64-bit operating systems.
• Parsing the addon Lua data: while this is not necessary it would be beneficial to embed Lua into the library. This would allow us to validate the saved Lua data, and it might provide options for blocking invalid data, too. Why should we upload broken data?
• Authentication: I would love to have the database site requiring a login. Why? Because it would be great to give credits where they are due. If someone contributes to the database, it should be recorded and visible in some place.
• Update management: we need to keep up-to-date, and this includes both the database client, and our WoW addon. The game client changes with every release, and bugs are everywhere. There is no development method that results in zero bugs.

On top of the library custom GUI clients can be used for each platform. On Windows, we could use plain C++ with MFC or a .NET GUI, on Mac OS X we can use Carbon API to integrate into the system.

Of course, suggestions are welcome.

The database server

Once of the things I have considered over the last few days was to turn the server into something that could run in a distributed fashion, much like the version control system Git which I use for my own projects at home and at work. Concerns have been raised that the current databases are commercial because you will have large hosting bills.

But what if the database server would have a central server somewhere, and all available installations would connect to this server for data sharing? Thus every installation (e.g. on guild sites) could contribute their data even without knowing the main server, and every installation would benefit from uploads.

Anyway, the only thing I have decided on yet is that the database server will be developed using a model-view-controller pattern. This may be done with ASP.NET, on PHP using the Zend Framework, or on Python using Django, or on Ruby using the famous Ruby on Rails.

Personally I would prefer a Python or Ruby based solution. But still, for my prototyping I will stick to using PHP and the Zend Framework for one simple reason: this solution works on most hosted environments. You will not depend on owning a root server (which not everyone can afford).

The code

There already is a bit of code, and I am working hard to get this in a readable state and documented. It will appear in my GitHub account in a few days.

Contributions are welcome, in the beginning I would be very interested to hear what addon developers need. E.g. what would systems like QuestHelper, TourGuide, or LightHeaded need? After all, quest guides are the simplest form of giving data back to the community, thus you would want to have it done right from the beginning.

For now, I am considering XML output in a format similar to the armory format, but would that work for addon developers?

The database contestants

Ever since World of Warcraft became public there have been websites out there, which gathered game data by using a Lua addon and some sort of data uploader. In the beginning there was one database site and nowadays there are many.

• Thottbot: Probably the father of all WoW database websites. Thottbot.com started somewhere during the World of Warcraft Closed Beta and has been a primary source of information for many players. Quests, Items, Maps, NPCs, Spells, and more await the curious player, and closely coupled with Thottbot comes Cosmos, a User Interface modifcation pack, to which players were drawn in the early days of WoW aka. the days when World of Warcraft was not available in any localization.
• Allakhazam: Allakhazam entered the market of WoW databases a bit later. They already had experience with this thing, as they started with an Everquest database. Their WoW site has gone through various iterations, and AFAIK was the first database site to offer support for the various localizations in which WoW was made available. Another feature spearheaded by them was the monitoring of Auction House prices for items. Yay for that!
• Wowguru: Another side project of an MMO database site, and one that initially had some success. WoWguru.com entered the scene in Summer 2005, and later spearheaded with features like honor tracking, and most prominently with monitoring the individual realm status during the Ahn’Qiraj War Effort.
• Wowhead: Here comes an impressive contestant. Ever since their launch Wowhead impressed with an information-centred design that helped users in finding the information needed very quick. Wowhead comes with a well made Lua addon, and a sleek uploader. Once of their primal bonusses was that they had been very active with making their Lua addon work for the Public Test Realms, and soon this resulted in Wowhead leading the WoW databases. Features like a well-designed commenting system, their item and character preview, and others still remain on top of the list.
• WoWDB: The latest entry in the list of contestants. Made by the MMO portal site Curse (which alos provides hosting for most WoW Lua addons), WoWDB entered the scene with some features that Wowhead could not offer: item comparison, wishlists, and a look more oriented on the WoW look. AFAIK their character preview was first, and Wowhead added that a bit after them.

What do all these databases share?

As it seems, the market for World of Warcraft databases is a hot one. Even four years after WoW made its’ initial release. And as we can see by the release of new and different databases, none of the contestants listed above yet has managed to reach a state where WoW players are satisfied.

If we compare the features of all available WoW databases we can see that it’s not all about features, but about design and usability, too. Some features did not really make it into the market, as players did not seem to accept them.

• Auction House monitoring: Yes, it is there, and some people might use it, but apparently this is not interesting or good enough to be used anywhere else than on Allakhazam. Apparently using spreadsheets still is superior. Also, there is Auctioneer which works in-game and automates a lot of the process.
• Crafting requirements: Wowguru introduced this quite some time ago, and I thought it was a great feature. When displaying a crafted item, you could see all the items required to create it, summing up the total vendor price for all needed materials. Nice, but oviously not needed. Gold seems to be an irrelevant factor, and thus only material lists survived.

This leaves us with a list of features that seem mandatory for a mature World of Warcraft content database.

• Searching: Of course, searching is mandatory. Every site has it, and the only difference to be found is in the way search results are returned. Older sites just take an argument to look for and return an result page with any matching object, Wowhead and WoWDB sport a bit more elegance and make use of AJAX to return drop down lists with matching data instead of requiring you to wait for a result page.
• Filtering: Even though the official forums are full of people demanding more content because the existing content would not be sufficient, a look at a database of your choice proves the opposite. There is lots of game content, and there is much to be seen. Even after four years, I am sure you will find content that you have not seen yet, even if you started your character in February 2005. Thus most database allow you to filter for various parameters, and most important: you can apply multiple filters to any kind of data. Sleak and useful.

And why would you want that Open Source’d?

It’s simple. Many people contribute data to these databases, and only with your or my contributions of data gathered while playing the game, those databases exist. It’s a community effort, just like the game itself is meant to be some sort of social community. But why are all of these databases closed, or commercial? Some even want you to buy premium subscriptions to access guides or more data.

Now what if there was an Open Source database for World of Warcraft? Where you could not only contribute data you gathered while playing, but also access that data or even download it to your computer and do something with it? Or where you could see what you have gathered while playing?

So I have decided to give myself a new pet project to work on, and it will become Open Source very soon, once I have ironed out the basic details. Work already begun, and a very basic implementation is there. The tools I have used are:

• Visual C# 2008 Express Edition to build a .NET 2.0 client application which handles uploads,
• Lua to write a WoW addon which gathers data while you play,
• Zend Framework and Doctrine ORM to write the server-side backend which accepts uploads.

The process for now is very simple:

• the .NET client will parse the WoW data cache (which you will find in your WoW installation directory under WDB/your-locale/*.wdb),
• it can show you the contents of your WDB files, e.g. you can see which NPCs you have seen, or what books you have read,
• it will parse the saved Lua data generated by the addon, and can show what data besides your WDB cache is there,
• and it can convert both WDB and Lua data to XML,
• and finally it can upload the data to my server (GZipped of course, to reduce bandwidth usage).

Parsing the data is something that will be done next. For now my server-side application only handles storing the uploaded data, and manages updates of the client. Not very much, but at least my data is stored. Parsing will be a bit more work since I have to make a modular parser that can deal e.g. with different data formats, as the data formats may and surely will change with every WoW client update.

What do you think? Would you use an Open Source World of Warcraft database, where you have full access to the data you contributed? Would you like to download contributed data in a parsed format, perhaps as XML files to reuse them on your guild website or your blog?

More on the project soon, after the finishing touches have been put on the data client. Screenshots coming soon.

First, let us check what we currently have in store:

• Characters: Retrieve full character details including stats, equipped items, skills, reputation, buffs,
• Items: With complete stats, reagent details, related quests,
• Guilds: List of members,
• Caching: Caches results of requests to improve performance
• Localisation: Results returned in the armory’s supported languages from localised servers.

This seems like the basics done. Personally I would love to add the following stuff:

• Arena teams: it’s on the TODO list, and will be released after December 17th, 2008. Why? Because arena season 5 will start then, and only then I can get arena team data from the armory to test and implement this.
• Searching: Query the armory for any kind of data.
• Guild banks and calendars: You have guessed by the name, don’t you?

Searching is pretty simple to implement, as we can base upon getXmlData( ..) and search for arena teams, characters, guilds, and items easily. We can even filter the results by any desired parameter.

Now when it comes to guild banks and calendars, things get a bit spooky. Both features can be implemented, but you would have to trust phpArmory to not do bad things with your account data, as the class would need to authenticate using your account data on the armory site in order to retrieve the guild bank contents, or your calendar.

Here is your chance, to influence future releases. Raise your voice, and share your thoughts.

0.4.1 – “Call to Arms” – Nov 26, 2008

The World of Warcraft armory has received quite a few improvements, making it feature complete with the added character data from the “Wrath of the Lich King” expansion.

Features added

• getCharacterData($characterName, $realmName) will now return an array which contains character achievements and statistics.

  $character = Array
  (
      [characterinfo] => Array
          (
                  ...
          )
  
      [reputationtab] => Array
          (
                  ...
          )
  
      [skilltab] => Array
          (
                  ...
          )
  
      [talenttab] => Array
          (
                  ...
          )
  
      [achievements] => Array
          (
                  ...
          )
  
      [statistics] => Array
          (
                  ...
          )
  
      [armorypatchlevel] => 030003
  )
  

Download

Enjoy the 0.4.1 release, and either grab phparmory-0.4.1.zip or phparmory-0.4.1.tar.gz. Please note that all PHP files are formatted with Unix line endings, as I am mostly a Linux / Mac geek.

Feel free to leave a comment if you should end up having trouble with the classes.