How-To Tutorials

article-image-cms-made-simple-16-learning-smarty-basics

04 Mar 2010

8 min read

CMS Made Simple 1.6: Learning Smarty Basics

04 Mar 2010

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

0
0
2561

article-image-import-add-background-music-audacity

Packt

03 Mar 2010

2 min read

Importing and Adding Background Music with Audacity 1.3

Packt

03 Mar 2010

2 min read

Audacity is commonly used to import music into your project, convert different audio files from one format to another, bring in multiple files and convert them, and more. In this article, we will learn how to add background music into your podcast, overdub and fade in and out. We will also discuss some additional information about importing music from CDs, cassette tapes, and vinyl records. This Audacity tutorial has been taken from Getting Started with Audacity 1.3. Read more here. Importing digital music into Audacity Before you can add background music to any Audacity project, you'll first have to import a digital music file into to the project itself. Importing WAV, AIFF, MP3, and MP4/M4A files Audacity can import a number of music file formats. WAV, AIFF, MP3 are most common, but it can also import MP4/M4A files, as long as they are not rights-managed or copy-protected (like some songs purchased through stores such as iTunes). To import a song into Audacity: Open your sample project. From the main menu, select File, Import, and then Audio. The audio selection window is displayed. Choose the music file from your computer, and then click on Open. A new track is added to your project at the very bottom of the project window. Importing music from iTunes Your iTunes library can contain protected and unprotected music files. The main difference is that the protected files were typically purchased from the iTunes store and can't be played outside of that software. There is no easy way to determine visually which music tracks are protected or unprotected, so you can try both methods outlined next to import into Audacity. However, remember there are copyright laws for songs written and recorded by popular artists, so you need to investigate how to use music legally for your own use or for distribution through a podcast. Unprotected files from iTunes If the songs that you want to import from iTunes aren't copy-protected, importing them is easy. Click-and-drag the song from the iTunes window and drop it into your Audacity project window (with your project open, of course). Within a few moments, the music track is shown at the bottom of your project window. The music track is now ready to be edited in, as an introduction or however you desire, in the main podcast file.

0
2
49470

How-To Tutorials

article-image-flex-multi-list-selector-using-list-control-datagrid-and-accordion

Packt

02 Mar 2010

3 min read

Flex Multi-List Selector using List Control, DataGrid, and the Accordion

Packt

02 Mar 2010

3 min read

0
0
2201

article-image-building-your-first-ireport

Packt

02 Mar 2010

4 min read

Building Your First iReport

Packt

02 Mar 2010

4 min read

So let's get on with it! Creating a connection/data source Before going to create the connection, a database should be set up. The SQL query for the database used for creating reports can be downloaded from the Packt website. Now, we are going to create a connection/data source in iReport and build our first report in some easy to follow steps: You need to create the connection/data source just once before developing the first report. This connection will be reused for the following reports. Start iReport. Press the Report Datasources button in the toolbar. You will see a dialog box similar to the following screenshot: Press the New button. Another dialog box will appear for selecting the data source type. There are several types to choose from, according to your requirement. For now, choose Database JDBC connection, and press Next >. Another dialog box will appear to set up the Database JDBC connection properties. Give a sensible name to the connection. In this case, it is inventory. Choose the JDBC Driver from the list, according to your connection type and/or your database. In this case, it is MySQL (com.mysql.jdbc.Driver). Write the JDBC URL, according to the driver you have chosen. For this tutorial, it is jdbc:mysql://localhost/inventory. In the previous code for connecting to a database from a Java program using JDBC—jdbc is the connection protocol, mysql is the subprotocol, localhost is the MySQL server if it runs on the same computer, and inventory is the database name. Enter the Username and Password. Generally, for a MySQL server, the username is root and you have set a customized password during the installation of the MySQL server. The screenshot is as follows: Press Test to confirm that you have set all the properties correctly. If all the settings are correct, then you will see a message that says Connection test successful!. You can save the password by checking the Save Password checkbox, but be warned that iReport stores passwords in clear text. Storing passwords in clear text is a bad thing for us, isn't it? If you do not specify a password now, iReport will ask you for one only when required and will not save it. Now save the connection. You will see that the newly created connection is listed in the Connections/Datasources window. If you have more than one connections, then you can set one as the default connection. In order to do this, select the connection and press Set as Default. Enter the Username and Password. Generally, for a MySQL server, the username is root and you have set a customized password during the installation of the MySQL server. The screenshot is as follows: When we execute the report with an active connection, the reports are filled with data from the database or other data sources. We can also see the report output with empty data sources, which has, by default, a single record with all fields set to null. An empty data source is used to print a static report. However, in order to choose the tables and columns from a database automatically using the Report Wizard, we need to connect to a database/data source first. To do this, we must create a connection/data source. Building your first report Having set up a connection, we are ready to build our first report. We will keep it very simple, just to be familiar with the steps required for building a report. We will create a report that lists out all the products; that is, we will show all the rows of the product table of our database. Follow the steps listed and build your first report: Go to the File menu and click New…. You will see a dialog box like the following screenshot: From the list of Report templates, select Simple Blue and press Launch Report Wizard. Enter Report name as List of Products and press Next >. Now you will specify the query to retrieve the report fields. Select your connection from the Connections / Data Sources drop-down list. Write the SQL query for the report you want to develop. In our case, it is SELECT ProductCode, Name, Description FROM Product.

0
0
2194

article-image-installing-wordpress-e-commerce-plugin-and-activating-third-party-themes

Packt

02 Mar 2010

4 min read

Installing WordPress e-Commerce Plugin and Activating Third-party Themes

Packt

02 Mar 2010

4 min read

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

0
0
3872

article-image-setting-wordpress-site-e-commerce-platform

Packt

02 Mar 2010

4 min read

Setting Up WordPress Site as an e-Commerce Platform

Packt

02 Mar 2010

4 min read

0
0
1484

article-image-authorization-zendacl-zend-framework-18

Packt

02 Mar 2010

7 min read

Authorization with Zend_Acl in Zend Framework 1.8

Packt

02 Mar 2010

7 min read

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.

0
0
1971

article-image-managing-site-using-php-nuke

Packt

25 Feb 2010

13 min read

Managing the Site using PHP-Nuke

Packt

25 Feb 2010

13 min read

0
0
3839

Packt

24 Feb 2010

12 min read

Your First Page with PHP-Nuke

Packt

24 Feb 2010

12 min read

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.

0
1
13355

article-image-mediawiki-content-organizing-features-templates-sections-redirection

Packt

24 Feb 2010

8 min read

MediaWiki Content Organizing Features: Templates, Sections, Redirection

Packt

24 Feb 2010

8 min read

Template Consider a case where a Haunted site's users felt that they should make a repository of all haunted movies and share it with others. A movie, however, will have a lot of information to go with it—producers, director, actors, release date, distributors, storyline, etc. It will be very easy to create a page with all the information, but it won't be possible to summarize the movie in a way that anybody can have summary information when they visit any movie's page. There needs to be a common format that will be used by all the movie pages. That is how Wikipedia shows a summary of every James Bond movie at the right side of the page. Since all movies have some common attributes but different values, they use the same format for all the James Bond movie summaries—it's only the attributes' values that change, and not the attributes themselves. Can we use the same thing in our Haunted site? MediaWiki has the solution, and it is known as a template. A template is a page that can be inserted into another page via a process called transclusion. Templates usually reside in the Template namespace in MediaWiki. Templates are useful for any text for which one wants a copy in two or more pages, and there is no need for each copy to be edited independently, to adapt it to the page it is in. Templates can also be parameterized—we can add parameters to a template in order to show different content based on the parameter. This lets a template act like a subroutine. Looking at it from other angle, a template can be thought of as being like the include file that we use in programming. Creating our First Template The syntax for insertion of the page Template:templatename is {{ templatename }}. This is called a template tag. If the page Template:templatename does not exist, then {{ templatename }} works as [[Template:templatename]], a link to a non-existing page, leading to the edit page for the template. Thus, one way of creating a template is putting in the tag first, and then following the link. Let's create our first template using this technique. Write down the following text in the URL section of the browser: http://haunted.com/index.php?title=Template:Movie_Summary This will take us to an empty non-existent template page. We can edit the template and save it as our template. Let's make the movie summary information template for our movie section. It will contain the movie name, a poster, screenwriter, cast details, etc. Editing a template page is similar to editing a normal page. There is no difference at all, and so we can use wiki syntax in our template page. Let us add the following content in our template page for a movie named "The Haunting" and save it: '''The Haunting''' <br>[[Image:200px-The_Haunting_film.jpg]] <br>'''The Haunting''' film poster <br>'''Directed by''' Jan de Bont<br>'''Produced by''' Donna Roth,<br>Colin Wilson<br>'''Written by''' Novel:<br>Shirley Jackson <br>'''Screenplay:'''<br>David Self<br>'''Starring''' Lili Taylor,<br>Catherine Zeta-Jones,<br>Owen Wilson,<br>Liam Neeson<br>'''Distributed by''' DreamWorks<br>'''Release date(s)''' July 20, 1999<br>'''Running time''' 113 minutes<br>'''Language''' English<br>'''Budget''' ~ US$80,000,000<br> We can now call this template from any of our pages using a pair of double curly braces {{ }} with the name of the template between the braces. Assuming that we are creating a new page where we will show all stories, let's add the template to a story page. Open any of the story pages that we have created so far, and add the following line at the beginning of the edit page: {{Movie_Summary}} Now save the page and preview it in the browser. You will see true magic now; the content of the template is shown in the story page as follows: We put the template tag at the start of the page, but you can always put it anywhere you want in the content page. We can use templates to create a header, a footer, the copyright information, special messages, etc., for our site. This is a very simple but powerful use of templates. Think about a situation where we have a lot of movie information available. What we did is just for a single movie, but we can use the same template for other movies with the same type of attributes. When we use templates, we don't have to worry about changing the summary attributes in each and every page. We will just change the template and all the pages will be updated, since pages include that template. We can do amazing things using templates. Also, since they are similar to normal pages, we can always create nice-looking templates using tables, images, links, etc. Templates work on a project basis. So a template in one wiki will not work in another wiki site. In order to use the same template on another wiki site, we have to build the same template in that site. Also when we change a template, we must be careful about the impact of the changes in the pages where the template is actually used. Parameterizing Templates We already know that we can add parameters in our template to make it work like a subroutine. I hope all of you know what a subroutine means; if not you could visit the following URL: http://en.wikipedia.org/wiki/Subroutine. Based on its parameters, a subroutine performs some task and shows results. We know templates are not subroutines, but they can be used as subroutines for performing different tasks. Take the example of our movie summary template. We have hardcoded the name of the movie and other attributes, but we can use the same template for another movie by changing the attributes' values. So it is almost same as adding the content in each page. However, if we can parameterize the template, it will definitely make our task easy. What we can do is make the movie name, movie poster, writer, actors' names etc., into variables that will be set by parameters and passed from the calling page. All the template parameters are divided into two categories: named parameters and numbered parameters. In order to create a parameterized template, we need to perform the following two tasks every time: In the template page, declare parameters that will be changed based on the passed values. Call the template with proper values from the calling page. Parameters are declared with three pairs of braces with the parameter name inside. {{{myVar}}} declares a parameter name myVar. So in the template, the parameter declaration will done as follows: {{{parname1|default}}}, {{{parname2|default}}} and in the tag or calling page, we have to write it as follows: {{templatename|parname1=parvalue1|parname2=parvalue2}} The default option in the parameter declaration is totally optional. It can be different for each and every parameter, and applies when no value has been provided for the parameter. Here default stands for the default value of the parameter. This default value will be used if a parameter is not set to any value from the calling pages. You will see that we are using the parameter name in both template definition and declaration page. This is known as a named parameter. There is another type of parameter as well, called a numbered parameter, which is indicated by the use of ?a number instead of a name. In a numbered parameter option, the declaration looks like this: {{{1|default}}}, {{{2|default}}} and in the calling page, we have to write down the tag as follows: {{templatename|parvalue1|parvalue2}} Now back to our movie summary example. We want to convert our movie summary template to a named parameterized template. We will use different parameters for different attributes of the template. We will also use a table to make the template look better. Here is the code for the template: {|style="width:250px; " border="0"|-|width=100px||width=100px||-| colspan="2" align="center" |'''{{{name}}}'''|-| colspan="2" align="center" |[[Image:{{{image}}}|{{{image_size|200px}}}]]|-| colspan="2" align="center" |''{{{caption}}}''|-|'''Directed by'''||{{{director}}}|-|'''Produced by'''||{{{producer}}}|-|'''Written by'''||{{{writer}}}|-|'''Screenplay:'''||{{{screenplay}}}|-|'''Starring'''||{{{starring}}}|-|'''Distributed by''' ||{{{distributor}}}|-|'''Release date(s)'''||{{{released}}}|-|'''Running time'''|| {{{runtime}}}|-|'''Language'''|| {{{language}}}|-|'''Budget'''|| {{{budget}}}|}

0
0
2340

article-image-drupal-6-attachment-views-page-views-and-theming

Packt

24 Feb 2010

9 min read

Drupal 6: Attachment Views, Page Views, and Theming

Packt

24 Feb 2010

9 min read

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.

0
0
2513

article-image-mediawiki-content-organizing-features-namespaces-categories

Packt

24 Feb 2010

7 min read

MediaWiki Content Organizing Features: Namespaces, Categories

Packt

24 Feb 2010

7 min read

Necessity of Organizing Content As the site grows, the numbers of users and articles also grow. The necessity of organized content arises because: As the number of users keeps growing, the articles and other contents such as images, media files, etc., will keep growing. In order to maintain the large number of articles and content, we need a proper structured system to organize all the content. Think of a library where hundreds and thousands of books are kept. If those books are not kept in order, then where should a person look for a particular book? For users, it will be really nice to have proper organized content rather than disjoint and unorganized content. As the number of articles keeps growing, it is also necessary to categorize them. It is very easy to find a particular article and maintain it based on the category. Carrying on our library example, if we keep a section for horror books, and under this section we keep relevant comics, stories, novels, and movies, then it will be much easier for someone to point to the horror section and find the right movie there. One thing we have to remember: the more organized a site is, the more user friendly it is. Users love sites that are friendly to use and adopt. Sometimes it is required to break an article in several pages as the article is very big and difficult to maintain on a single page. Users usually have to scroll through the huge amount of text, and this can be problematic. Also, editing a huge amount of content at once can be difficult. So we need to know how we can manage such big articles by breaking them into sub-pages and also keeping them together so that user can find them easily. MediaWiki can help us in this regard. MediaWiki has some built-in features that can make our task very easy and simple. These software features are very important components of MediaWiki since organizing in a collaborative community is not that easy. We will now focus on a few MediaWiki features that can be used for better content organization. MediaWiki Content Organizing Features MediaWiki handles these major issues without any problem or complexity whatsoever. The concept and the application of organizing content in MediaWiki are easy to grasp and apply. MediaWiki has the following software features to strengthen its organizing ability. Namespaces Categories Templates Sections Redirection We will now explore some of the features in detail with examples. Namespaces Namespaces are used to group together similar type of contents. Namespaces divide a wiki into different areas so that each functional area is clearly defined. Namespaces can segregate different types of content that may exist under the same title. Generally, namespaces should not be used to categorize content of the same type as we can use categories for that. The namespaces that come with MediaWiki illustrate this "content type" distinction: The Main, un-prefixed, namespace is for the primary content to be maintained in the wiki. The Talk namespaces are for discussion. The Project namespace is for policies, votes, and meta-information. The Image namespace is for images. Namespaces allow separation of content for better management. One thing about a namespace is that it is not created by the users themselves. MediaWiki has some pre-defined namespaces and administration can add new namespaces if required. The namespaces that are added by the administrator are known as custom namespaces. It is always important to let users know about the custom namespaces available in the site. Like the Image namespace, there are 17 other namespaces available in MediaWiki for special purposes. So when should one create a custom namespace? Essentially, if you have some type of content that you feel is substantially different from the content in the existing namespaces, you may want to consider creating a new namespace. For our Haunted site, we can have a movie namespace, so as to accommodate movie descriptions and trailers. Now let us focus on how we can use namespaces. A page title in MediaWiki consists of two parts separated by a colon (:). The part before the colon is the (optional) namespace, and the part after the colon is the required page title. An example page title with a namespace is Help:Namespace, which will take us to the Namespace page under the Help namespace. A page title without a colon belongs to the Main namespace. There are as many as 18 namespaces in MediaWiki, among which two are used as pseudo namespace, and 16 separate namespaces are defined by MediaWiki. Although there are 16 defined namespaces in MediaWiki, eight of them are talk pages of remaining eight namespaces. A talk page is a special type of page used for discussions. On a talk page, users can communicate as in a forum. They can write their views or share their ideas on certain topics. Every page and namespace has an associated talk page (except for the Special namespace). Here is a list of 18 namespaces in MediaWiki and a summary of their functionalities: Namespace Functionality Media This is the first pseudo namespace in MediaWiki. It is used for uploaded files. Special This is the second and last pseudo namespace in MediaWiki. It is used for listing all special pages. Main This is the core namespace that holds all the pages without specifying any namespace in front of the title. Pages under this namespace are also known as normal pages. The content we have added so far to our Haunted site is inside the Main namespace. Talk The Talk namespace holds talk pages for the Main namespace. Talk pages are used for discussion. The Talk namespace is used for all the discussion pages under the Main namespace. User This namespace is used for every registered user in MediaWiki. Every registered user has a homepage, and all homepages are stored under the User namespace and can be accessed by a User:username link. Users can use this page as their profile page. User_talk User talk pages are used for discussions on user pages. Project This namespace provides information about the current project or wiki, such as guidelines, ideas, future plans, etc. Project_talk This talk page is used for the Project namespace. Image Used for images and other uploaded file information. Description of the file such as file size, version, etc., can be found here. Image_talk This is the talk page for the Image namespace. MediaWiki This namespace is used for system messages defined for the current wiki or project. These messages are either editable by a registered user, or sysops can turn off editing for security reasons. MediaWiki_talk This is the talk page for the MediaWiki namespace. Template This is used as the default namespace for templates, another feature that is used for integrating a page into another page. We will learn about templates later in this chapter. Template_talk This is the talk page for the Template namespace. Help This is typically used for building help content for wiki users. All the help-related information is stored here. Help_talk This is the talk page for the Help namespace. Category Pages can be put into categories. The Category namespace shows a list of categories inside the wiki, and upon clicking a category, a list of pages under the category along with additional text is also shown. Category_talk This is the talk page for the Category namespace.

0
0
5552

article-image-managing-menus-joomla-15-part-1

Packt

24 Feb 2010

7 min read

Managing Menus in Joomla! 1.5: Part 1

Packt

24 Feb 2010

7 min read

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.

0
0
2090

article-image-adding-image-content-joomla

Packt

23 Feb 2010

6 min read

Adding Image Content in Joomla!

Packt

23 Feb 2010

6 min read

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.

0
0
3389

article-image-managing-image-content-joomla

Packt

23 Feb 2010

3 min read

Managing Image Content in Joomla!

Packt

23 Feb 2010

3 min read

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.

0
0
6073

CMS Made Simple 1.6: Learning Smarty Basics

Importing and Adding Background Music with Audacity 1.3

Flex Multi-List Selector using List Control, DataGrid, and the Accordion

Building Your First iReport

Installing WordPress e-Commerce Plugin and Activating Third-party Themes

Setting Up WordPress Site as an e-Commerce Platform

Authorization with Zend_Acl in Zend Framework 1.8

Managing the Site using PHP-Nuke

Your First Page with PHP-Nuke

MediaWiki Content Organizing Features: Templates, Sections, Redirection

Trending Topics

Drupal 6: Attachment Views, Page Views, and Theming

MediaWiki Content Organizing Features: Namespaces, Categories

Managing Menus in Joomla! 1.5: Part 1

Adding Image Content in Joomla!

Managing Image Content in Joomla!

Create a Free Account To Continue Reading

Sign in to activate your 7-day free access