test

I’ve been waiting for this one for weeks. Donncha worked pretty hard getting this release out and squashing the bugs. Check out the official forum thread for details.

I’m a bit behind, but I hope to thoroughly test this out and point out the snazzy new features and what you can do with them.

The first one I did notice (using a release candidate) was a Quota level for users. It shows up both on the dashboard under the Blog Stats and in the upload area, so users can tell how much space they have left for files. Excellent addition.

Share This

Original post by Andrea

Sometimes there are quite a few forums posts, or even bug tickets filed, reporting issues that aren’t really bugs. So to me, the first step in reporting a bug is determining if it is actually a bug or not.

I’m sure you already know this, but to clarify, a bug means there is something wrong with the program itself. If you are having issues installing the program itself, this is not a bug. It means you missed a step somewhere or your server has an issue you need to track down.

Another common issue is not knowing how the program works by default. There is an assumption that anyone using MU has at least rudimentary knowledge of Wordpress and is generally familiar with running a server and mucking about in configuration files. So, before asking in the forums or filing a ticket you need to research if this issue is default behaviour.

One example is registering users. In Mu, users have to register on the main blog, then they can be added to sub-blogs. This is different from regular Wordpress where users can sign up directly to that blog. This is also not a bug.

A lesser complaint is that the program doesn’t do what you wanted or expected it to do. MU is a blog farm. It does it quite well. It can be convinced and massaged to do plenty of other things or act similar to other software, but it is not a CMS, and it is not a social network. Not really, not out of the box.

The best-case scenario for finding a bug is on a fresh or recently updated working install, you’ve clicked a box, uploaded a file, pressed a button and… poof. White screen of death. Congratulations! You’ve found an actual bug!

So now we’ve determined that our problem is not default behaviour and our expectations are in line. The next step is to search the forums to see if anyone else had the same issue. If we’re lucky, we may find that other people have had the same problem. Read each thread to see if soloutions are offered. If it becomes a known issue, and is confirmed as a bug, someone may post that a trac ticket has been filed. If it’s really a good day, there may even be a fix in trac and you can update your install with the fixed file and move on.

Of course, you too can be a part of development if you’ve found a new bug. Now file that trac ticket!

Share This

Original post by Andrea

Most users lightly follow development in the forums. To get a bit further, you can follow along the trac system and see when tickets are filed and issues are fixed. There’s an RSS feed link at the bottom of this page to follow active tickets. It’s a good practise because sometimes an official release is tagged and the download page is updated, but bugs soon follow. This is also usually the first place you will see security issues or fixes. to follow every change, both tickets and recent changes, subscribe to the feed on this page.

Found a bug? Great! To file a bug ticket, login using the red login link at the top right of the page. Your login username and password is the same as the one you use on the forums. This is very handy indeed. Also read Is it really a bug if you are not sure.

Once you’ve logged in you’ll see that the menu bar now has a new option: New Ticket. Click it. You will now be presented with a wiki-like form in which you can type up the details. Write a brief but descriptive subject and in the text area be as detailed as possible. Ther eare drop-down boxes to further categorize your issue. If you are not sure what to pick, you can leave them.

My only caution is that you use the bug tracker sparingly and only when you are absolutely sure it is needed.

Share This

Original post by Andrea

Now that we are familiar with the trac system, how can one get a small zip containing just the needed files that have been recently changed?

First, you need to know what you already have installed. As of this writing, if you have the latest from the download page, you have installed 1.2.5a. This is also listed in the admin footer of your install. In the trac system, you can find tagged version of the code in the “tag” section. (Browse to the source, choose the tag folder instead of trunk.) Scan along that line and you will see a cloumn with the revision number. In the case of 1.2.5a, it is revision 1054.

Remember that number.

Browse back up to the root, choose trunk this time. Near the top right along the menus, choose “Revision Log“. Scrolling down, you will note that revision 1054 is not there, but 1053 and 1055 are. That’s because 1053 was the last file change before it was tagged as that official release. Making that change (tagging an official version) was the 1,054th change and it was assigned to the tag folder. The next change was a file change in the trunk folder, and thus was 1055.

On the left of the columns are radio buttons. Select the left-most radio button next to number 1055. At the top, the right-hand radio buttons already have the latest change selected. If you don’t want to go quite that fare, that’s fine. You may only want to go as far as before the most recent Wordpress merge*, in this case 1124. So now that we have two radio buttons selected, press the “view changes” button near the top left.

* Typically a Wordpress merge means quite a few file changes, so you may want to leave that revision for another seperate time to deal with it.

Depending on how many changes are between your selections, it may take a bit to bring back results. What you will see next is a list of every file that has been changed. The small box in front of each filename is a color status. Yellow means changed, red means deleted and green means added new.

Scrolling a bit further, you will see line-by-line results of recent changes. In our example there’s a lot, so feel free to scroll on by. And finally we’ve reached the bottom of the page, where once again we’re greeted with a download link to a zip. This will contain just the changed files between revisions. The directory structure is maintained, so once you’ve downloaded it and extracted it somewhere, you can easily replace the files in your test bed with a quick drag and overwrite all.

This is a good option if you do not have a local copy to sync with through svn, or you do not want to download the whole entire recent package.

Share This

Original post by Andrea

Ah, the trac system. Trac is a program on the server that keeps a record of every single code change made by the devs. It also serves as a bug reporting and archiving tool. Every time a change is made to the codebase, it is submitted to trac. When you read about “development version” or “bleeding edge code” this is the repository that people are referring to.

Initially, it can be quite confusing to move around and find things. The main area that you will probably use is located in the link along the top right of this screen. Choose “Browse Source”, then the “trunk” folder, and you’ll see what looks like a directory structure of the whole program. Next to each file name is a line with the most recent reason for the last change to that file. There is also a column to show the last time that particular file was updated.

Before you click anywhere, scroll down to the very bottom of the page. See where it says “download in other formats”? The zip archive link below is indeed a zip of the latest development version. It’s handy if you need or want the absolute latest version that hasn’t appeard on the official download page yet.

The same is true for individual files. You can always browse to your needed file and get a copy from the links at the bottom. Then you can integrate this into your install. Take care to read the comments next to the files, as sometimes there are warnings that it is still untested and should not be moved into a production site without a through test by you.

Coming up:
- how to file a bug ticket and follow the latest issues
- how to sync a local install with the latest version
- how to find line-by-line code changes
- how to get a zip of recently changes files

I’ll link to these as they are written.

Share This

Original post by Andrea