How-To Tutorials - Web Development

Adding a text box to your profile page One useful thing you can add to your profile page, or any View, is a text box. These are extremely useful for giving meaning to your web page. You can use the text box to put in descriptions or snippets of information that help structure your View in a more logical way. In the next Time for action section we look at how exactly you add a text box to your profile page. Along the way, you will encounter for the fi rst ti me Mahara's drag-and-drop user interface for adding items to Views, which is is very exciting! One of the things that make Mahara stand out is its flexible framework for creating web pages. It is extremely intuitive as you will see, and reflects in some ways how you would create a poster display—taking bits of information such as text and pictures, moving them around until you are happy with their location and then sticking them in place. Of course, the advantage is that, with Mahara, they aren't stuck down forever with glue and can be repositioned whenever you like. Let's add a text box to our profile View. Time for action – creating a text box for your profile page Click on the Edit Profile Page button in the Profile submenu. You will see a page that looks a bit like this: You will notice that you are being encouraged to select different blocks from within a set of six tabs at the top of the screen and drag them down onto your View page. Later we will be looking at these blocks and learning how to position them on our page. However, right now we are focusing on how to work with the text box. Click into the tab called General. You should see this: Click and drag the text box icon somewhere onto the space below to position it amongst the other blocks already on your View layout. You will see the other blocks move as you are dragging to make space for the text box. You will also see a dotted gray line showing you where the new block will appear. Here is a basic diagram showing the drag-and-drop action: Can't drag and drop in Internet Explorer 6.The functionality allowing us to drag blocks around the page when we are editing a Mahara View is enabled by JavaScript. Most modern browsers support JavaScript as default, including Firefox, Safari, and Internet Explorer 7 and 8. Unfortunately, many people are still running Internet Explorer 6 and Mahara's drag-and-drop facility won't work in this browser because of problems (or bugs) it has with layout that newer browsers don't. You can still use IE 6 without the drag and drop feature, and use the radio buttons instead, but we recommend you to upgrade your Internet Explorer browser or (even better) download an open source browser such as Mozilla's Firefox: www.mozilla.com/firefox/. A box will open. Click into the Block Title and add your title. Click into the Block Content box. Type in here the body of your text box. Janet Norman decided that she would like to have some information about Mahara on her profile page. Click Save to finish and that's it, you've added you first text box. What just happened? You just added a text box to your profile page. A section on your View is called a block, and you've just learned how to add a new text box by clicking and dragging it onto your profile page. Blocks are what Mahara uses to personalize your profile page and your Views. You can add and delete blocks, and move them around. There are actually quite a variety of blocks, and the Mahara developers are keen to keep adding to the list. We have started here with a basic text box, as it's probably the one you will use most frequently. One of the things you probably noticed when adding text to your text box was that you have a number of editing options available. Janet would like to make her text look more interesting, so let's revisit our text box and look at what these options do. Options in the text editor You will probably find that you have already used most of the options in the text editor when working in word processing programs. Let’s have a quick look at some of the most commonly used options. Icons Function These icons can be used to make your characters bold, italicized, or underlined   Align your text to the left, to the center, to the right or justify your text into a square, newspaper-style layout.   Add bullets or numbers to your lists of text.   To toggle your page into HTML mode.   Add a hyperlink to your text.   Break an existing hyperlink.   Now let's try formatting some of the text you have just entered. Time for action – editing a text box by adding a hyperlink Open the text block you created earlier for editing. You can do this by clicking on the icon that looks a little bit like a cog at the top of the block. We are going to add a hyperlink to the text. Did you notice that the two link icons are grayed out and unclickable? This is because you can't hyperlink to something before you have highlighted it. Do this by clicking and dragging you mouse over the text you want to hyperlink. Now you should see the two hyperlink buttons in color. Click the Make Hyperlink button (the one that looks like a chain) to start creating your hyperlink from the word(s) that are highlighted. Jane has chosen to make a link from the word "Mahara" to the Mahara website. You should see a new dialogue box similar to the one below: You now get the chance to enter your link. Jane therefore enters a link to the Mahara website http://mahara.org. She has also added a Title to her link. This title displays when the user hovers over the link. Click Insert, which will create your link. To finish, remember to click Save, otherwise you will lose the work you have just done. You should see the link highlighted in a different color: What just happened? You just edited a text box by adding a hyperlink. In the last section, we showed you that HTML editing is one of the options in the text editor. Web developers have traditionally used HTML code to write their web pages. It will be useful for regular Mahara users to learn a bit of basic HTML in order to gain more control over their Mahara View pages. The World Wide Web Consortium offers free, beginner-level HTML tutorials at http://www.w3schools.com/html/.

For this article, we are going to concentrate on the Profile tab of the main menu. The very first thing that most Mahara users want to do is customize their own profile space, making it unique to them. We will show you how to do that. For the following examples, we will be working with Janet Norman of PI Inc, showing you how she has configured her profile space. Why not set up your own profile in the demonstration site as you work through the examples? Let's start by looking at profile information. Profile information Later you will set up your own profile page—showing yourself and your knowledge off to others in an attractively personalized way. However, before you do that, you need to add some profile informati on. Your profile information is the first example we will see of "stuff " that you can add to Mahara. When we say stuff we simply mean informati on, or items that can then be viewed later or arranged into web pages, which we will see when we look at your profile page. You are now going to set up some profile information as "stuff " that you can select from and use. We will look at three types of profile information—your profile itself, profile icons, along with your resumé, goals, and skills. Editing your profile Let's show you how to edit your profile. Any information you enter into your profile is private from everyone except the Mahara Site Administrators. You will get to choose who can view what, later on in the Mahara process. Time for action – editing your profile Click the Profile button on the main menu. You will notice that Mahara has opened the Profile submenu. The Edit Profile tab is selected when you first enter your profile space. Let's take a quick look at Janet's profile. You will notice that the About Me tab is selected. Janet has already entered her name. Say something about yourself! Scroll down to the Introduction section of the About Me page and enter some text. Here is what Janet Norman typed in: Whenever you make any changes, click the Save Profile button at the bottom of the page. Next, click the Contact Information to the right of the About me tab. You will see that you are expected to fill out some telephone numbers and addresses. The first thing you should notice is that you can have more than one e-mail address in a Mahara site. To add another e-mail address, click the link to Add email address. The e-mail address will receive a confi rmati on e-mail from the Mahara site and you will have to go to your e-mail account and follow the link to confirm it is genuine. You can now use radio buttons to toggle which e-mail address you would like to use as default for your account. This selection is important because it is at this address that you will receive system messages. You will also noti ce that you can delete an e-mail address by clicking the small, red-colored cross to the right of the e-mail address. Fill in your contact information on this page. Remember, you don't have to complete all the fields if you don't want to. Click the tab called Messaging. Mahara will bring together the types of people you are likely to engage with in live text, audio, and video conferences. People can display these contact details to each other in their profile page and other web pages. Enter your contact details for the facilities you use on this page. If you are still not using live conferencing tools, perhaps now is the time to start thinking about it. Finally, click the tab called General. On this page enter your Occupation and Industry (remember to click the Save Profile button when you have finished). Janet Norman typed this: What just happened? You have just completed your profile by entering some information about yourself, including your personal information, what messaging/conference tools you use, and your Industry background. Both the Contact Information and Messaging information are private and will only be seen if you add them to a web page. This is because you don't necessarily want anybody in the Mahara site to be able to see your telephone number and address for security reasons. Help!If you have found so far that you wish you had a bit more information about what certain options do, then don't worry! Mahara is very well documented software. On most pages, you will see litt le question mark icons. If ever in doubt, click on these and you will be given very useful and specific help relati ng to your area of doubt. Let's now continue to add some more stuff into our profile, with profile icons. Profile icons Profile icons bring your profile to life! They are the first thing that people see about you when they are interacting with you in different areas of the site. Mahara allows you to upload up to five different profile icons. This becomes very useful when you are making web pages out of your stuff . You can present yourself to different audiences in different ways, simply by altering your profie icon. For example, you can display a serious passport photo to your professional work colleagues, a more informal photo to your closest work colleagues, perhaps an avatar for public groups where you would like to be a bit more anonymous, and a picture of you having fun at a party for some of your more social interactions. Time for action – uploading your profile icons Let's get a few different profile icons online. Click the Profile submenu button called Profile Icons. Click Browse to find the profi le icon you want to upload from your computer or USB stick (or wherever). Don't forget to add an Image Title for your profile icon before you click the upload button. You are allowed to upload up to five profile icons and you can delete any icon at any point. You will need to choose one of your icons as your default profile icon which should probably be a fairly sensible one. Janet Norman has already uploaded two profile icons: What just happened? You have just uploaded a profile icon to represent yourself in your Mahara site. As we saw in the Time for action section, Janet has uploaded two icons. One of these is an avatar of herself and the other is the company logo. She plans to use the company logo in places where she would like to appear more professional, whereas the avatar will be used more generally. Make yourself an avatar! An avatar is simply a character or cartoon representation of yourself. If you don't want a passport photograph as your profile icon, an avatar is a good alternative. There are many websites that help you create your own. A few of the most fun include the Simpsons Avatar Maker (http://www.simpsonsmovie.com), DoppelMe (http://www.doppelme.com), and Mr Picassohead (http://www.mrpicassohead.com). Editing your resumé goals and skills No longer will you need to trawl through ancient hard drives trying to find the resumé you last wrote five years ago. Instead, you can keep your resumé information within your Mahara system and update it when you make changes. How impressive will you look when you show your resumé to your prospective employer as a web page rather than on a piece of paper. There are three tabs remaining in the profile submenu that allow us to add stuff to our site. The remaining things we can add are: Resumé information: You can record your career and educational achievements. Goals information: Here you can set ourselves personal, academic, and career-related targets for your future. Skills information: You can record for yourselves what you perceive to be your personal, academic, and work-related skills.

PHP-Nuke is about web communities, and communities need members. PHP-Nuke enables visitors to your site to create and maintain their own user account, and add their personal details. This is usually required for them to post their own new stories, make comments, or contribute to discussions in the forums. Those annoying little tasks like managing lost passwords are also taken care of for you by PHP-Nuke. User accounts can be created in two ways: By the super user (that's you) By the user registering on your site The second method involves a confirmation email sent to the user's email account. This email contains a link for them to click and confirm their registration to activate their account (this needs to be done within 24 hours or the registration expires). Once a visitor is registered on your site, the gates to enjoy the full glory of your site will be thrown wide open. Visitors, or users as you could now call them, will be able to contribute to discussions on forums, add comment on posted stories, even add their own new stories, as well as access parts of the site that are off-limits to the 'riff-raff' unregistered visitor. Ingredients of a User Every user requires a certain amount of information to uniquely identify them in PHP-Nuke. There are the usual three things required of every user in PHP-Nuke: A nickname: This is an alias or username if you like. This identifies who the user is, and is their online identity in PHP-Nuke. A password: This is required to verify that the user is who they claim to be. A valid email address: This is where the confirmation email is to be sent. Once the user account is created for a user, the user is of course able to modify their details, and also view the details of other users. Information such as the URL of the user's own website, messenger ID (MSN, AIM, and others), their location, and interests are also part of the user 'profile', but are not compulsory. By default, the real email address of any user is never made public, for both security and to prevent harvesting by spammers. Users can specify a 'fake email' address, possibly in spam-obfuscated form (for example, address_at_mydomain.com) which will be displayed to other users, although this is not required. A user's privacy is always protected. Setting Up a New User User management starts by clicking the Users icon in the Modules Administration menu: Clicking on this icon brings you to the User's Administration panel. This panel consists of two mini-panels, Edit User and Add a New User , whose use is given away by their titles. We'll start by setting up a new user. Our user will imaginatively be called testuser. Time For Action—Setting Up a New User Manually If you're not at the User's Administration panel, click on the Users icon in the Modules Administration menu. In the Add a New User panel, enter testuser into the Nickname field. Enter Test User into the Name field. Enter your own email address into the Email field. Scroll down to the Password field. Enter testuser as the password. Click the Add User button. When the page reloads, you will be taken straight back to the administration homepage. What Just Happened? We created a new user. For this simple user, we only specified the required fields Nickname, Email, and Password, and provided a single piece of personal information, Name. Failing to specify the required fields will mean that the user is not set up, and you will be prompted to go back and add the missing fields. No email notification is sent to the user when the user is set up in this way, and no confirmation of the registration is required. As soon as you click Add User, provided all the required fields have been entered, the user is ready to go. Editing the details of a user is equally easy, but you do have to know their nickname to edit the details. Simply enter this into the Nickname field of the Edit User panel, select Modify from the drop-down box and click Ok! If you have taken a sudden dislike to a particular user, enter their nickname into the Nickname field and select Delete from the drop-down box, click Ok! and they are gone forever (the account, not the person). Subscribing a User Once a user has been created, you have the option to subscribe this user. We mentioned the idea of Subscribed Users in earlier articles; it's a mechanism for restricting module access to specific groups of people, such as fee-paying customers. There is only one group of Subscribed Users in PHP-Nuke at present, so once a user has a subscription, they are able to access any module restricted to Subscribed Users only. The option to subscribe a user is not available when you create the user manually, as we did above. To find the option, you have to edit the user's details. This is done by entering their username into the Edit User panel, selecting Modify from the drop-down box, and clicking on the Ok! button. The subscription options are near the bottom of the user details, underneath the newsletter option. The Subscribe User option does not refer to 'subscribing to' the newsletter; you sign up the user or remove them from your newsletter mailing list with the Newsletter option. The Subscribe User option makes the user into one of the site's elite, a Subscribed User. If you subscribe the user, then you must specify the Subscription Period. This is the length of time that the user remains subscribed, and ranges from 1 year to 10 years, in yearly increments. If you leave the Subscription Period at None then the user will not be subscribed. Once a user has been subscribed, you can change their subscription details from the same panel: You can unsubscribe the user, or extend their subscription period. To shorten the subscription period, you would have to unsubscribe the user, subscribe them again, and then set the new period. Subscribed users are reminded of the passing of time and the impending expiry of their subscriptions when they visit the Your Account module—we'll further explore this module later in the article: Time For Action—Registering as a User This time we'll register to create a user account as a normal visitor would. We'll call the user account userdude. If you do not have your mail server set up, then you will just have to follow the text and screenshots for now. The confirmation email sent by PHP-Nuke is a key part of the registration process, and includes a special link for the visitor to click to activate their account. Don't worry though, when your site is live on your web hosting account, you will undoubtedly be able to access a mail server. If you are still logged in as the super user, logout by clicking the Logout icon in either of the administration menus, or click the Logout link in the Administration block. If you are still logged in as testuser, logout by clicking on the Your Account link in the modules block, then click the Logout/Exit link in the navigation bar that appears: Alternatively, you can enter the logout URL directly: http://localhost/nuke/modules.php?name=Your_Account&op=logout You will be redirected to the site homepage. Now click the Your Account link in the Modules block: Click the New User Registration link. This brings you to the New User Registration panel. The top part of that panel is shown here: Enter the Nickname of userdude. Enter your own email address into the Email field. We are going to use userdude for the password as well as the nickname. If you think of another password at this point, enter it instead. Then put the password into the Re-type password field as well. Click the New User button. You will come to the final step of the registration process: Click the Finish button. Open up your email client, and log in to check your mail. You should find a mail with the subject New User Account Activation waiting for you. It will be from the email address you specified in the Administrator Email field in the Site Configuration Menu. The body of that email will look something like this: Welcome to the Dinosaur Portal You or someone else has used your email account (myaddress@packtpub.com) to register an account at the Dinosaur Portal To finish the registration process you should visit the following link in the next 24 hours to activate your user account, otherwise the information will be automatically deleted by the system and you should apply again: http://thedinosaurportal.com/modules.php?name=Your_Account&op=activate&use rname=userdude&check_num=64ad845758d7f8f572b12800f60842ba Following is the member information: -Nickname: userdude -Password: userdude Click the link in the email, or copy the link and paste it into your browser, and you will be taken to the New User Activation page where you will see a message of the form: userdude: Your account has been activated. Please login from this link using your assigned Nickname and Password. Clicking on this link takes you back to the User Registration/Login page of the Your Account module, and you can use your nickname and password to login. What Just Happened? You just created a new user account. The page for logging in is the homepage of the Your Account module. We'll talk more about this module in a minute; as you could guess, it handles everything to do with 'your' user account. If the visitor is not logged in, they are presented with the login panel when they visit the Your Account module page. From here they can enter their nickname and password to log in, or click the New User Registration link to register a new user account, as we did. For visitors that have forgotten their password, clicking on the Lost your Password? link will take them to a screen where they can enter their nickname, and an email will be sent to their registered email address containing a confirmation code, a random-looking 10 digit string; with this code they can have their password changed. A new, random password is generated and emailed to them. PHP-Nuke never stores raw passwords in its database, so it can never reveal any password. With the new password, the user can log in and change their password to something easier to remember. The registration process for the user is straightforward; they only require a nickname, a valid email address, and a password. There are certain rules, however, that are followed by PHP-Nuke: Only one occurrence of an email address is allowed on the system; if someone uses an email address that belongs to another user account that address will be rejected, and the user will have to choose another. Only one occurrence of a particular nickname is allowed as well; the system will check the uniqueness of the nickname before creating the account. After the visitor clicks Finish on the final step, the user account is created. Following that, the confirmation email is sent to the email address. If the email address specified is invalid, or not the visitor's email address, then that visitor will have to create their account with a new email address. If the user doesn't mind being embarrassed, they can contact the site administrator, or wait 24 hours for the account to be deleted from the list of 'waiting to be activated' accounts, and then try again. You will notice that the link to activate the account contains the URL of your PHP-Nuke site: http://thedinosaurportal.com/modules.php?name=Your_Account&op=activate&use rname=userdude&check_num=64ad845758d7f8f572b12800f60842ba It is very important that you have configured your Site URL option correctly in the Web Site Configuration menu (we saw this in Aritcle 4). If you haven't done that, then the activation link will point to the wrong site! The check_num part of the URL is what identifies the unregistered visitor to the system. When the visitor registers his details, PHP-Nuke stores them in the database along with the check_num value. When the visitor visits the above link, PHP-Nuke will check the value of check_num against the values stored in the database, and if it finds a match, it will move that visitor's details to the proper users table in the database, and remove them from the table of visitors waiting to confirm their registration. That's all there is to creating user accounts. It is possible to turn off the registration, so that only the administrator can create accounts. If you feel the need for this, you can read more about it in the PHP-Nuke HOWTO: http://www.karakas-online.de/EN-Book/disable-registration.html That section of the PHP-Nuke HOWTO also has a number of other user account hacks that you can make use of. Graphical Code for User Registration PHP-Nuke enables you to add a security code to the login or registration pages on the site. The security code is a small graphic with some digits, and is shown under the password fields, along with a textbox for the visitor to type in the digits from the graphic. The point of this device is to prevent automated registrations; without typing the correct digits into the Type Security Code field, the submission will not be accepted. The digits displayed in the image are not part of the page HTML, and the only way for the digits to be read is to actually see them when they are displayed on a monitor. Use of the security code is controlled by a setting in the file config.php in the root of your PHP-Nuke installation. (This was the file in which we made some database settings in Article 2.) The setting to change is the value of the $gfx_chk variable. By default, it looks like this in the file, which means that the security code is not used: $gfx_chk = 0; The config.php file itself has a description of the values for this variable as seen in the table: Value Effect on the Security Code 0 Security code is never used. 1 Security code only appears on the administrators login page (admin.php). 2 Security code only appears on the normal user login page. 3 Security code only appears for new user registrations. 4 Security code appears for user login and new user registrations. Thus to have the security code appear only at the administrator login, you would set $gfx_chk to 1 and then save the config.php file: $gfx_chk = 1; For the graphical code to function properly, the GD extension will need to work properly with PHP on the web server. The GD extension takes care of drawing the graphics, and if this isn't functioning for whatever reason (possibly it's not installed), then the graphic will not be displayed properly, and it will be impossible to determine the security code. In that case, you will have to change the setting in config.php to remove the graphical code. If you are running your site on a web hosting account and the graphical security code is not being displayed when it should, then you should contact your host's technical support to find out if there is a problem with the GD extension. You can tell if the GD extension is installed by using the phpinfo() PHP function. Open a text editor and enter the following code: <?php phpinfo(); ?> Save this file as phpinfo.php in the web server root (xampphtdocs). When you navigate to that page in your browser, a number of PHP settings are displayed, including the status of the GD extension: If you do not see a table like the one above on the page, or if it does not say enabled next to GD Support, then contact your host's technical support. The XAMPP package we install in Appendix A has GD installed and working. Seeing Who's Who Log in to your site as the super user and activate the Members List module (deactivated by default). After activation there will be an additional option available in the Modules block called the Members List module, which provides anyone able to view this module with a list of the registered users: Clicking on the username will bring up a view of that user's profile: This is only a view of the user profile, and it is not an editable form. You will notice the word Forum in the above screenshot. The user profile displayed here is actually the user profile from the Forums module (and note also that the Forums module needs to be activated for this screen to be seen). You will also notice that the name of the site is wrong—it says MySite.com, which is not the value we set for our site name. This is because the Forums module has its own set of configuration settings. We will see how to set these in Article 8. Also note that the Members List module takes information from the Forums module configuration settings. The Forums module is a complete application—phpBB, one of the best pieces of free, open-source forum software around—integrated into PHP-Nuke. One aspect of the integration is the shared user account—the user account you create for the PHP-Nuke site also functions as a user account on the forums. As a user, it is possible to work with your details in two places in PHP-Nuke—from the Your Account module and also from within the Forums module. Although there are two views of information, and two places to edit your details, there is still only one user account. At the moment, the Your Account module offers more user details than are found in the Forums module, such as newsletter subscription information. The integration between the PHP-Nuke user account and the user account for the Forums module has gradually become tighter over the versions of PHP-Nuke, and they are likely to 'converge' further in future versions of PHP-Nuke. Once a user account is created, and the user has logged in, a whole new world opens up to them. The Your Account Module The Your Account module is a visitor's space. The visitor is guided round their space by a graphical navigation bar as seen below: Before we look at each of these links, let's mention what else is on the front page of the Your Account module: My Headlines: The user can view a list of headlines from an RSS news feed of another site. The user can select from one of the headline sites that we saw in the previous article, or enter the URL of the site directly. Broadcast Public Message: The user can enter the text of a public message to be shown to all current visitors of the site. We'll look at this in a moment. These two features are not always displayed; their display is controlled by options in the Web Site Configuration menu that we'll see in a moment. However, the user is always able to see their Last 10 Comments posted and their Last 10 News Submissions on this page. Returning to our discussion of the links in the navigation bar of the Your Account module, we've already seen what the Logout/Exit link does; it logs the visitor out. The Themes link takes the visitor to a page from where they can choose one from the list of themes installed on the site. We'll look at the Comments link in detail in the next article; it leads to options for viewing and posting comments on stories. Note that when you are logged in as the super user, the Your Account module displays another panel called Administration Functions. This panel allows you to modify certain details of that user. We will talk about these in the next article and meet them in their natural context. Editing the User Profile The Your Info link takes the user to their user profile. We saw some of the options here when we looked at creating the user manually. These options are generally for personal details (name, email, and so on), newsletter subscription, private message options, and forum configuration, among others. The options themselves are straightforward. A number of options in the user profile correspond to forum profile options, and don't particularly affect the user outside of the Forums module. After making any changes to a user profile, the Save Changes button needs to be clicked to save these changes. Note that the Save Changes button is not the button at the very bottom of the user details page—the Save Changes button is above the Avatar Control Panel: The button at the bottom of the form is marked Submit , and is only active when the options in the Avatar Control Panel are enabled. The Avatar Control Panel seen at the bottom of the user profile contains an interesting option. An avatar is a small graphic, representing you as an online character. You can choose a graphic from the already existing library by clicking on the Show Gallery button next to the Select Avatar from gallery option: Clicking on this button brings up a selection of little images for the user to choose from. Simply click on the required image and this will be assigned to the user profile: Clicking the Back to Profile link will return you to the Your Info page. The library of images you just saw can be found in the modulesForumsimagesavatarsgallery folder of your PHP-Nuke installation. If you want you can add in more images here, but make sure your image is a GIF file, and that it isn't more than 80 pixels wide or 80 pixels high. Your Account Configuration The Your Home link provides some options for configuring Your Account further: From this panel, the number of news stories displayed on the homepage of the site can be controlled. Remember, this setting only applies to you—and only when you are logged in.

I will first outline the requirements and how to get started with a network installation. Next I will walk through a network installation including screenshots for every step. I will also include text descriptions of each step and screenshot. Requirements In order to install a machine over the network you'll need the network installer image. Unfortunately these images are not well publicized, and rarely listed alongside the other .ISO images. For this reason I have included direct download links to the 32bit and 64bit images. It is important that you download the network installer images from the same mirror that you will be installing from. These images are often bound to the kernel and library versions contained within the repository, and a mismatch will cause a failed installation. 32 bit http://archive.ubuntu.com/ubuntu/dists/karmic/main/installer-i386/current/images/netboot/mini.iso 64bit http://archive.ubuntu.com/ubuntu/dists/karmic/main/installer-amd64/current/images/netboot/mini.iso If you'd prefer to use a different repository, simply look for the "installer-$arch" folder within the main folder of the version you'd like to install. Once you've downloaded your preferred image you'll need to write the image to a CD. This can be done from an existing Linux installation (Ubuntu or otherwise), by following the steps below: Navigate to your download location (likely ~/Downloads/) Right-click on the mini.iso file Select Write to Disk... This will present you with an ISO image burning utility. Simply verify that it recognizes a disk in your CD writer, and that it has selected the mini.iso for writing. An image of this size (~12M) should only take a minute to write. If possible, you may want to burn this image to a business card CD. Due to the size of the installation image (~12M), you'll have plenty of room on even the smallest media. Installation Congratulations. You're now the proud owner of an Ubuntu network installation CD. You can use this small CD to install an Ubuntu machine anywhere you have access to an Ubuntu repository. This can be a public repository or a local repository. If you'd like to create a local repository you may want to read the article on Creating a Local Ubuntu Repository using Apt-Mirror and Apt-Cacher, for additional information on creating a mirror or caching server. To kick off your installation simply reboot your machine and instruct it to boot off a CD. This is often done by pressing a function key during the initial boot process. On many Dell machines this is the F12 button. Some machines are already configured to boot from a CD if present during the boot process. If this is not the case for you, please consult your BIOS settings for more information. When the CD boots you'll be presented with a very basic prompt. Simply press ENTER to continue. This will then load the Ubuntu specific boot menu. For this article I selected Install from the main menu. The other options are beyond the scope of this tutorial. This will load some modules and then start the installation program. The network installer is purely text based. This may seem like a step backward for those used to the LiveCD graphical installers, but the text based nature allows for greater flexibility and advanced features. During the following screens I will outline what the prompts are asking for, and what additional options (if any) are available at each stage. The first selection menu that you will be prompted with is the language menu. This should default to "English". Of course you can select your preferred language as needed. Second, to verify the language variant, you'll need to select your country. Based on your first selection your menu may not appear with the same options as in this screenshot. Third you'll be asked to select or verify your keyboard layout. The installer will ask you if you'd like to automatically detect the proper keyboard layout. If you select Yes you will be prompted to press specific keys from a displayed list until it has verified your layout. If you select No you'll be prompted to select your layout from a list.

Page templates Often times, we may have content that we need to include on several pages. For instance, we may want to include a legal disclaimer to certain pages. Or maybe we want to include a header or footer to all pages that fall into a specific category. Basically, if we have content that we want to include on more than one page, we can use a template. Creating a template means we don't have to type the same disclaimer, or header, or footer every time we want to put it onto a page. Instead, we only have to create the template, and include the template tag wherever we want the content to be displayed. If this reason is not enough to make use of templates, consider this—if we want to change some of the content in let's say, the disclaimer, we only need to change the template and all the pages will be updated. If we weren't using a template, we would have to find each page where the disclaimer content was entered and make the necessary changes to keep it consistent. Using templates is just smart management. Time for action – creating a template We are going to use the URL method to create a new template. When we do this, we will create an empty page where we can create the template. Once it is saved, it can be added to any page we choose with the template tag {{templatename}}. Of course, the name we save our template as will be substituted for templatename. For our sample wiki, we will create a template that adds a thank you to the user for supporting free and open source software. A link to both the Free Software Foundation and the Open Source Initiative will be included as well. This template can then be added to the bottom of each page that describes software. Open your web browser. In the address bar, type http://www.wikiname.com/index.php/Template:nameofyourtemplate . For the example wiki, we will enter http://www.flosspropopulo.com/index.php/Template:Thank you. Hit Enter . After you hit the Enter key, you will be taken to the new Template page. Click on edit this page to create and write the content for your template. For the sample wiki, we use: Thank you for supporting free and open source software.You can learn more about these projects from http://www.fsf.org and http://www.opensource.org. Click Show preview to see your new template. If you are satisfied, click Save page. Open an existing page in your wiki. At the bottom of the page, type {{templatename}} substituting your template for templatename. In the example, we will be opening the OpenOffice.org page and typing {{Thank you}} at the bottom. Click on Save page. What just happened? While creating a new template, we created a footer that can be added to any page simply by using the template tag in a page. This tag {{templatename}} is what placed the content below the horizontal rule in the previous screenshot. Anytime we include the tag for this template, {{Thank you}}, this piece of content will appear. Templates with parameters While the last use of the template tag can really benefit us when we are creating our pages, there is another manner in which we can use templates in our wiki. Do you remember when we created a new namespace called Tutorials? Let's say that we want users to create tutorials for us on our site. Now, if we have 20 different users contributing tutorials, I will bet that there will be 20 different layouts for our tutorial pages. To help keep things more consistent, we can add parameters to our template so that it acts like a subroutine would in a program. Each page where we use this template would have the same parameters; however, the values for each would change. This keeps the pages in the tutorial namespace consistent. A subroutine is a section of code in a program that executes a task that is one part of the larger program as a whole. Time for action – using parameters in a template While this may seem a bit difficult at first, after you complete the exercise you will see how simple it really is. If you have programming experience, the concepts of this should be second nature to you. In our example, we will make the parameters boldface by enclosing them with '''. However this is not necessary. What is necessary is for us to enclose the value of the parameter in triple brackets {{{ and }}}. For example: '''parameter'''||{{{value}}} Notice that the parameter is separated from the value by two pipes (||). Create a new template page using the URL method. For the example wiki, we will create a template called Tutorial by typing http://www.flosspropopulo.com/index.php/Template:Tutorial. Now, we need to create our template. We use the {| to open the syntax and |} to close it. Use some of the formatting techniques we have learned. For an example, we will use: {|style="width:80%; " border=0"|-|width=30%||width=70%||-| colspan="2" align="center"|'''{{{TutorialName}}}'''|-|'''Introduction'''||{{{intro}}}|-|'''Prerequisites'''||{{{prereq}}}|-|'''Steps'''||{{{steps}}}|-|'''Summary'''||{{{summary}}}|} This can serve as a guide for you as well. Simply change the parameters and the values to something that better reflects your wiki. Make sure the syntax is correct by clicking on Show preview. If everything looks like the following screenshot, you can click Save page. If anything is off, double check your syntax and make the necessary corrections. Now that we have created the template let's put it to use. We will need to pass on values on to our parameters on this page. Open a new page for editing. Open the template with double brackets {{. Using the example, we would type {{Tutorial |. Make sure to end this line with a pipe. Hit Enter to drop to the next line. Now we will pass values on to the parameters. Type your first parameter followed by an equal sign (=) and the value. For example, TutorialName = Installing MediaWiki|. Hit Enter and give your next parameter a value. Continue with this until all parameters have a value. Close the page with double brackets, }}. Click Show preview to see if everything is good. If you like what you see, click Save page. What just happened? Using the template namespace, we were able to assign parameters to our template. Now, we can apply this template to any page that we want to have a consistent look. Once we declare this template on a new page, we need to pass values on to the parameters. If you don't pass a value to a parameter, it will display the wikitext for the missing parameter. For example, if we fail to include an Introduction using the sample tutorial, the page will display {{{intro}}} where the introduction would be. The pages will now have the same layout, however the content will change. Using this technique, we created a template called Tutorial for the sample wiki and applied it to a new page. We also saw that we can apply many of the formatting techniques we have learned so far to our template to give it a more unique look and to separate items on the page. Have a go hero Templates are a great way to give your wiki a consistent look. Go ahead and create some templates that you can apply to pages in your wiki. For starters, create a disclaimer or some other type of footer that you will use on certain pages and apply this template to your wiki. Once you have been able to master this, go ahead and create a template that makes use of parameters unique to your wiki. If you are interested in learning more about parameters used with templates, search the Internet for Named and Numbered parameters. You can visit the MediaWiki page: http://meta.wikimedia.org/wiki/Help:Template#Parameters that specifically addresses parameter use in a template. Page redirection If you have spent any significant time surfing the web, you must have surely come across an instance when you follow a link but are redirected to another page. Generally, this happens for one of the two reasons, either because the content you are looking for has been moved to a different page, or because the page you are on has a similar URL to the page where the content is housed. The latter happens frequently when someone has multiple domains all pointing to one website. For instance, www.mysite.com hosts the website but www.mysite.org and www.mysite.net redirect to www.mysite.com so that visitors can view the content. Both instances would be ideal scenarios where we would redirect a page in our wiki as well. Take for instance our page OpenOffice.org from the example. Perhaps someone wrote an article on Star Office years ago. When the name was changed to OpenOffice.org, we could redirect the Star Office page to the newly created OpenOffice.org page. The second instance from above could be used because generally, people refer to OpenOffice.org as simply Open Office. We could then create a page called Open Office and redirect it to the OpenOffice.org page. Both are accomplished by adding the wikitext: #REDIRECT [[Article name]] to the beginning of the edit box. It is important to note that when redirecting an article that contains content, the content does not move to the new page. You can create a new page with the redirect tag as well.

Working with Smarty Variables Smarty variables are much simpler than complex Smarty plugins. They are placeholders that contain plain information about the actual page ID, page alias, or position of the page in the hierarchy. Some Smarty variables that you are not aware of, are already defined in your template. You do not need to know or remember all of them if you know how you can figure out their names and values. Time for action – getting Smarty variables We are going to get the number of the page in the page hierarchy to integrate this information into the design of the page title. How do we figure out the name of the Smarty variable that contains this information? We can get it from the template as follows: In the admin console, click on Layout | Templates. Open the Business World template for edit and add the plugin {get_template_vars} just before the last tag, as shown in the following code snippet: <!DOCTYPE html> <html> <head> <title>{title} - {sitename}</title> {stylesheet} {metadata} <meta name="description" content="" /> </head> <body> ........... {get_template_vars} </div> </body> </html> Click on Apply and then click on the magnifying glass icon on the top-right corner of the admin console to see the result. It should now look like the following screenshot: What just happened? With the Smarty {get_template_vars} plugin, you displayed all Smarty variables available in your template. In the list of variables on each line, one variable is displayed with its name and its value separated by an equals sign. These values change from page to page. For example, the variable with the name friendly_position contains the position of the page in the page hierarchy. If you navigate to other pages, you will see that the value of this variable is different on every page. How do you add a variable in your template? Smarty variables are enclosed in curly brackets as well, but unlike the Smarty plugins, they have a dollar sign at the beginning. To use the variable friendly_position, you just need to add the following Smarty tag to your template: {$friendly_position} You can delete the {get_template_vars} plugin now. It is helpful for you to see which Smarty variables exist and what values are stored there. You can add this plugin again, when you need to look for another variable. Let us use the information we have learned about Smarty plugins and Smarty variables by combining them both to create a title of the page. Open the template Business World (Layout | Templates)for editing and change the title of the page between the body tags and before the tag {content} shown as follows: <h1><span>{$friendly_position}</span> {title}</h1> Then open Business World Style Sheet for editing (Layout | Stylesheets), and add a CSS style to format the title of the page: h1 span { color: #ffffff; background: #cccccc; padding: 0 5px;} The result of the above formating should look as shown in the following screenshot: You  can use any Smarty variable from the template, except for variables with the value Array(). We will look at these special variables in the following section. Controlling output with the IF function You can create numerous templates for your website and assign different templates to different pages. This is useful if you use layouts with a different number of columns. However, sometimes there is only a tiny difference between the templates, and it is not efficient to create a new template each time you need only slight changes. For example, imagine you would like to display the last editor of the page, as we did with the {last_modified_by}tag. It is a useful piece of information on most pages but we would like to hide it on the contact page. You do not need to create a new template where this tag is not added. For such slight changes, it is better to know how to control the output in the same template with an IF structure. Time for action – displaying tags in dependence of the page We  are going to hide the {last_modified_by} tag on the page Contact Us. However, it has to be still displayed on all other pages. Open the template Business World for editing (Layout | Templates). Add the Smarty IF code around the {last_modified_by…} tag, as shown in the following code snippet: <!DOCTYPE html> <html> <head> <title>{title} - {sitename}</title> {stylesheet} {metadata} <meta name="description" content="" /> </head> <body> <div id="container"> <div id="header"> businessWorld </div> <div id="top-navi"> {menu number_of_levels="1" template="minimal_menu.tpl"} </div> <div id="content"> <h1>{title}</h1> {content} {if $page_alias neq "contact-us"} <p>Last modified by {last_modified_by format= "fullname"}</p> {/if} </div> <div id="sidebar"> {menu start_level="2" template="minimal_menu.tpl"} </div> <div id="footer"> 2009 businessWorld </div> </div> </body> </html> Click on Apply and then click on the magnifying glass icon in the top-right corner of the admin console to see the result. What just happened? The IF code that you have added around the paragraph containing the last modification causes CMS to check the page alias of the displayed page. If the page alias is equal to "contact-us", then everything between the IF structure is not shown, otherwise the information about the last modification is displayed. You have seen from the previous section that CMS knows what page of our website is currently being displayed. This information is stored in the Smarty variable {$page_alias}. With the built-in IF function, you can compare the page alias of the actual page with the page alias of the page Contact Us. If the value of the variable {$page_alias} is NOT equal to contact-us, then everything between the IF tags is displayed. If the page alias is equal to contact-us, then nothing is displayed. In this way, you can control the output of the template depending on the page alias.   The abbreviation neq (meaning not equal) between the variable {$page_alias} and the value contact-us is called a Qualifier. Qualifiers are used to build a logical condition in the IF code. The result of the logical condition can be true or false. If the result of the IF condition is true (and it is true if the page alias IS NOT EQUAL to contact-us), then everything placed in between the IF tags is displayed. If the result of the IF condition is false (and it is only false if the page alias IS EQUAL to contact-us), then everything between the IF tags is suppressed. There are more qualifiers that can be used to build logical conditions in Smarty. Some of them are listed in the following table: The IF structure is a useful tool for handling slight changes in one template depending on the page name or the position in the hierarchy. In the preceding example, you saw that you can use every variable from the template to build a logical condition. Creating navigation template with Smarty loop You can also change the HTML markup of the navigation. Before you can learn this principle, you have to understand some Smarty basics. When we added the top navigation to the website, we used a standard template for the navigation. It displays the navigation as an unordered HTML list. Imagine that you need a kind of footer navigation where all the links from the top navigation are shown. You do not need an unordered HTML list in this case. You just would like to show all links in one line separated by a pipe (|) shown as follows: Our Company | Announcements | History | Team | Photo gallery …… This means that you need a completely different HTML markup for this kind of navigation. The great advantage of CMS Made Simple is the ability to display a template in template. While you can use the main template to define the whole layout for the page, the  HTML markup of the navigation is saved in its own template. This navigation template is just a piece of the HTML code that is added to the main template at the place where the tag {menu} is placed.

Setting up ExtVal As with all other libraries, we start by downloading ExtVal and installing it in our project. As with many other JSF libraries, the ExtVal project has different branches for JSF 1.1 and 1.2. The first two digits of ExtVal’s version number are the JSF version they are made for. So ExtVal 1.1.x is the xth version of ExtVal for JSF 1.1, whereas ExtVal 1.2.x is the xth version for JSF 1.2. Versions of ExtVal are not released very often. At the time of writing this article, only two official releases have been published for each branch. According to the lead developer of ExtVal, a third release (1.1.3 and 1.2.3) is in the works for both branches, as well as a first release from the new JSF 2.0 branch. Apart from stable releases, ExtVal offers snapshot builds that are created on a regular basis. The snapshots are created manually, which gives some guarantees about the quality compared to automatically-created daily releases. No snapshots with major bugs will be created. According to the lead developer of ExtVal, the snapshot builds have “milestone quality”. Because of some issues and limitations in ExtVal 1.2.2, a snapshot build of ExtVal 1.2.3 was used while writing this article. A stable release of ExtVal 1.2.3 is expected to be available soon after the publishing date of this article. Stable releases can be downloaded from the ExtVal download site at http://myfaces.apache.org/extensions/validator/download.html. The downloaded ZIP file will contain all of the ExtVal modules, as listed in the next table. Note that more modules may be added to ExtVal in future releases. It is also possible that additional support modules will be provided by others. For example, a JSF component project may create a support module to get the most out of its components with ExtVal. Regarding component support modules, it is also worth mentioning the “Sandbox 890” project, which provides proof of concept implementations of support modules for some non-MyFaces component libraries. Currently, proofs of concept are available for IceFaces, PrimeFaces, RichFaces, and OpenFaces. Library Description myfaces-extval-core-1.2.x.jar The core of ExtVal. This library should be added to the project in all cases. myfaces-extval-property-validation-1.2.x.jar Extension module that adds several custom ExtVal annotations that we can use in our Model layer. myfaces-extval-generic-support-1.2.x.jar Extension module for generic JSF component support. This library should be added to the project in almost all cases. There are two cases when we don't need this generic support library, which are as follows: If we're using a support library for a specific component library, such as the Trinidad support module mentioned in the following row in this table If the component library we're using is 100% compliant with the JSF specification, which is almost never the case If no specific support module is in use, and it is unclear if the generic module is needed, it is safe to add it anyway. It is also a good idea to take a look at the Tested Compatibility section on the ExtVal wiki at http://wiki.apache.org/myfaces/Extensions/Validator/. myfaces-extval-trinidad-support-1.2.x.jar Extension module that supports the MyFaces Trinidad JSF components. If we use this one, we don't need the "generic support" module. The Trinidad support module will make use of Trinidad's client-side validation options where possible. So we get client-side validation based on annotations in our Model with no extra effort. myfaces-extval-bean-validation-1.2.x.jar Extension module that adds support for Bean Validation (JSR 303) annotations. This module will be available from the third release of ExtVal (*.*.3). Snapshot builds of ExtVal can be downloaded from ExtVal’s Maven snapshot repository, which can be found at http://people.apache.org/maven-snapshot-repository/org/apache/myfaces/extensions/validator/. In the case of snapshot builds, no single ZIP file is available, and each module has to be downloaded separately as a JAR file. Note that if Maven is used, there is no need to manually download the snapshots. In that case, we only have to change the version number in the pom.xml file to a snapshot version number, and Maven will automatically download the latest snapshot. The following table lists the URLs within the Maven repository from where the modules can be downloaded: Module URL Core myfaces-extval-core/ Property validation validation-modules/myfaces-extval-property-validation/ Generic support component-support-modules/myfaces-extval-generic-support/ Trinidad support component-support-modules/myfaces-extval-trinidad-support/ Bean validation (JSR 303) validation-modules/myfaces-extval-bean-validation/ URLs in this table are relative to the URL of the Maven repository that we just saw. After each URL, 1.2.x-SNAPSHOT/ has to be appended, where 1.2.x has to be replaced by the appropriate version number. Once we’ve finished downloading, we can start adding the JARs to our project. ExtVal differs in one thing from other libraries—it needs to access our Model and View project. So we have to add the ExtVal libraries to the lib directory of the EAR, instead of the WAR or the JAR with the entities. Some libraries that ExtVal uses have to be moved there as well. If we don’t do this, we’ll end up with all sorts of weird exceptions related to class-loading errors. Libraries that are added to the lib directory of an EAR are automatically available to all contained WAR and JAR files. However, depending on the IDE and build system that we are using, we may have to take some additional steps to be able to build the WAR and JAR with dependencies to the libraries in the EAR’s lib directory. This image shows a simplified structure of the EAR with ExtVal’s libraries added to it. Note that the MyFaces ExtVal and dependencies node in the image actually represents multiple JAR files. It is important to verify that none of the libraries that are in the lib directory of the EAR are included in either the WAR or the entities JAR. Otherwise, we could still encounter class-loading conflicts. The following table lists all of the libraries that have to be moved into the EAR to avoid these class-loading conflicts: Library Explanation myfaces-extval-*.jar Of course, all of the needed ExtVal JARs should be in the EAR. asm-1.5.x.jar, cglib-2.x_y.jar These are libraries that ExtVal depends on. They are bundled with the ExtVal download. They're not bundled with snapshot releases. jsf-facelets.jar We're using Facelets, so ExtVal has to use it to add validations within our Facelets pages. So if we didn't use Facelets, this one would not be needed. myfaces-api-1.2.*, myfaces-impl-1.2.* We're using MyFaces Core as JSF implementation. ExtVal will need those libs too. Note that if we use the application server's default JSF implementation, we don't have to add these either to the EAR or to the WAR. trinidad-api-1.2.*, trinidad-impl-1.2.* We're using Trinidad, and ExtVal offers some Trinidad-specific features through the "Trinidad support" extension. In that case, the Trinidad libraries should be in the EAR too. commons-*.jar Various libraries that we just mentioned depend on one or more libraries from the Apache Commons project. They should also be moved to the EAR file to be sure that no class-loading errors occur. Note that the aforementioned changes in our project structure are necessary only because we chose to have our Model layer in a separate JAR file. In smaller projects, it is often the case that the whole project is deployed as a single WAR file without enclosing it in an EAR. If we had chosen that strategy, no changes to the structure would have been necessary and we could have added all of the libraries to the WAR file, as we would do with any other library. Other than including the necessary libraries as discussed before, no configuration is needed to get started with ExtVal. ExtVal uses the convention over configuration pattern extensively. That means, a lot of sensible defaults are chosen, and as long as we’re satisfied with the defaults, no configuration is needed. The next section will get us started with some basic ExtVal usage. Bug with Trinidad tables There’s a bug in ExtVal that can cause some weird behavior in Trinidad’s <tr:table> component. Only the first row will be populated with data, and other rows will not show any data. This happens only when a Facelets composite component is used to add the columns to the table—exactly what we do in our example application. The bug can be found in the JIRA bug tracker for ExtVal at https://issues.apache.org/jira/browse/EXTVAL-77.. There’s a workaround for the bug that we can use until it gets fixed. Be warned that this workaround may have other side effects. This workaround is shown in the following code snippet, in which we have created a class called DevStartupListener: public class DevStartupListener extends AbstractStartupListener { @Override protected void init() { ExtValContext.getContext().addGlobalProperty(ExtValRendererProxy.KEY, null, true); } } The required imports are in the org.apache.myfaces.extensions.validator.core package and subpackages. Register this class as a phase listener in the faces-config.xml file: <lifecycle> <phase-listener>inc.monsters.mias.workaround.DevStartupListener</phase-listener> </lifecycle> You’re all set, and the <tr:table> will now act as expected. Don’t forget to remove this workaround if the bug gets fixed in a future release of ExtVal. Basic usage After setting up ExtVal, the basic usage is very simple. Let’s explore a simple example in our MIAS application. In our Kid.java entity, we have some JPA annotations that map the properties of the Kid bean to a database table. Let’s take a closer look at the lastName property of our Kid bean: @Column(name = "LAST_NAME", nullable = false, length = 30) private String lastName; The @Column annotation maps the lastName property to the LAST_NAME column in the database. It also shows some information that is derived from the table definition in the database. nullable = false means the database won’t accept an empty value in this field, and length = 30 means that no more than 30 characters can be stored in the corresponding database column. This information could be used for validation in our View layer. If we hadn’t used ExtVal, we would have added a required="true" attribute to the input element in our EditKid.xhtml page. We also would have added a <tr:validateLength > component to the input component, or we could have set the maximumLength attribute. But all of these things would have been a duplication of information and logic, and would thus break the DRY principle. With ExtVal, we don’t have to duplicate this information anymore. Whenever ExtVal encounters a nullable = false setting, it will automatically add a required="true" attribute to the corresponding input element. In the same way, it will translate the length = 30 from the @Column annotation into a maximumLength attribute on the input component. The next screenshot shows ExtVal in action. (Note that all validators, and the required and maximumLength attributes were removed from the JSF code before the screenshot was taken.) The really nice thing about this example is that the validations created by ExtVal make use of Trinidad’s client-side validation capabilities. In other words, the error message is created within the user’s web browser before any input is sent to the server. Complementing JPA annotations It’s nice that we can reuse our JPA annotations for validation. But the chances are that not all validation that we want can be expressed in JPA annotations. For that reason, ExtVal offers a set of extra annotations that we can add to our beans to complement the implicit validation constraints that ExtVal derives from JPA annotations. These annotations are a part of the myfaces-extval-propertyvalidation-1.2.x.jar library. For example, if we want to add a minimum length to the lastName fi eld, we could use the @Length annotation as follows: @Length(minimum = 5) @Column(name = "LAST_NAME", nullable = false, length = 30) private String lastName; Note that if, for some reason, we couldn’t use the length = 30 setting on the @Column annotation, the @Length annotation also has a maximum property that can be set. The @Length annotation can be imported from the org.apache.myfaces.extensions.validator.baseval.annotation package, which is where the other annotations that ExtVal offers are also located. The following image shows the minimum length validation in action: As the example in the screenshot shows, setting a minimum input length of five characters for a name might not be a good idea. However, that’s an entirely different discussion Using ExtVal annotations for standard JSF validators For each of the validator components that is a part of the JSF standard, there is an annotation in ExtVal’s Property Validation library. These are covered briefly in the following subsections. Note that ExtVal will automatically use any overridden versions of the standard validators, if they are present in the project. Defining length validation For the length validation of input strings, the @Length annotation can be used, as shown in the previous example. This annotation relies on the javax.faces.validator.LengthValidator to implement the validation. The following table lists the available properties: Property Type Explanation minimum int The minimum length (inclusive) in characters of the input string maximum int The maximum length (inclusive) of the input string in characters Defining double range validation To validate if a double value is within a certain range, the @DoubleRange annotation can be used, which delegates the implementation of the validation to the javax.faces.validator.DoubleRangeValidator validator. See the following table for the available properties: Property Type Explanation minimum double The minimum value (inclusive) of the double input maximum double The maximum value (inclusive)of the double input Defining long range validation What @DoubleRange annotation does for doubles, the @LongRange annotation does for long values. It uses javax.faces.validator.LongRangeValidator for the implementation: Property Type Explanation minimum long The minimum value (inclusive) of the long input maximum long The maximum value (inclusive) of the long input Defining required fields The example given at the beginning of this section showed how ExtVal can create a required="true" attribute based on an @Column annotation with the nullable = false setting. If it is not possible to use this setting, ExtVal also has an alternative @Required annotation . Just add this annotation to a field to make it required Using ExtVal’s additional annotations Apart from the annotations that correspond to the standard JSF validators, some additional annotations exist in the Property Validation module that perform other validations. These are listed in the following subsections. Whereas the validations based on the JSF standard validators use the error messages provided by the JSF validators, the additional validations cannot use standard messages from JSF. Therefore, standard messages are provided by ExtVal. Should you want to use your own message, all additional annotations have a validationErrorMsgKey property that can be used to assign a message key for the error message. We’ll discuss custom error messages in more detail later in this article. Defining pattern-based validation Validation with regular expressions is very powerful, and is very usable for validating phone numbers, postal codes, tax numbers, and any other data that has to fit in a certain pattern. Regular expression-based validation can be added by using the @Pattern annotation. For example, to allow only letters and spaces in the firstName field, we could write: @Pattern(value="[A-Za-z ]*") @Column(name = "FIRST_NAME", nullable = false, length = 30) private String firstName; For completeness, the following table lists the arguments of the @Pattern annotation: Property Type Required Explanation value String[] Required Array of regular expression patterns. Beware if you add more than one pattern that the input must match all patterns. It is easy to make any input invalid by using two patterns that are mutually exclusive. validatonErrorMsgKey String Optional Optional key for alternative error message.

We have focused mainly on organizing content rather creating content in your wiki in this article. We assume you should have a few pages in your wiki. As our wiki grows in popularity, the amount of content it hosts will continue to grow so it is important to organize the content in your wiki so that our wiki looks better to our visitors and editing and reviewing content is much easier for our users. If we think of our wiki as a library, it is easy to see why we need to organize our wiki. After all, if you walk into a library with no system for organizing the books, movies, music, periodicals, and others you would find it hard to locate what you are looking for. Likewise, if we have no order in our wiki, then our visitors could find themselves frustrated when trying to find the information they are looking for. If they become too frustrated, they will go elsewhere. Namespaces Namespaces are used by MediaWiki to group together pages that have a similar purpose such as Help pages, User profiles, or Talk pages. This is not to be confused with pages that contain similar content. These pages are grouped by categories which we will discuss later in this article. Pages that exist within a namespace in a wiki are noted by the namespace prefix that helps to form the title of the page. For example, if we have a page called Uploading a video file that exists in the Help namespace, it would appear as Help:Uploading a video file. Perhaps you want to create a new page for an upcoming marketing project for your company. This would appear as Project: Marketing project. MediaWiki makes use of 18 built-in namespaces. The odd number namespaces are talk namespaces while even numbered ones represent subject namespaces. Numerical index Namespace Description 0 Main This groups together a majority of the site's content. There is no namespace prefix for the mainspace. 1 Talk The discussion pages attached to the mainspace pages. 2 User Pages that contain information about users and their history. 3 User talk Used to leave messages to a user. 4 Project Used for information related to the operation and development of the wiki. This is also known as the meta namespace. 5 Project talk Used to discuss project pages. 6 File Stores metadata for files uploaded to the wiki. This includes images, sound, video, and other files accessed through the Media namespace. 7 File talk Used to discuss files and media. 8 MediaWiki Contains system messages and other important content. 9 MediaWiki talk Discussion pages related to the MediaWiki namespace. 10 Template Used to hold templates used in the wiki. 11 Template talk Discussion pages for the various templates used in the wiki. 12 Help Holds help files, how-tos, and other instructions for users. 13 Help talk Used to hold discussions related to the help files. 14 Category Holds information related to the different categories created for the wiki. 15 Category talk Used to hold discussions regarding the wiki's categories. -2 Media Used for direct linking to media files [[Media:song.ogg]] rather than the information page. -1 Special Groups special pages created by MediaWiki itself. Talk pages are accessed by clicking on the discussion tab at the top of a page. The last two namespaces, denoted by the negative sign, are used for pages created by MediaWiki. Users cannot create, delete, or edit any pages in these two namespaces without special extensions. The remaining 16 namespaces are all used for user-created content. The following screenshot shows the Help namespace for the Joomla! documentation wiki (http://docs.joomla.org/Beginners ): Time for action – creating a page in a namespace Content that is housed in many of the namespaces is created on the fly. For instance, when you first register as a user, a new page in the User namespace is created. When you create a Help page, a new page appears in the Help namespace. If you add to the discussion page for an article on your wiki, a new talk page is created. For Main, Project, Template, Help, and Category pages, we can add new pages directly into the namespace. For example, if our IT department wanted a user manual for a new software package that was just installed, we could create a project page for this. In this instance, we would have to designate the namespace or it would default to a regular article. Open your wiki in your browser and log in. In your browser's address bar, type the following: http://www.yoursitename.com/index.php/Project:Project page name. For the example site, I will be entering: http://www.flosspropopulo.com/index.php/Project:Using our new software . Hit Enter. Your new page should open up and look similar to the following screenshot: Right now, the project page tab is red because the page doesn't exist yet. Click on the edit this page link to create the page. When you are satisfied with the page, click Save page. When the page has been saved, it will look similar to this: You may have noticed that while the tab reads project page, the namespace is the title of our wiki. In this example, Floss Pro Populo appears instead of the word Project. As the project page deals with organization of the wiki, it defaults to the wiki's sitename to represent a project taking place within the wiki itself. This can be changed; however, it is something that should be done by more advanced MediaWiki administrators. What just happened? Instead of simply creating a new page, we used the URL to create a new page and included it in a specific namespace. In this example, we created a new Project page explaining the project that will include creating a user manual for a new software package. We also saw that of the 18 namespaces, we can directly create new pages using this method in only five of them. The other 13 namespaces have their pages created by MediaWiki itself when different actions are taken. If you try to create a page in a namespace that doesn't exist, it will default to the Main namespace. MediaWiki will not create the new namespace for you. Pop quiz – namespaces Namespaces are important because they help keep our pages organized. As an administrator, it is important to know what kind of pages the different namespaces hold so we can find what we are looking for. To make user that you have a solid grasp of namespaces, let's take a moment to test your knowledge. All namespaces can be edited by the users. True False Most pages in the namespaces are created by MediaWiki when the user does something. Which of the following namespaces allows the user to directly create a new page (by using the URL)? Help File Special User According to the example above, which URL will correctly create a new page in the Category namespace? Category:New page http://www.wikiname.com/Category:New page http://www.wikiname.com/index.php/Category:New page

Authorization with Zend_Acl in Zend Framework We now have a way to check if a user is who he/she says he/she is. Next we need to stop certain users from accessing certain parts of the application. To do this, we are going to use the Zend_Acl component Zend_Acl introduction ACL (Access Control List) lets us create a list that contains all the rules for accessing our system. In Zend_Acl, this list works like a tree enabling us to inherit from rule to rule, building up a fi ne-grained access control system. There are two main concepts at work in Zend_Acl—Resources and Roles. A Resource is something that needs to be accessed and a Role is the thing that is trying to access the Resource. To have access to a resource, you need to have the correct Role. To start us off, let's fi rst look at a basic example. In this example, we are going to use the scenario of a data centre. In the data centre, we need to control access to the server room. Only people with the correct permissions will be able to access the server room. To start, we need to create some Roles and Resources. $visitor = new Zend_Acl_Role('Visitor');$admin = new Zend_Acl_Role('Admin');$serverRoom = new Zend_Acl_Resource('ServerRoom'); Here we have created two Roles—Visitor and Admin and one Resource—ServerRoom. Next, we need to create the Access Control List. $acl = new Zend_Acl();$acl->addRole($visitor);$acl->addRole($admin, $visitor);$acl->add($serverRoom); Here we instantiate a new Zend_Acl instance and add the two Roles and one new access rule. When we add the Roles, we make the Admin Role inherit from the Visitor Role. This means that Admin inherits all the access rules of the Visitor. We also add one new Rule containing the ServerRoom resource. At this point, access to the server room is denied for both Visitors and Admins. We can change this by adding allow or deny rules: Allow all to all resources: $acl->allow(); Deny all to all resources: $acl->deny(); Allow Admin and Deny Visitor to all resources: $acl->allow($admin); Allow Admin and Deny Visitor to ServerRoom resource: $acl->allow($admin, $serverRoom); When adding rules, we can also set permissions. These can be used to deny/allow access to parts of a Resource. For example, we may allow visitors to view the server room but not access the cabinets. To do this, we can add extra permission options to our rules. Allow Visitor and Admin to view the ServerRoom, Deny Visitor cabinet access: $acl->allow(visitor, $serverRoom, array('view'));$acl->deny($visitor, $serverRoom, array('cabinet')); Here we simply add the new permissions as an array containing the strings of the permissions we want to add to the ServerRoom resource. Next we need to query the ACL. This is done through the isAllowed() method. $acl->isAllowed($admin, $serverRoom, 'view');// returns true$acl->isAllowed($visitor, $serverRoom, 'view');// returns true$acl->isAllowed($visitor, $serverRoom, 'cabinet');// returns false As we can see, Zend_Acl provides us with an easy, lightweight way of controlling access to our systems resources. Next we will look at the ways in which we can use the ACL component in our MVC application. ACL in MVC When looking to implement ACL in MVC, we need to first think about how and where we implement the ACL in the MVC layers. The ACL by nature is centralized, meaning that all rules, permissions, and so on are kept in a central place from which we query them. However, do we really want this? What about when we introduce more than one module, do all modules use the same ACL? Also we need to think about where access control happens—is it in the Controller layer or the Model/Domain layer? Using a centralized global ACL A common way to implement the ACL is to use a centralized ACL with access controlled at the application level or outside the domain layer. To do this, we first create a centralized ACL. Typically, this would be done during the bootstrap process and the full ACL would be created including all rules, resources, and roles. This can then be placed within the Registry or passed as an invoke argument to the Front Controller. We would then intercept each request using a Front Controller plugin (preDispatch). This would check whether the request was authorized or not using the ACL. If the request was not valid, we would then redirect the request to an access denied controller/action. This approach would base its rules on the controller/action being requested, so a rule using this may look something like: $acl->allow('Customer', 'user', 'edit'); Here we would allow access for a Customer Role to the User Resource and the Edit permission. This would map to the user Controller, and the edit action or user/edit The advantages of using centralized global ACL are as follows: Centralized place to access and manage ACL rules, resources, and roles Maps nicely to the MVC controller/action architecture The disadvantages are as follows: Centralized ACL could become large and hard to manage No means to handle modules We would need to re-implement access controls in order to use our Domain in a web service, as they are based on action/controller Using module specific ACL's The next logical step is to split the ACL so that we have one ACL per module. To do this, we would still create our ACL during bootstrap but this time we would create a separate ACL for each module, and then we would use an Action Helper instead of Front Controller plugin to intercept the request (preDispatch). Advantages: Fixes our module handling problem with the previous approach Keeps things modular and smaller Disadvantages: We still have the problem of having to re-implement access control if we use our Domain away from the controller/action context. ACL in the Domain layer To deal with our last concern about what if we need to use the Domain in another context outside the controller/action architecture, we have the option to move all the Access Control into the Domain itself. To do this, we would have one ACL per module but would push the management of this into the Model. The Models would then be responsible for handling their own access rules. This in effect will give us a e-centralized ACL, as the Models will add all rules to the ACL. Advantages: We can use the Model in different contexts without the need to re-implement the access control rules. We can unit test the access control The rules will be based on Model methods and not depend on the application layer Disadvantages: Adds complexity to the Domain/Models Being de-centralized, it could be harder to manage For the Storefront, we have opted to use the Model based ACL approach. While it adds more complexity and implementation can be a little confusing, the advantages of being able to unit test and use the Models outside the application layer is a big advantage. It also gives us a chance to demonstrate some of the more advanced features of the ACL component.

Setting up a static front page By default, the main page of your WordPress site shows a running list of your latest posts. While this is perfectly acceptable for a personal blog, an e-commerce site typically takes a more static approach so as not to confuse any first-time visitors. Fortunately, configuring a static front page is simple. We first, need to create a new page that will become the default front page. In your WordPress Dashboard, navigate to Pages and select Add New, as shown in the following screenshot: Add any variety of information that you would like first-time visitors to see, such as a logo, a welcome message, a breakdown of product categories, or whatever you would like. When you've finished, go ahead and publish your page. The page we created for our music shop is titled Welcome. Now let's set it as the default front page. Back in the WordPress Dashboard, browse to Settings and click on the Reading option, as shown in the following screenshot: Underneath Reading Settings, select the option to display a static front page. Be sure to choose the title of the desired static page from the drop-down list. Note that we chose Welcome, the same page that we just added. The following screenshot shows the Reading Settings options: Another good option for a static front page is to directly choose the Products Page from the drop-down list. The Products Page is automatically created when you activate the e-Commerce plugin for the first time, and is essentially the gateway to your e-commerce shop. If you want customers to first see your products when they visit your site, choose this option. Using widgets Also known as "sidebar accessories", widgets are one of the slickest and easiest ways to vary the content of your WordPress sidebars. With widgets, you can elegantly add text, images, gadgets, HTML, or any other design elements to one or more sidebars on your site. A growing number of plugins for WordPress also come with additional widget features, including the WP e-Commerce plugin. To get started with widgets, navigate to Appearance in your Dashboard and click on Widgets, as shown in the following screenshot: Feast your eyes on the number of Available Widgets. The following screenshot shows the different widgets available: Adding a widget to your desired sidebar is a simple, click-and-drag affair. You can add as many widgets as you like to the sidebar, and re-arranging them is as easy as dragging and dropping them. Here are the three widgets that we added to our music shop: a Search box, a Text Widget, and the Shopping Cart. The Shopping Cart widget is shown in the following screenshot: Creating text widgets For an e-commerce site, a text widget is like a Swiss Army Knife since it's one simple tool that can serve a variety of purposes. Here are a few tasks that text widgets can accomplish: Create a "Featured Product" widget and rotate the contents every few days or weeks Add a custom image that links to a specific product category, such as "Albums" or "Singles" Create an HTML drop-down list with links to all product categories Add notices about sales or special discounts Here's an example: let's say we want to let our customers know about a special coupon code for our shop that is valid during the month of April. A text widget is the perfect way to let all visitors know about the sale. Drag-and-drop an empty text widget and place it in the sidebar. It should expand automatically, and now we can type all of the necessary text and HTML. In the following screenshot, we've added some text and a little HTML. The Title of the text widget is now April Sale! The <p> tags simply format the text into paragraphs, and the <strong> tag makes the coupon code show up in bold text. The usage of these tags is shown in the following screenshot: Be sure to save all of the changes once you have created the text widget. If we now take a look at the front page of our music shop, we can see the widget layout and the sale information in the WordPress sidebar, as shown in the following screenshot:

Installing the WP e-Commerce plugin At this point, you should already have WordPress installed. If you do not, please visit http://wordpress.org/download/ to grab the latest version. Some web hosts also offer a one-click install of WordPress via cPanel or another control panel. Installing the WP e-Commerce plugin is no different than installing other WordPress plugins. There are two ways to do so: Directly from the WordPress Dashboard Manually using your favorite FTP program Installing from the WordPress Dashboard This is by far the easiest and most convenient way to install new plugins for WordPress. All you need to do is log in to your Dashboard, expand the Plugins menu in the left-hand side column, and click on Add New, as shown in the following screenshot: In the Search box that displays on the resulting page, ensure that Term is selected as your search option, and perform a search for e-commerce. The WP e-Commerce plugin should be one of the top results. The following screenshot shows the Search Plugins option: All that's left is to click on the Install button, and WordPress will handle the rest of the installation for you. The following screenshot shows the search results with the WP e-Commerce plugin on top: Manual installation If you prefer the tried-and-true method of installing plugins manually, that's also an option. First, download the latest version from: http://getshopped.org or use the alternate download site: http://wordpress.org/extend/plugins/wp-e-commerce/. Next, decompress the downloaded ZIP archive with the tool of your choice. We should now have a folder called wp-e-commerce, as shown in the following screenshot: Using your preferred FTP/SFTP program, we need to upload that entire folder to the wp-content/plugins directory on your server. See the following screenshot to view the wp-e-commerce folder properly uploaded next to a few other plugins: The full path to the wp-e-commerce directory should be: <your WordPress install>/wp-content/plugins/wp-e-commerce/. Plugin activation Now that we have successfully uploaded the plugin, let's activate it. Open your web browser and log in to your WordPress Dashboard. Under the Plugins section, you should now see an inactive plugin called WP Shopping Cart, as shown in the following screenshot: Click on the Activate button to enable the plugin. On the left-hand side of the WordPress Dashboard, we now have a new section called Products, as shown in the following screenshot: Congratulations! You have now taken the first crucial step in building an e-commerce site. Let's now continue paving the way for our shop by addressing some functional and cosmetic issues within WordPress. Installing third-party themes One of the major strengths of WordPress is how easy it is to customize and alter. This is especially true with regard to themes. If you have the knowledge, experience, and patience to build a theme for your site completely from scratch, you are more than welcome to do so. For the rest of us, it's easy to install and tweak a pre-built third-party theme. The official site for previewing and downloading WordPress themes is: http://wordpress.org/extend/themes/. As of this writing, there are well over 1,000 themes available. Most third-party themes are free, though a number of so-called "premium" themes are also available at varying price levels. For our upcoming music shop, let's select a free theme. One popular and appropriate option is the Crafty Cart theme (http://bit.ly/crafty-cart). This theme just happens to be designed with the e-Commerce plugin for WordPress in mind, making it a solid starting point for our shop. Another nice feature is that it's completely free to use for both personal and commercial purposes. No matter which theme you choose, all third-party themes can be installed in one of the following two ways: Through the WordPress Dashboard Manually via FTP

Your Site, Your Database The database that we created when we installed PHP-Nuke is PHP-Nuke's storage repository. That may sound like a rather trivial remark; we know PHP-Nuke is a database-driven web content management system. However, it is worth understanding the nature of what PHP-Nuke stores. PHP-Nuke stores not only information about registered users of the site, and such things as your news stories, features about you, your company, or your club, your photos and other images, but also stores all the information about your site and the content it holds. In its database, PHP-Nuke stores such things as the name of your site, the site URL, the site logo, how many stories are displayed on the front page, whether users can comment anonymously on stories, the footer text displayed at the bottom of the page, how many people have read the stories, the voting information about stories, and also what layout and choice of colors are used to display the site. There are many, many more things PHP-Nuke squirrels away into its database, but the point in general is that your site is determined by the contents of its database. This may sound rather overwhelming, particularly if you are new to databases—but this is precisely where the real power of PHP-Nuke lies. You don't have to be a MySQL master or know anything about the finer points of database theory; in fact, you generally won't be touching the database yourself. PHP-Nuke has a powerful web-based administration tool that lets you control and maintain your site. Through it you are effectively managing the database but this is happening behind the scenes and it is not something that you need to overly concern yourself with. Visiting the Administration Area With PHP-Nuke's awesome administration tool, you manage your site through your browser, controlling almost every aspect of its behavior, as well as adding and maintaining the content that is displayed. This doesn't mean that anyone can mess with your site; access to the administration area is restricted. You, the super user, as head of administrators have supreme power and can even appoint other people to act as limited administrators, with specific abilities to moderate and approve content for certain parts of the site. PHP-Nuke's administration area can sometimes feel too comprehensive and often be overwhelming, occasionally counterintuitive in its behavior. This is the jungle we will beat our way through in the next few articles of the series, and in fact, it's where you will spend most of your PHP-Nuke life (the administration area, not these articles!). The first thing to do is to log in to the administrator account. Enter the following URL into your browser: http://localhost/nuke/admin.php If you are not already logged in, you will be prompted for the administrator username and password created in the previous article—Your First Page with PHP-Nuke. Enter these and click the Login button to proceed. Once you log in, you will be in the administration area and are confronted with two monstrous administration menus in the center of the screen: This is the central hub of the administration interface. Each of the icons you see on screen is a link to specific parts of the administration area, responsible for the control and management of particular features. If you scroll down the page, you will find some panels with information about the current home module, how many users are online, and some details of recently published stories, although at the moment, there is not much to see in any of these displays since we have no content or users! The top menu of the administration interface, the Administration Menu, has icons for general 'system' management functions. These control the 'core' operations of PHP-Nuke, such as: Block and module management Database backup and optimization Banner management, users and user groups, and newsletters Site configuration Logging out of the administrator account The lower menu, Modules Administration, has icons that take you through to the administration areas of individual modules. There is also another logout link. Note that if you are using a version of PHP-Nuke earlier than 7.5, there is only one large menu, the Administration Menu, and this contains all the above icons mixed in together. The two-menu split emphasizes the division of labor for managing a PHP-Nuke. The top menu has tasks for maintaining and configuring the site. The bottom menu has tasks for maintaining and configuring individual modules. First experiences of the administration menu are often perplexing—you click on one of the images and the page reloads, but nothing seems to have happened. The menus are still there in the middle of your page, grinning at you. (Particularly the rather gruesome looking IP Ban icon; you may begin to believe its eyes follow you around the room.) What you're actually after is displayed below the menus. By default, the administration menus are always displayed at the top of the page in the administration area; the action you're trying to do is contained in the panels underneath, and you will generally have to scroll down to get at what you want. Possibly, if your screen resolution is sufficiently high and your browser window sufficiently sized, then you won't get this problem, but for most of us, we will find ourselves wondering if anything has happened. The advantage of these ever-present menus is that if you suddenly find yourself needing to switch to another task, you simply scroll back up to the top of the page and click on the desired icon. If you want to return to the administration homepage at any point, you can either enter the URL of the administration homepage (http://localhost/nuke/admin.php) or if you glance to the left-hand side of your page, you will see the Administration block. The top link in this block, Administration, returns you to the administration homepage. This block is ever present if you are logged in as the administrator. Administrator movements are not necessarily restricted to the 'back end' (the administration interface) of the site. You can also visit the 'front end' of the site and view the site as your visitors see it. However, for the administrator, extra, context-sensitive links appear on various items that provide you with a fast track to the administration area, and let you control that item. We'll see more of these links as we look in detail at the default modules over the next few articles of the series. Also, there are special blocks that are only visible to the administrator, the Administration block being one of them. You can replace the graphical administration menus by a more manageable text menu, but for now we will be working in the more familiar graphical environment, at least until we know our way round. Site Preferences Our first job will be to change some global settings of our site; we do so by clicking on the Preferences option: When you do this, the page will reload and the Administration Menu will reappear, and then you should scroll down to the Web Site Configuration menu. This is a long list of options; the top part is shown in the following figure: At the foot of the list is a Save Changes button (not seen in the screenshot as it is too far below). This button has to be clicked for any changes to persist. The list of Web Site Configuration options is divided into a number of panels, grouping together options for particular tasks: General Site Info Multilingual Options Banners Options Footer Messages Backend Configuration Mail New Stories to Admin Comments Moderation Comments Option Graphics Options Miscellaneous Options Users Options Censure Options We won't look at all of these panels now; instead we will look at them as we need them. For example, when covering story management in the article—Story Management with PHP-Nuke, we'll explore the Comments Moderation, Comments Option, Censure Options, Backend Configuration, and the Mail New Stories to Admin panels. We shall now look at some of the options in General Site Info; these control some basic options for our site. First up is the Site Name option. This is the name of your site, and is usually displayed in the title-bar at the top of the browser. It also used in any text referring to your site, such as email messages automatically sent out by the site (for example, the confirmation message sent to a user who has created an account on your site). Let's stamp the identity of this site, by changing the Site Name value to the Dinosaur Portal: Now scroll to the bottom of the list of preferences where you see the Save Changes button. Click this to update your site. After the page reloads, you should see that the title bar in your browser has changed from PHP-Nuke Powered Site to our new site name—the Dinosaur Portal. When the page reloads, you are still on the Web Site Configuration menu page. This is good in case you need to make any further changes, or if you got something wrong with the last change you made. There are some parts of the PHP-Nuke administration interface where clicking a Save or Ok button does not keep you in the same part of the administration interface but returns you to the administration homepage. This kind of thing can make you lose your bearings early on. Although we only made one change before clicking the Save Changes button, you can, of course, make as many changes to the preferences as you like before clicking the button. The Site URL is important too. This field holds the URL of your site homepage (without the index.php bit). If you specify the wrong Site URL or, more likely, forget to change it from http://phpnuke.org, then the consequences are not drastic; visitors will not suddenly find themselves transported to another site when they click a link on your site. However, the Site URL is used in emails sent to newly registered users with a link to confirm their registration. With the wrong Site URL here, people will go to the wrong site to register (and fail!). We will remind you of this when we discuss emails sent out by the system. Let's change the Site URL before we forget. Since our site is at http://localhost/nuke, enter that into the Site URL field, and then scroll down and click the Save Changes button. The Site Slogan, Site Start Date, and Administrator Email are straightforward to change. The Administrator Email account is the email account that will be used to send out user registration confirmations. The Site Slogan value is used in the META DESCRIPTION tag in the page header of your page: <META NAME="DESCRIPTION" CONTENT="Your slogan here"> This tag is used by some search engines to create the description of your page in its listing. (That is when you are visited by search engines, which is still a long way off!) By default, the value of the META DESCRIPTION tag is fixed for all pages in PHP-Nuke, and takes the value of your Site Slogan field. The Site Logo specifies an image used by some modules to 'stamp' their pages. This value does not control any site logo image that may appear in the site banner at the top of your page. Another interesting option is the Default Theme for your site. This gives you a drop-down box with a list of the currently installed themes. Select NukeNews from the list, scroll down, and click Save Changes. When the page reloads, it looks rather different: Not bad for two clicks of a mouse. We just changed the site's default theme and immediately the new theme has been applied, and we now have a very different looking site. It still 'works' the same, but it looks very different. One of the most obvious changes is the icons in the Administration Menu. There are some standard images in PHP-Nuke that can be overridden by images from the theme. The icons in the Administration Menu are one set of images that can be overridden like this. Every visitor sees the theme that is specified as the default theme. Registered users have the option to choose their own theme, to personalize the site to their liking. Now let's select the DeepBlue theme from the list of themes and click the Save Changes button. In the next few articles we're going to see a lot of screenshots from the PHP-Nuke administration interface and the front end, and they're all going to be taken with the DeepBlue theme. If you're not using this theme as you follow along, things could look different. The DeepBlue theme is the default theme. Turning off the Graphical Icons For future reference, if you get sick of the Administration Menu icons (perhaps the terrifying IP Ban icon is finally getting to you), the Graphics Options panel is where you can turn off the graphical administration menu: We will leave it set to Yes for now as we explore the administration interface. When you feel more confident, you can return here and set it to No to replace the graphical menu by a text menu. The Cookie Crumbles That's enough of the Web Site Configuration menu for now. Don't worry; we will come back to it over the next few articles. Your next task is to close your browser. Now open a new browser window, and navigate to your site's homepage (http://localhost/nuke/). You will notice that you are still logged in as the administrator—you can see the Administration block in the left-hand side column. You may find this rather strange—you didn't enter a username or a password or go through the admin.php page, so how did it know? The answer is a cookie. PHP-Nuke issues cookies to visitors, which contain a number of user preferences, including their login details. This means that when the visitor returns to the site they are identified, and dealt with accordingly. This explains why you are logged back in as an administrator without having taken any action. An annoying side-effect is that if you wanted to view the site as a visitor and administrator at the same time, you would have to log out and log in again before viewing. Should you find yourself doing this often, an obvious solution is to use two different types of browsers—say Mozilla Firefox and Internet Explorer (cookies are distinct on the two applications)—so one can be your administration browser and the other can be your visitor browser.

Menus and content in Joomla! are closely intertwined. If you have experience building websites the old fashioned way, menu links don't just point to existing pages, as you might expect. When adding a menu link, you don't just tell Joomla! what page the menu link should point to, but you rather instruct it to make that page. By creating menu links, you created different types of pages. However, to your visitor, Joomla! menus are no different from other website menus. To your visitor, menus should provide an easy means of navigation.In this article, we'll concentrate on menus as a means to navigate. We'll focus on how you can make and tweak menus to design clear and intuitive navigation, and also on how you can help the visitors find what they want without difficulty. Up to now, you've added menu links using mainly the default settings. Let's find out how we can enhance menus and improve the navigability of the site. How many menus can you have? On any Joomla! website you can create as many menus as you want. The default sample site is a good example as it contains no fewer than six menus. On the home page four of those are shown: the horizontal Top Menu, the Main Menu, the Resources Menu, and the Key Concepts Menu. In the backend, all of the menus are listed in the Menu Manager (Menus | Menu Manager). At least one menu, the Main Menu, is needed for Joomla! to function properly. The other ones, such as the  Top Menu (the top horizontal menu) and the User Menu (a menu that's only visible after users have logged in), are only there to showcase Joomla!'s menu possibilities. In real life you'll probably just confuse your visitors with that amount of navigation options popping up on different pages and places. However, it's great to be able to create as many menus as you like. This allows you to set up different menus for different functions and different users. You can have a main menu (at the top of the page) containing primary links, and another menu (somewhere down the page) containing secondary links. You might also want to have a special menu with action links (such as Login, and Register) and another menu that's only shown to visitors who have logged in. Menus are modules (and why that's important) You've already seen some examples of modules in action, such as the Poll module. Remember, modules are Joomla!'s magic building blocks that can contain all kinds of functionality. Menus are modules too. In fact, every new menu you add is a new instance of the mod_mainmenu module. This makes menus very flexible. Not only can you have as many menus (menu modules) on your site as you like, but you can also tell Joomla! exactly where (on what part of the screen, in which module position and when (on which specific pages, for which specific users) you want these menus to show up.Sounds confusing? Don't worry, we'll practice adding and customizing menus in this article series—and once you get the hang of it, you'll really appreciate Joomla!'s amazing menu flexibility. Creating user-friendly navigation: Cleaning up the Main Menu When building a site, you'll start by adding links to the Main Menu. It's the mandatory menu that is always part of the Joomla! installation, even if you don't install sample data. But as your site evolves, it can become a long and cluttered list of hyperlinks. Even the menu of our SRUP example site already contains eight links. When you find the Main Menu gets long and messy, what options do you have to improve site navigation? Option 1: Change the order of menu items By default, a new menu item is added to the end of the existing menu. If you were to add a new link called New Menu Item, it would show up at the bottom: In our example site we've haven't paid much attention to menu item order. However, the order in which you add items isn't necessarily the order in which you want them to be displayed to your visitor. Time for action—change menu item order On the SRUP example site main menu there are eight menu items (as you've just seen in the previous screenshot). Let's move things around to present the links in a more logical order. The items that we want to get most attention should be in the top half of the menu; links to less important or static content should be placed down below. Navigate to Menus | Main Menu. In the Order column, enter numbers to reflect the desired order of menu items. Click on the little disc icon on the top row of the Order column to apply the new order. What just happened? The menu items now show up in the order that you've chosen. News and Who are SRUP? have been moved up from their humble position. On the frontend you can see that the order of items has changed: A quick way to change the position of multiple menu items is to enter the desired order by numbers, as you've just seen. If you only want to move one or two menu items up or down you can also click on the green up and down arrows in the Order column. Option 2: Add a separate new menu Rearranging menu items is a first step—but there are definitively more powerful ways to improve a menu. You can also clean up a menu by removing links that don't really fit in, and create a separate menu for these links that you can show somewhere else on the page. This way, you can either emphasize those links in the visual hierarchy of the web page—or you can choose to make them less prominent. Let's have a look at the SRUP Main Menu items. Imagine your client has asked you to reorganize the navigation to enable visitors to quickly find the information on ugly paintings that this site is about. As the current Main Menu is rather long, it's difficult for the visitor to distinguish between links on actual ugly painting contents and links on the organization behind the site A good solution would be to create a separate menu on SRUP-related contents. Time for action—step 1: Create a new, empty menu In the Main Menu of the example site, three items are suited to be shown in another menu. These links are of interest to visitors who want to know more are about the SRUP organization. Let's create a new menu "About SRUP" so that we can move the menu links Who are SRUP?, Mission Statement, and Contact there. Navigate to Menus | Menu Manager. Click on New. In the Menu : [New] screen add a Unique name. This is the name that Joomla! uses to identify the menu; it won't be visible on the frontend. Enter a name without spaces or special characters. In the following example, we have entered aboutsrup: Enter the Title; this is the name that may be displayed with the menu. Enter a Description and a Module Title too. The Module Title will show up in the Module Manager. Click on Save. You'll be taken to the Menu Manager. At the bottom of the list you can see a new entry. The menu About SRUP has been created: What just happened? In the Menu Manager you've created new menu. It's visible in the Joomla! backend—but of course it's still empty.

Looking at just about anything worth doing, a question will often arise beginning with the words, "How do I." Often the challenge can seem daunting. Then, one finally intuits, discovers or otherwise stumbles upon the answer and simultaneously is offered several alternative opinions, each being offered as the best way to accomplish the same goal. This is the case whether planning a vacation route, taking a photograph, or creating part or all of an application. There are a number of ways to accomplish what we will be doing in the article. If you spend any time on the Drupal IRC (Internet Relay Chat) channels, you will most likely receive varying opinions as to the best approach and, perhaps, come away more confused than when you started. Sometimes, there is no clear answer. One approach would be to write custom code. Another might be to use the Panels module. Each approach is valid, and has different pros and cons in terms of features, effort, learning curve, and time. Here, we're going to face each challenge in the same way, with attachment views, which means less coding, less time, and a smaller learning curve. A view is originally a relational database term, referring to a temporary arrangement of information in the database so that it can be presented in a meaningful way which is different than the underlying table layout. The Views module accomplishes the same thing, and provides the glue to tie itself in to the rest of Drupal and, especially, the ability to theme the result with templates. In other words, it gives you the ability to look at Drupal content in a way you would otherwise be unable to (without custom code). What is an Attachment view? A view is the dynamic display of one or more pieces of related content based on one or more criterion. What does that mean in practice? Let's consider a simple example. Let's say we have created a number of nodes of the content type 'Story' and assign one or more taxonomy terms to each. Having done that, we want to be presented with a list of teasers for each Story that has 'travel' as one of its taxonomy terms. It's a fairly common requirement. If you're familiar with Joomla!, for example, it could be accomplished by means of a Section or Category Blog page. The fact, though, is that the architecture that makes Drupal so extensible results in there being no manner in which to accomplish this using a core module. Enter the Views module, which will allow us to specify that we want a page on which we want to view x number of nodes, their selection based on certain criteria, which in this case will be nodes containing the taxonomy term 'travel'. That, in a nutshell, describes views at their simplest. Now, how about Attachment views? Well, to continue using the same example, let's say that our requirement has changed, and we don't always want a page based on every node having to do with travel, but want to be able to select destinations from a list of regions shown on the same page, as illustrated in the following figure. The box on the left shows the available travel regions, each of which is a taxonomy term, with Asia having been chosen. The boxes on the right are node teasers, each of which has Asia among its taxonomy terms. How can we accomplish this? One method would be to code a custom page in PHP and display it. That would work, but it would also set the page in stone to some extent, bypassing the flexibility that Drupal provides. We could also create a menu of destination regions and put it in the sidebar as a block. That would work too, but the menu would not be dynamic, and would have to be edited each time a region was added, changed, or removed. One further option would be to have two separate views. How can we have two views though? We could create one as a block, but let's say that the design calls for the selection choices to be in the content area of the page. So, that means we need to find a way to have both views as content. Enter Attachment views. Reviewing the view requirements The business for which our website is being built is a commercial builder's. As with most construction businesses, subcontractors represent the major source of labor. On this site, Subcontractors will be the user type that will need to register, in order to subsequently review jobs and bid for them. There will be other authenticated user types, such as management, job supervisors and admin, but they will have user records created for them and will not need to register. Customers will be anonymous users. To that end, a custom profile has been created for subcontractors, to capture the necessary information. We're using the content_profile module so that each subcontractor profile will be a node. We are going to have a menu from which the user will select a contractor for which the details will be displayed. For a given view, we can create various displays. A view to be displayed like a node will have a Page display—'Page' can be thought of as a web page—and one that is to be displayed as a block will have a Block display. Considering our menu of subcontractors, and the display of a subcontractor's details, in conjunction with the terms 'Page display' and 'Attachment display', the reasonable inference is that the Attachment view will be the menu-style list of subcontractors, and the Page display will be the subcontractor details, the page being larger than an attachment, and the details being larger than the menu. However, that's not necessarily the case, and in subsequent examples we'll invert that assignment of content to display. The description of the subcontractor list may bring the thought 'Block' to mind. Often a block can be used in place of an Attachment display, and in fact, the option to create a Block display in the view is just one selection away from the Attachment type. We're using Attachment displays rather than Block displays because Attachments are not as entity-like in their construction, and are easier to place anywhere within the page content than Blocks, which are more easily placed in regions adjacent to the content area. Attachment views do not include paging as do Page views. We are only going to be showing one subcontractor's details at a time, so there is no paging issue there. However, when we list the subcontractors to select from, there could be dozens, or even hundreds, and that will require us to have paging available for that display, so the Page display for our view will be the subcontractor list. We'll build that first. Activity 2-1–Subcontractor page view The Subcontractor page will allow the user to view the details of a subcontractor chosen from a dynamic list. That is, the list of subcontractors will not be something separate that requires editing whenever a subcontractor is added or removed, and the list will be in the content area of the page and not in a navigational menu. Let's create a new view. We're going to create a node view named subs, as shown in the following screenshot: Click Next and the Views panel is presented. The panel will allow us to customize the view settings. We'll start by creating a Page display for the view. The Views page will always attempt to provide you with a real-time preview based on your settings. Often, the settings are being established in an order that is not conducive to creating the preview, because some information is missing. In that event, you will see a pink warning about this, for example, Fields is the display type but no fields have been chosen. Use the warnings as a way to tweak your memory about what you have left to do, but don't worry about them, as long as there are none remaining when you think you're done. We'll click on Title and change the view title, as shown in the following screenshot. Click Update default display when you are finished. Let's look at some of the other configuration options in Basic Settings. Leave the style settings as it is. A style plugin isn't needed, because the view will eventually be themed, and since it will only be showing one record it doesn't require a table or grid. We'll also leave the Row style set as Fields, as we want the profile data to be displayed as a vertical list of fields. Again, changes can be made when the view is themed. We won't use AJAX at this time. We do want to use paging with this display. It's likely that the subcontractor list will be large, and so we'll only want a small amount being shown at one time. We'll change the Use pager setting to "yes", and from the config options choose Mini pager. Leave the More link setting at no, we don't need a More link, and likewise, since each record is a separate subcontractor node, we're not concerned about unique records. As this view is meant only for use by the management of Guild Builders, we'll want to restrict access to it. Change the Access setting to restrict access to a specific role. A role called management has already been created for use by the management staff of Guild Builders. There will probably be more roles added later, such as one for staff and another for the subcontractors themselves. We'll assign access to the management role. We won't be caching the view, nor exposing the form in a block, so we'll leave the settings caching at one and expose form in block at no. There will be a page header and footer, but they can be added later. Empty text won't be an issue, because the node selection will come from a list based on existing nodes. That takes us to the end of the Basic Settings pane. Let's move on to Sort criteria.

We're going to look at our new homepage and from there move on to look at some of the main concepts of PHP-Nuke: blocks, modules, themes, and site security. Along the way, we're going to create the super user, a user with absolute power over our site; we will edit our first piece of content in PHP-Nuke, and begin the construction of the Dinosaur Portal. Your New Homepage Navigate to your site's homepage in your browser. For our newly installed PHP-Nuke site, this will be http://localhost/nuke/. You should be presented with the following screen, which we saw at the end of the last article: Considering that we've not really done anything, this is impressive. I'm sure you won't be able to resist clicking on some of these links and seeing what PHP-Nuke has in store for us. Currently, the system is 'empty', so it has a rather cold and eerie feeling about it. Rest assured that it will start to warm up over the next few articles as we add content to the site. By the way, if you are impressed with the features you're seeing right now, let me tell you that there are others that haven't yet been activated. Also, there are many other add-ons that we can find from various PHP-Nuke resource sites across the Internet. Let's now talk about some of the PHP-Nuke bits that we see on the front page. First of all, there's the look of the page. There is the banner at the top, a site logo, and a horizontal navigation bar: The page 'body' begins below the navigation bar. You can see a three-column layout with a big chunk of information in the middle column. The page layout of a PHP-Nuke site need not always look this; the arrangement of the elements, the choice of color, text styles, and images is controlled by the theme. A different theme can be selected for the site, and immediately, the look and feel of your site is changed. Blocks The elements that you see in the left- and right-hand columns are known as blocks: Blocks in PHP-Nuke are little nuggets of information positioned at the sides or sometimes at the bottom of a page. They often provide 'navigation', linking to other parts of the site, and provide a report or summary of the content that is available either on your site or, possibly, on another site. Typically, many blocks are displayed on a single page. An important block is the Modules block in the left-hand column: This block shows a list of the active modules on your site, and is the standard navigational element of a typical PHP-Nuke site. Each entry in the above list is a link to a module on your site, and by clicking on the links the visitor is able to move between the modules. Modules PHP-Nuke is a modular system. Each module is like a mini website in itself, performing different tasks and working with different types of content. The PHP-Nuke 'core' provides a central mechanism for handling these modules, so that they work together sharing data and user information, and ensuring a consistent look and operation throughout your site. In short, the modules define your site. The good thing with PHP-Nuke is that you can add and remove modules as needed, selecting the best range of features to suit your site and its visitors. We will discuss the standard PHP-Nuke modules over the next few articles. When viewing a page on a PHP-Nuke site, the module currently in play can be known by looking at the URL of that page. For example, if you are looking at the Downloads module, the URL will be something like this: http://localhost/nuke/modules.php?name=Downloads The part of the URL after the ? character is the query string. The query string contains variables that are separated by the & character. In the above URL, the query string contains a single variable, name, which has the value Downloads. PHP-Nuke switches between modules according to the value specified in the name variable. The other query string variables determine what else is to be displayed on that page, such as the required news story for example. (Handling these query string variables appropriately has traditionally been a security weakness in PHP-Nuke, but that is true for many other web applications). The output of the module being currently viewed is displayed in the middle column of the web page. A Fistful of Default Modules Let's have a quick overview of what some of the standard modules offer: Home: Shows the homepage of the site. There isn't actually a Home module but some particular module is associated with the homepage. The homepage actually has the URL index.php, rather than modules.php?name=XXXX. Downloads and Web Links: Allow you to create and maintain categorized lists of downloadable resources or links to other sites. Possibly you have already seen the Downloads module in action when you downloaded PHP-Nuke itself from a PHP-Nuke powered site. This is another 'interactive' module—visitors can submit their own downloadable resources or links here. Recommend Us: Allows the visitor on your site to send a message to their friends suggesting that they come and visit your site. Search: Allows the visitor to search the contents of your site. Statistics: Provides site statistics like the number of visits to your site, the different browsers used by visitors, and the most-viewed stories on your site. Stories Archive: Contains an archive of past stories that have appeared on the site, arranged by month of publication. Submit News: Allows visitors to submit a news story to the site through a form, after which the story goes straight onto the site provided it is acceptable. The story is then said to be published. Surveys: Displays the results of polls that have appeared on the site. Polls can be attached to stories and other pieces of content. Topics: Provides a different view of the stories, this time arranged by their topic. Your Account: Allows visitors to your site to register and create their own accounts. All visitors that register at your site can have their own area, which is accessed through this module. They can customize their own area, including their own Journal. That's not even all of the modules, but it's enough to give you an idea of the breadth of the functionality that PHP-Nuke offers and the kind of experience that your visitors can look forward to. Coming back to the homepage, have a look at the message in the middle that says: For security reasons the best idea is to create the Super User right NOW by clicking HERE It's not everyday that we're invited to create a super user, so I think we should get on with that, especially as the word NOW is in upper case; that always suggests a sense of urgency. Clicking on the word HERE in that message will take you to the page http://localhost/nuke/admin.php; and we can begin creating our super user. Creating the Super User PHP-Nuke enables visitors to your site to create their own user account, and add and maintain their own personal details. The user account is required to identify them for posting news stories, making comments, or contributing to discussions in the forums, among other activities. By registering on the site and creating a user account, the visitors are given greater freedom on the site. However, their freedom has limits. We are about to create a special type of user, the super user. This is a registered user of the site who has almost total freedom on the site and absolute power over it. The super user can access, add, remove, and modify any part of the site, and can configure and control anything on the site. Given the nature of this power, there comes the obvious responsibility of ensuring that the identity of this user is kept a secret. Anyone obtaining these account details will be able to do almost anything to your site, and that could be worse than it sounds, so you must ensure that these details do not fall into the wrong hands. The super user is a site administrator, in fact, the site administrator. We will use the term administrator and super user interchangeably. It is also possible to create other, less powerful, site administrators who can manage various parts of the site, such as approving bits of content submitted by visitors. We shall now create the super user account. As with any user account on PHP-Nuke, it will consist of a username ('nickname', as it is also known in PHP-Nuke) and a password. On the page http://localhost/nuke/admin.php, you will be presented with a form asking you to choose a super user Nickname, the HomePage of that user, a contact Email address and a Password. The password should only contain alphanumeric characters (letters and numbers). This is how the form looks: The super user account is not the only type of user account that can be created with PHP-Nuke. Visitors to your site can register and create their own user accounts, which make them Registered Users of your site. When creating the super user there is an option to create a registered user with the same details, although obviously that user doesn't have the extended power of the super user. This does mean that when you log in with this administrator account, you will enjoy all the personalization benefits of the standard user account. We will create the nickname and password for the super user account now. Do not use nicknames like admin, super user, or root for the super user; these would be the first guess of any miscreant attempting to break into your system. Also, make your password difficult to guess; make it long with a mixture of digits and letters, both upper and lowercase (definitely do not use the word password as your password!). Making the password secure is another vital step toward the overall security of your site. In the page, we will enter dinoportmeister for the nickname, and use the password Pa2112cktXog. You can enter your own nickname and password here if you like, but make sure you remember them! Your email address needs to go into the Email field, this is another required field. The HomePage field does not have to correspond to the address of this site; this is for informational purposes only. The option to create a normal user with the same data will do just that, it will create a user with the same username and password as the administrator account. However, the two accounts are distinct, and changing the password for either account will not affect the other. Click Submit and the super user is created. Becoming the Administrator After you have created the details for the super user, you still have to log yourself in with these details. On the admin.php page, you will find a form for entering the administrator username and password. Hopefully you haven't forgotten them already! After entering the details here, click the Login button and you will pass over to the other side: the administration area of the site. The admin.php page is where you need to log in to access the administration area. Whenever you want to log in as an administrator to perform some site maintenance, you do so from this page. Logging in from any other place on the site will log you 'normally' into the site, as if you were a standard visitor to the site, even if the administrator username and password is accepted. If you think about it, this suggests that unless it has been specially customized, any PHP-Nuke site has an administrator login page at admin.php. This means that anyone intent on accessing the administrator area of that site does not have to look far to find the administrator login (of course, getting the right username and password combination is another matter). To counter this, from PHP-Nuke 7.6 onwards, if you want to rename the admin.php file, you can do so by storing the new name of the file in the $admin_file variable in the config.php file. This relocates your administrator login page. Once you have entered the administration username and password, you will get your first taste of the administration area: That might be more than you were expecting. We are presented with two towering graphical menus; the Administration Menu and the Modules Administration menu, the main navigation tools for the site administrator. (In versions of PHP-Nuke earlier than 7.5, these menus were one—the Administration Menu). We'll dig into more detail about these menus in the next few articles. This is the place where you will spend most of your PHP-Nuke life, so you will need to get comfortable with it. Before we go any further, click the Home link in the Modules block to return to the homepage of your site. A New Welcome When you return to the homepage, you will notice that some extra text has appeared at the bottom of the welcome message: [ View: All Visitors - Unlimited - Edit ] This text is evidence of the super user's extra powers. If you click on the Edit link, you can begin changing the site. The presence of the Edit link is an example of 'in-position' editing, whereby as you browse the site you can quickly edit or delete the content you see. This link is not available to normal users of the site and is a pretty neat feature of PHP-Nuke. When you click the Edit link, you will be taken back to the administration area.