How-To Tutorials - CMS & E-Commerce

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

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.

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.

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.

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.

Images and why we use them in websites Research suggests that images enhance learning by illustrating the concepts visually and by providing visual memory cues to the viewer. We have been using images to describe, tell stories, and record history since our human evolution. I have been in a few situations where, if a language barrier between me and the other party exists, we have resorted to a pencil and napkin in order to communicate effectively. Pictures can convey a message, which might take many thousands of words to describe. This non-textual communication and the visual emotions that the use of images can generate mean they are the perfect medium to complement or replace the text in our web pages: The previous image could easily take a thousand words to describe, which would look uninteresting to the reader and take up valuable space on our web pages. Instead the picture only utilizes a fraction of the space that our description would use and tells a story in itself. Not only do images describe a story, a moment in time, or a fantasy situation; they can provide a visual stimulus, which portrays a style or theme and sets a mood for the viewer. Many Joomla! Templates now contain a high percentage of graphical images in order to produce interesting designs and effects, such as this commercial example from http://www.yootheme.com: Many templates now utilize rounded edges for the graphics, or faded effects, and some create a 3D type effect on our two-dimensional computer screens. This is achieved by using shading and image layering effects. Others use images to create interesting navigation effects which could not be achieved without using these. Besides the design, navigation, and branding effects that images help provide, inside our content and modules, we use images to advertise and communicate to our site visitors. One important trick as web developers is to make sure our images are as optimized as they can be before asking our viewers to load them into their web browsers. This ensures a pleasant user experience because if a site is slow to load, or images are missing, these can be a big turn-off to your site visitors. Image formats and which ones to use Images can often make up 50 percent of a Joomla! website; sometimes even more. These images that get loaded into the browser can be part of your template design, or site images we have loaded into our modules and articles. Choosing an appropriate format for this image content will help optimize the loading times of your web pages, which is one of the most important considerations when building a multimedia rich website: There are a few simple rules we can use in order to choose an appropriate image format. The most important criterion for the final file is the size. The previous image is exported using Adobe Fireworks on a Mac computer. External image editors such as the GNU Image Manipulation Program (GIMP) are good open source solutions for manipulating and optimizing images for the web. GIMP can be downloaded by visiting http://www.gimp.org. With each image requiring loading by the user's browser, page-loading times can be easily affected with the quality and quantity of images you use in your web pages. This in turn results in end user frustration (especially on dial-up Internet connections) and loss of site traffic. Digital images Before we proceed further into file sizes and file types, it is important to mention a note about digital images. Because all of our web page images are stored or viewed on a computer device, they are in a digital format (an electronic file stored using zeros and ones). A digital image is built up of tiny elements called pixels. Pixels are the building blocks of all digital images and are small adjoining squares in a matrix across the length and width of your image. Pixels are so small that you cannot easily see them when the image is viewed on your computer screen: Each pixel is an element containing a single solid color, and when put together all of these tiny dots make up your final image. Usually, more pixels per area make up a higher quality image, but there is a poin t when viewed with the human eye on electronic devices that you cannot actually see the extra detail that the additional pixel's bring to the image: The physical dimensions of a digital image are measured in pixels and all digital images have what is called an image resolution (the image height and width dimensions in pixels). It is possible to save your digital images in numerous formats and compressions in order to optimize the file quality and size. Image editing programs, such as Adobe Fireworks, are specifically designed with web optimization and export options: Lossy and lossless data compression Data compression is an important part of our digital world. File compression is useful because it helps in reducing the consumption of expensive resources such as transmission bandwidth and computer hard disk space. Almost all digital images that we use on the web have been resized or compressed to some degree. When editing or saving files in popular software editing programs, many options are provided to help optimize digital images. Lossy and lossless compression are two terms that describe the compression type of a file, and whether or not the file retains all of the original data once compression and then decompression of that file has taken place. The preferred formats for digital web images (such as JPEG and GIF) all fall into one of the following compression types: LossyA lossy data compression is one where the compression attempts to eliminate redundant or unnecessary file information. Generally, once a file has been compressed, the information that was lost during compression cannot be recovered again. Hence, it is a degradable compression type, and as the file is compressed and decompressed each time, the quality of the file will suffer from generation loss.JPEG and MP3 files are good examples of formats that use lossy compression. LosslessLossless file compression makes use of data compression that retains every single bit of data that was in the original file before compression.Lossless compression is often used when an identical representation of the original data is required once a file has been compressed and then decompressed again. As an example, it is used for the popular ZIP file format. Image formats such as PNG and GIF fall into the lossless compression type. For now, it is not so important to go into any more detail on these compression types, but the following image formats fall into both of these compression categories. It is possible to optimize your website images by choosing the correct format to save and present them to your site users.

Creating image galleries and slideshows Joomla! is a Content Management System designed primarily for organizing and managing website content. It contains numerous multimedia features built into it, but its main focus is providing two roles: Powerful CMS features, and a well-designed framework which allows additional features to be added to the system, thus creating powerful functionality. These additional features are called Extensions and are designed to plug in to the core Joomla! Framework and extend the functionality of it. With regards to the core Joomla! CMS, we have already looked at how images can be included into content items and modules. However, image galleries and slideshows are asking a bit more than just simple image management, and so require the power of extensions to provide these features: The number of multimedia extensions now available for Joomla! is staggering. We have extensions which can create complex galleries, stream in videos, and compile jukebox type audio features. Having considered at great length the best approach has resulted in one option. That is to highlight some of the most popular and useful image gallery and slideshow extensions, and hope that these will provide understanding as to the complex image management capability that can be achieved by using Joomla! Extensions. Image management extensions, and how to install them Before proceeding with covering third-party extension functionality, let's quickly cover how image extensions are added to your Joomla! site. As with most things in Joomla!, the process of installing extensions has had careful consideration from the development team, and is a very easy to perform. Most Joomla! Extensions come with their own installation instructions, and these general guidelines will help you get them installed on your site. Before installing anything, make sure you copy your file set and backup your site database. For the purpose of this example, I am going to install one of my favorite Joomla! Multimedia Extensions—the RokBox extension by RocketTheme. RokBox is a MooTools powered slideshow plugin that enables you to display numerous media formats with a professional pop-up screen lightbox effect: The installation steps are as follows: Download the required extension and save this download on your computer. The file will be in a .zip format, or possibly a .gzip or .tgz format which may require unzipping before installation: Log into your Joomla! Administrator's Control Panel, and navigate to the Extensions menu, then to Extension Manager. The page will default to the Install screen: Browse your computer for the extension .zip file using the Choose File button on this page and once the file is located, use the Upload File & Install button. The Joomla! Installation Manager will perform all of the work and if your extension has been built correctly, the installer will place all files and documents into their correct directories: An installation success message will show to inform you that the extension has been successfully installed. Some extensions success text may contain additional links to configuration pages for the extension.

The steps to install and configure PHP-Nuke are simple: Download and extract the PHP-Nuke files. Download and apply ChatServ's patches. Create the database for PHP-Nuke. Create a database user, and fill the database with data. Make some simple changes to the PHP-Nuke configuration file. Copy the PHP-Nuke files to the document root of the web server. Test it out! Let's get started. Downloading PHP-Nuke The latest version of PHP-Nuke can be downloaded at phpnuke.org downloads page: http://www.phpnuke.org/modules.php?name=Downloads&d_op=viewdownload&cid=1 You can also obtain older versions of PHP-Nuke, including version 1.0, from SourceForge: http://sourceforge.net/project/showfiles.php?group_id=7511&package_id=7622 SourceForge is the world's largest home of open-source projects. Many projects use SourceForge's facilities to host and maintain their projects. You can find almost anything you want on SourceForge—whether it is in a usable state or has been updated recently is another matter. Extracting PHP-Nuke Once you have downloaded PHP-Nuke, you should extract the contents of the PHP-Nuke ZIP archive to the root of your c: drive. You will have to create a folder called PHP-Nuke-7.8 in the root of your c: drive. (If you extract the files elsewhere, create the folder PHP-Nuke-7.8 and copy the contents of the main unzipped folder to this new folder). If you don't have a tool for extracting the files, you can download an evaluation edition (or buy a full edition) of WinZip from www.winzip.com. There are also free, powerful, extracting tools such as ZipGenius (http://www.zipgenius.it/index_eng.htm) and 7-Zip (http://sourceforge.net/projects/sevenzip/) among others. In the PHP-Nuke-7.8 folder, you will find three subfolders called html, sql, and upgrades. The upgrades folder contains scripts that handle upgrading the database between different versions, the sql folder contains the definition of the PHP-Nuke database that we will be working with, and the html folder contains the guts of your PHP-Nuke installation. The html folder contains all the PHP scripts, HTML files, images, CSS stylesheets, and so on that drive PHP-Nuke. Within the html folder are further subfolders; some of these include: modules: Contains the modules that make up your PHP-Nuke site. Modules are the essence of PHP-Nuke's operation; we look at them from article Your First Page onwards. blocks: Contains PHP-Nuke's blocks. Blocks are 'mini-functionality' units and usually provide snippet views of modules. We will look at blocks in article Managing the Site. language: Contains PHP-Nuke language files. These allow the language of PHP-Nuke's interface to be changed. images: Contains images used in the display of the PHP-Nuke site. themes: Contains the themes for PHP-Nuke. The use of themes allows you to completely change the look of a PHP-Nuke site with a click of a button. includes, db: Contain code to support the running of PHP-Nuke. The db folder, for example, contains database access code. admin: Contains code to power the administration area of your site. Downloading the Patches No software is without its flaws, and PHP-Nuke is no exception. After a release, the large user community invariably finds problems and potential security holes. Furthermore, PHP-Nuke also contains features such as its forum, which is in fact the phpBB application specially modified to work with PHP-Nuke. phpBB itself is updated on a regular basis to correct critical security vulnerabilities or to fix other problems, and consequently the corresponding part of PHP-Nuke also needs to be updated. Rather than releasing a new version of PHP-Nuke for these situations, patches for its various parts are released. ChatServ's patches from www.nukeresources.com are mostly concerned with variable validation, in other words, making sure that the variables used in the application are of the right type for storing in the database. This has been an area of weakness with many earlier versions of PHP-Nuke. The patches are often incorporated into subsequent versions of PHP-Nuke so that each new version becomes more robust. Note that you don't have to apply the patches, and PHP-Nuke will still work without them. However, by applying them you will have taken a good step towards improving the security of your site. If you navigate to http://www.nukeresources.com, there is a handy menu on the front page to access the patches: To obtain the patch corresponding to your version, click the link and you will be taken to the relevant file (of course, www.nukeresources is a PHP-Nuke powered site!). Click on the Nuke 7.8 link to go to the Downloads page of www.nukeresources.com. On this page, clicking the Download this file Now! link will download the patches for PHP-Nuke 7.8. The name of this file will be of the form 78patched.tar.gz. This is a GZIP compressed file that contains all the patches that we are about to apply. The GZIP file can be extracted with WinZip, or any of the other utilities we discussed earlier. The patches are simply modified versions of the original PHP-Nuke files. The original files have been modified to address various security issues that may have been identified since the initial release, or maybe since the last version of the patch. Applying the Patches To apply the patches, first we need to extract the 78patched.tar.gz file. We will extract the files into a folder called patches that we will create in the PHP-Nuke-7.8 folder. After extracting the files, copy the contents of the patches folder to your html folder. Do not copy the patches folder, copy its contents. The patches folder contains files that replace the files in the default installation, and you get a Confirm File Replace window. Select Yes for all the files, and when the copying is complete, your installation is ready to go. We have performed this patching immediately after installing PHP-Nuke, but we could have done this at any time. Doing it at this point is more sensible as it means that we are working on the most secure version of PHP-Nuke. Also, the patch process we have described here overwrites existing PHP-Nuke installation files. If you have modified these files, then the changes will be lost on applying the patch. Thus applying the patches later without disturbing any of your changes becomes more demanding. There is one further thing to watch for after applying the patches. You may find that the patched files have had their permissions set to read-only, and that you are unable to modify the files. To modify the files (and we do have to modify at least the config.php file in this article) you will need to remove this setting. You can do this on Windows by right-clicking on the file, selecting Properties from the menu, unchecking the Read-only setting, and clicking the OK button: We've done almost all the work with the files that we need to; now we turn our attention to creating and populating PHP-Nuke's database. Preparing the PHP-Nuke Database We'll be using the phpMyAdmin tool to do our database work. phpMyAdmin is part of the XAMPP installation (detailed in Appendix A), or can be downloaded from www.phpmyadmin.net, if you don't already have it. phpMyAdmin provides a powerful web interface for working with your MySQL databases. First of all, open your browser and navigate to http://localhost/phpmyadmin/, or whatever the location of your phpMyAdmin installation is: Creating the Database We need to create an empty database for PHP-Nuke to hold all the data about our site. To do this, we simply enter a name for our database into the Create new database textbox: We will call our database nuke. Enter this, and click the Create button. The name you give doesn't particularly matter, as long as it is not the name of some already existing database. If you try to use the same name as an already existing database, phpMyAdmin will inform you of this, and no action will be taken. The exact name isn't particularly important at this point because there is another configuration step coming up, which requires us to tell PHP-Nuke the name of the database we've created for it. After clicking Create, the screen will reload and you will be notified of the successful creation of your database: Creating a Database User Before we start populating the database, we will create a database user that can access only the PHP-Nuke database. This user is not a human, but will be used by PHP-Nuke to connect to the database while it performs its data-handling activities. The advantage of creating a database user is that it adds an extra level of security to our installation. PHP-Nuke will be able to work with data only in this database of the MySQL server, and no other. Also, PHP-Nuke will be restricted in the operations it can perform on the tables in the database. We will need to create a username for this boxed-in user to access the nuke database. Let's call our user nuker and go with the password nukepassword. However, in order to add an extra level of security we will introduce some digits into nukepassword, and some other slight twists, to strengthen it, and so use the word No0kPassv0rd as our database user password. To create the database user, click the SQL tab, and enter the following into the Run SQL query/queries on database textbox: GRANT ALL PRIVILEGES ON nuke.* TO nuker@localhost IDENTIFIED BY 'No0kPassv0rd' WITH GRANT OPTION Your screen should look like this: Click the Go button, and the database user will be created: Populating the Database Now we are ready to fill our database with data for PHP-Nuke. This doesn't mean we start typing the data in ourselves; the data comes with the PHP-Nuke installation. This data is found in a file called nuke.sql in the sql folder of the PHP-Nuke installation. This file contains a number of SQL statements that define the tables within the database and also fill them with 'raw' data for the site. However, before we fill the database with the tables from this file, we need to make a modification to this file. By default, the name of each database table in PHP-Nuke begins with nuke_. For example, there is a table with the name nuke_stories that holds information about stories, and a table called nuke_topics that holds information about story topics. These are just two of the tables; there are more than 90 in the standard installation. The word nuke_ is a 'table prefix', and is used to ensure that there are no clashes between the names of PHP-Nuke's tables and tables from another application in the same database, since the rest of the table name is descriptive of the data stored in the table, and other applications may have similarly named tables. What this does mean is that unless this table prefix is changed, the table names in your PHP-Nuke database will be known to anyone attempting to hack your site. Many of the typical attacks used to damage PHP-Nuke are based around the fact that the names of the tables in the database powering a PHP-Nuke site are known. By changing the table prefix to something less obvious, you have taken another step to making your site more secure.

As far as web interface design techniques are concerned, AJAX is definitely the way to go. The term AJAX has been part of the mainstream development community's vocabulary since early 2005, yet AJAX reinvented existing technologies as something new and exciting, and paved the way to a better, more attractive, and interactive web (sometimes referred to loosely as web 2.0) where web applications feel much more like desktop applications. The very first JavaScript libraries sprang into existence as a means of abstracting away the differences in AJAX implementation between platforms, thereby allowing developers to focus on the important things in web design instead of worrying about compatibility issues. The result in many cases is a quick and easy way for developers to cut down on the amount of code they are required to produce, and a better more interactive experience for end users and website visitors. The Connection Manager—A Special Introduction The Connection Manager utility is by no means the smallest, most light-weight component included with the YUI, but it's certainly not the largest either, yet it packs so much functionality into just 12Kb (for the –min version). Connection Manager provides a fast and reliable means of accessing server-side resources, such as PHP or ASP scripts and handling the response. A series of supporting objects manage the different stages of any asynchronous transactions, whilst providing additional functionality where necessary. Connection is one of just a few of the utilities that are supported by a single class; this makes looking up its methods nice and straight-forward. It also doesn't have any properties at all (although the objects that it creates all have their own members which hold various pieces of information), which makes using it even easier! This utility is what is known as a singleton utility, which means that there can only be one live instance of the utility at any one time, differing from many of the other components of the library. Don't worry though, this doesn't restrict you to only making one request; Connection will manage as many separate requests as you need. Because this utility is a singleton, there are important considerations that advanced coders may want to take note of. Unlike some of the other library components, Connection cannot be subclassed—all of its class's members are static, meaning that they won't be picked up when using the YAHOO global .extend() method. It wraps up the cross-browser creation of the XMLHttpRequest (XHR) object, as well as a simple to use object-based method of accessing the server response and any associated data, into a simple package which handles the request from start to finish. This requires minimal input from you, the developer, saving time as well as effort. Another object created by Connection is the response object, which is created once the transaction has completed. The response object gives you access via its members to a rich set of data including the id of the transaction, the HTTP status code and status message, and either the responseText and responseXML members depending on the format of the data returned. Like most of the other library components, Connection Manager provides a series of global custom events that can be used to hook into key moments during any transaction. We'll look at these events in more detail later on in the article but rest assured, there are events marking the start and completion of transactions, as well as success, failure, and abort events. The Connection utility has been a part of the YUI since its second public release (the 0.9.0 release) and has seen considerable bug fixing and refinement since this time. This makes it one of the more reliable and better documented utilities available. Connection is such a useful utility that it's used by several other library components in order to obtain data from remote sources. Other components that make use of Connection Manager include the AutoComplete control, DataTable, DataSource, and Tabview. It is one of the only library components not dependant on the DOM utility. All it requires are the YAHOO global utility and the Event utility. That doesn't mean that you can't include a reference to the DOM utility, however, to make use of its excellent DOM manipulation convenience methods. The XMLHttpRequest Object Interface When working with the Connection utility you'll never be required to manually create or access an XHR object directly. Instead, you talk to the utility and this works with the object for you using whichever code is appropriate for the browser in use. This means that you don't need separate methods of creating an XHR object in order to keep each browser happy. A transaction describes the complete process of making a request to the server and receiving and processing the response. Connection Manager handles transactions from beginning to end, providing different services at different points during a request. Transactions are initiated using the .asyncRequest() method which acts as a constructor for the connection object. The method takes several arguments: the first specifies the HTTP method that the transaction should use, the second specifies the URL of your server-side script while the third allows you to add a reference to a callback object. A fourth, optional, argument can also be used to specify a POST message if the HTTP method is set to use POST giving you an easy means of sending data to the server as well as retrieving it. This is rarely required however, even when using the POST method, as we shall see later in the article. It's also very easy to build in query string parameters if these are required to obtain the data that you are making the request for. It can be hard coded into a variable and then passed in as the second argument of the Connection constructor instead of setting the second argument manually within the constructor. Connection Manager takes these arguments and uses them to set up the XHR object that will be used for the transaction on your behalf. Once this has been done, and Connection has made the request, you then need to define a new object yourself that will allow you to react to a range of responses from the server. A Closer Look at the Response Object I briefly mentioned the response object that is created by the utility automatically once a transaction has completed, let's now take a slightly more in-depth view at this object. It will be created after any transaction, whether or not it was considered a success. The callback functions you define to handle successful or failed transactions (which we'll examine in more detail very shortly) are automatically passed to the response object as an argument. Accessing it is extremely easy and requires no additional intervention from yourself. If the transaction fails, this object gives you access to the HTTP failure code and HTTP status message which are received from the server. Examining these two members of the response object can highlight what happened to make the request fail, making it integral to any Connection implementation. If the transaction was a success, these two members will still be populated but with a success code and status message, and additional members such as responseText or responseXML will also contain data for you to manipulate. If you need to obtain the HTTP response headers sent by the server as part of the response, these can be obtained using either the getResponseHeader collection, or the getAllResponseHeaders member. In the case of file uploads, some of these members will not be available via the response object. File uploads are the one type of transaction that do not make use of the XHR object at all, so the HTTP code and status message members cannot be used. Similarly, there will not be either a textual or XML-based response when uploading files. Managing the Response with a Callback Object In order to successfully negotiate the response from the server, a literal callback object should be defined which allows you to deal quickly and easily with the information returned whether it is a success, failure, or another category of response. Each member of this object invokes a callback function or performs some other action relevant to your implementation. These members can be one of several types including another object, a function call or even a string or integer depending on the requirements of your application. The most common members you would use in your callback object would usually be based upon success and failure function calls to handle these basic response types, with each member calling its associated function when a particular HTTP response code is received by the response object. It's also very easy to add an additional member to this object which allows you to include data which may be useful when processing the response form the server. In this situation, the argument object member can be used and can take a string, a number, an object, or an array. Other optional members include a customevents handler to deal with custom, per-transaction events as opposed to the global events that are available to any and all transactions, a scope object used to set the scope of your handler functions, and a timeout count used to set the wait time before Connection aborts the transaction and assumes failure. The remaining member of the callback object is the upload handler which is of course a special handler to deal specifically with file uploads. As I already mentioned, the response object will be missing success of failure details when dealing with file uploads, however, you can still define a callback function to be executed once the upload transaction has completed.

This is the first article of the series in which we will cover the introduction to PHP-Nuke. PHP-Nuke is a free tool to manage the content of dynamic websites. To be more specific, PHP-Nuke is an open-source content management system. In fact, you could say it is 'the' open-source content management system. Since it is vastly popular, a number of other similar systems have sprung from it, and even similar systems based around very different technologies that owe nothing to it in terms of code have added 'Nuke' to their name as homage. Although the first paragraph conveys something of the history and grandeur of PHP-Nuke, it doesn't answer the basic question of what it can actually do for you. PHP-Nuke allows you to create a dynamic, community-driven website with minimum effort and programming knowledge. To get the most out of PHP-Nuke, a knowledge of web development will prove to be useful, but even then, PHP-Nuke is written in the PHP scripting language (as can be deduced from the name), which is probably the most popular and straightforward language for creating websites and web applications. The first PHP-Nuke release in June 2000 was created by a developer named Francisco Burzi to power his site, Linux Preview. Since then, PHP-Nuke has evolved under his guidance to the system it is today. PHP-Nuke is truly one of the Internet's legendary applications. In this article, we will take our first look at PHP-Nuke, understand what it can do, find out where to go for further resources, and briefly discuss the site we will create in this article series. What PHP-Nuke Can Do for You PHP-Nuke is ideal for creating community-driven websites. The 'community' part of 'community-driven' means that the site is geared towards a particular group of people with similar interests. Maybe this community is concerned with wine making, flowers, programming, zombie films, or even dinosaurs. Maybe the community is actually a group of customers of a particular product. Of course, we are talking about an online community here. Whatever the community is into, the site can be structured to hold information relevant to the members; maybe it will be news stories about a forthcoming zombie film, links to other zombie sites, reviews, or synopses of other zombie films. The 'driven' part of 'community-driven' suggests that the information available on this site can be extended or enhanced by the members of the community. Members of the community may be able to shape what is on the site by posting comments, contributing or rating stories, and participating in discussions. After all, communities are made up of people, and people have views and opinions, and often like to express them! This is exactly what PHP-Nuke enables. More than being just a website, a PHP-Nuke site provides a rich and interactive environment for its visitors. The best bit is, you don't have to be an expert programmer to achieve all this. With only rudimentary knowledge of HTML, you can engineer a unique-looking PHP-Nuke website. The Visitor Experience The standard installation of PHP-Nuke provides many features for its visitors. Some of them are: Searchable news articles, organized into topics Ability of visitors to create an account on the site, and log in to their own personal area Ability of visitors to rate articles, and create discussions about them Straw polls and surveys Ability of visitors to submit their own stories to be published on the site An encyclopedia, in other words, a collection of entries organized alphabetically A catalog of web links or downloadable files Discussion forums Ability of visitors to select their own look for the site from a list of different 'themes' RSS syndication of your articles to share your content with other sites This is not a complete list either. And these are only some of the features that come with the standard installation. PHP-Nuke is a modular system; it can be customized and extended, and there is a huge range of third-party customizations and extensions to be found on the Internet. Any of these can add to the range of features your site provides. The Management Experience As a potential 'manager' of a PHP-Nuke site, as you read through the list of features above you may think they sound rather attractive, but you might also wonder how you will handle all of that. PHP-Nuke provides a web-based management interface. You, as the manager of the site, visit the site and log in with a special super user, or site administrator, account. After this, from the comfort of your web browser, you run the show: You can add new information, and edit, delete, or move existing pieces of information. You can approve articles submitted by the user to be shown on the site. You can decide the features of the site. You can control what is displayed on the pages. You can control who is able to see what. What Exactly is PHP-Nuke? PHP-Nuke is a collection of PHP scripts that run on a web server, connect to a database, and display the retrieved data in a systematic way. In other words, PHP-Nuke is a data-driven PHP web application. PHP-Nuke can be downloaded for free, and then installed to your local machine for testing and development. The files and the database can be uploaded to a web hosting service, so that your site will be available to anyone on the Internet. There are even web hosting services that offer PHP-Nuke installation at the click of a button. Modular Structure PHP-Nuke is built around a 'core' set of functions, which perform mundane tasks such as selecting what part of the application the user should be shown, checking who the user is, and what they can do on the site. The thing that makes PHP-Nuke exciting to the world is the set of modules that comes with it. These modules provide the real functionality of the site, and include ones for news and article management, downloads, and forums, among others. The modules can be switched on and off with ease, and other modules can be added to the system. There is no shortage of third-party modules on the Internet, and you can find a PHP-Nuke module for almost any imaginable purpose. Themed Interface The look of a PHP-Nuke site is controlled by a theme. This is a collection of images, colors, and other resources, and instructions that determine the layout of the page. A new theme can be selected, and your site will be transformed immediately. Visitors with a user account on the site are able to select their own personal theme. Multi-Lingual Interface PHP-Nuke comes with many language files. These contain translations of standard elements on the site interface. The availability of these translations reflects the international nature of the PHP-Nuke community. PHP-Nuke as an Open-Source Content Management System We used the expression 'open-source content management system' earlier in the article to describe PHP-Nuke. Let's take a closer a look at this term.