How-To Tutorials - CMS and E-Commerce

(For more resources related to this topic, see here.) Installing Magento locally Whether you're working on a Windows computer, Mac, or Linux machine, you will notice very soon that it comes in handy to have a local Magento test environment available. Magento is a complex system and besides doing regular tasks, such as adding products and other content, you should never apply changes to your store directly in the live environment. When you're working on your own a local test system is easy to set up and it gives you the possibility to test changes without any risk. When you're working in a team it makes sense to have a test environment running on your own server or hosting provider. In here, we'll start by explaining how to set up your local test system. Requirements Before we jump into action, it's good to have a closer look at Magento's requirements. What do you need to run it? Simply put, all up-to-date requirements for Magento can be found here: http://www.magentocommerce.com/system-requirements. But maybe that's a bit overwhelming if you are just a beginner. So let's break this up into the most essential stuff: Requirement Notes Operating system: Linux Magento runs best on Linux, as offered by most hosting companies. Don't worry about your local test environment as that will run on Windows or Mac as well. But for your live store you should go in for a Linux solution because if you decide to run it on anything else other than Linux for a live store, it will not be supported. Web server: Apache Magento runs on Versions 1.3.x, 2.0.x, and 2.2.x of this very popular web server. As of Version 1.7 of Magento community and Version 1.12 of Magento Enterprise there's a new web server called Nginx that is compatible as well. Programming language: PHP Magento has been developed using PHP, a programming language which is very popular. Many major open source solutions such as WordPress and Joomla for instance, have been built using PHP. Use Versions 5.2.13 - 5.3.15. Do not use PHP4 anymore, nor use PHP 5.4 yet! PHP extensions Magento requires a number of extensions, which should be available on top of PHP itself. You will need: PDO_MySQL, mcrypt, hash, simplexml, GD, DOM, Iconv, and Curl. Besides that you also need to have the possibility to switch off ''safe mode''. You do not have a clue about all of this? Don't worry. A host offering Magento services already takes care of this. And for your local environment there are only a few additional steps to take. We'll get there in a minute. Database: MySQL MySQL is the database, where Magento will store all data for your store. Use Version 4.1.20 or (and preferably) newer. As you can see, even in a simplified format, there are quite some things that need to be taken care of. Magento hosting is not as simple as hosting for a small WordPress or Joomla! website, currently the most popular open source solutions to create a regular site. The requirements are higher and you just cannot expect to host your store for only a couple of dollars per month. If you do, your online store may still work, but it is likely that you'll run into some performance issues. Be careful with the cheapest hosting solutions. Although Magento may work, you'll be consuming too that need server resources soon. Go for a dedicated server or a managed VPS (Virtual Private Server), but definitely for a host that is advertising support of Magento. Time for action – installing Magento on a Windows machine We'll speak more deeply about Magento hosting later on. Let's first download and install the package on a local Windows machine. Are you a Mac user? Don't worry, we'll give instructions for Mac users as well later on. Note that the following instructions are written for Windows users, but will contain valuable information for Mac users as well. Perform the following steps to install Magento on your Windows computer: Download the Magento installation package. Head over to http://www.magentocommerce.com/download and download the package you need. For a Windows user almost always the full ZIP package is the most convenient one. In our situation Version 1.7.0.2 is the latest one, but please be aware that this will certainly change over time when newer versions are released. You will need to create a (free) account to download the software. This account will also be helpful later on. It will give you access to the Magento support forums, so make sure to store your login details somewhere.The download screen should look something like this: If you're a beginner then it is handy to have some sample data in your store. Magento offers a download package containing sample data on the same page, so download that as well. Note that for a production environment you would never install the sample data, but for a test system like the local installation we're doing here, it might be a good idea to use it. The sample data will create a few items and customers in your store, which will make the learning process easier. Did you notice the links to Magento Go at every download link? Magento Go is Magento's online platform, which you can use out of the box, without doing any installation at all. However, in the remaining part of this article, we assume that you are going to set up your own environment and want to have full control over your store. Next, you need a web server, so that you can run your website locally, on your own machine. On Windows machines, XAMPP is an easy to use all-in-one solution. Download the installer version via: http://www.apachefriends.org/en/xampp-windows.html. XAMPP is also available for Mac and Linux. The download screen is as follows: Once downloaded, run the executable code to start the installation process. You might receive some security warnings that you have to accept, especially when you're using Windows Vista, 7 or 8, like in the following example: Because of this it's best to install XAMPP directly in the root of your hard drive, c:xampp in most cases. Once you click on OK, you will see the following screen, which shows the progress of installation: Once the installation has finished, the software asks if you'd like to start the Control Panel. If you do so, you'll see a number of services that have not been started yet. The minimum that you should start by clicking the Start button are Apache, the web server and MySQL, the database server. Now you're running your own web server on your local computer. Be aware that generally this web server will not be accessible for the outside world. It's running on your local machine, just for testing purposes. Before doing the next step, please verify if your web server is actually running. You can do so by using your browser and going to http://localhost or http://127.0.0.1 If all went well you should see something similar to the following: No result? If you're on a Windows computer, please first reboot your machine. Next, check using the XAMPP control panel if the Apache service is running. If it isn't, try to start it and pay attention to the error messages that appear. Need more help? Start with the help available on XAMPP's website at: http://www.apachefriends.org/en/faq-xampp-windows.html. Can't start the Apache service? Check if there are any other applications using ports 80 and 443. The XAMPP control panel will give you more information. One of the applications that you should for instance stop before starting XAMPP is Skype. It's also possible to change this setting in Skype by navigating to Tools | Options | Advanced | Connections. Change the port number to something else, for instance port 8080. Then close and restart Skype. This prevents the two from interfering with each other in the future. So, the next thing that needs to be done is installing Magento on top of it. But before we do so, we first have to change a few settings. Change the following Windows file: C:WindowsSystem32driversetchosts.Make sure to open your editor using administrator rights, otherwise you will not be able to save your changes. Add the following line to the host file: 127.0.0.1 www.localhost.com. This is needed because Magento will not work correctly on a localhost without this setting. You may use a different name, but the general rule is that at least one dot must be used in the local domain name. The following screenshot gives an example of a possible host file. Please note that every host file will look a bit different. Also, your security software or Windows security settings may prevent you from making changes to this file, so please make sure you have the appropriate rights to change and save its contents: Do you need a text editor? There are really lots of possibilities when it comes to editing text for the web, as long as you use a ''plain text'' editor. Something like Microsoft Word isn't suitable because it will add a lot of unwanted code to your files! For very simple things like the one above, even Notepad would work. But soon you'll notice that it is much more convenient to use an editor that will help you in structuring and formatting your files. Personally, I can recommend the free Notepad++ for Windows users, which is even available in lots of different languages: http://notepad-plus-plus.org. Mac users can have a look at Coda: http://panic.com/coda/ or TextWrangler http://www.barebones.com/products/textwrangler/. Unzip the downloaded Magento package and put all files in a subfolder of your XAMPP installation. This could for instance be c:xampphtdocsmagento. Now, go to www.localhost.com/magento to check if the installation screen of Magento is visible, as shown in the following screenshot. But do not yet start the installation process! Before you start the installation, first create a MySQL database. To do this, use a second browser tab and navigate to localhost | phpMyAdmin. By default the user is root, and so without a password you should be able to continue without logging in. Click on Databases and create a database with a name of your choice. Write it down, as you will need it during the Magento installation. After creating the database you may close the browser tab. It's finally time to start the installation process now. Go back to the installation screen of Magento, accept the license agreement and click on Continue. Next, set your country, Time Zone and Default Currency. If you're working with multiple currencies that will be addressed later on: The next screen is actually the most important one of the installation process and this is where most beginners go wrong because they do not know what values to use. Using XAMPP this is an easy task, however, fill in your Database Name, User Name (root) and do not forget to check the Skip Base URL Validation Before the Next Step box, otherwise your installation might fail: In this same form there are some fields that you can use to immediately improve the security level of your Magento setup. On a local test environment that isn't necessary, so we'll pay attention to those settings later on when we'll discuss installing Magento at a hosting provider. Please note that the Use Secure URLs option should remain unchecked for a local installation like we're doing here. In the last step, yes, really! Just fill out your personal data and chose a username and password. Also in here, since you're working locally you do not have to create a complicated, unique password now. But you know what we mean, right? Doing a live installation at a hosting provider requires a good, strong password! You do not have to fill the Encryption Key field, Magento will do that for you: In the final screen please just make a note of the Encryption Key value that was generated. You might need it in the future whenever upgrading your Magento store to a newer software version: What just happened? Congratulations! You just installed Magento for the very first time! Summarizing it, you just: Downloaded and installed XAMPP Changed your Windows host file Created a MySQL database using PhpMyAdmin Installed Magento I'm on Mac; what should I do? Basically, the steps using XAMPP are a bit different if you're using Mac. We shall be using Mac OS X 10.8 as an example of Mac OS version. According to our experience, as an alternative to XAMPP, MAMP is a bit easier if you are working with Mac. You can find the MAMP software here: http://www.mamp.info/en/downloads/index.html And the documentation for MAMP is available here: http://documentation.mamp.info/en/mamp/installation The good thing about MAMP is that it is easy to install, with very few configuration changes. It will not conflict with any already running Apache installation on your Mac, in case you have any. And it's easy to delete as well; just removing the Mamp folder from your Applications folder is already sufficient to delete MAMP and all local websites running on it. Once you've downloaded the package, it will be in the Downloads folder of your Mac. If you are running Mac OS X 10.8, you first need to set the correct security settings to install MAMP. You can find out which version of Mac OS X you have using the menu option in the top-left corner of your screen: You can find the security settings menu by again going to the Apple menu and then selecting System Preferences: In System Preferences, select the Security & Privacy icon that can be found in the first row as seen in the following screenshot: In here, press the padlock and enter your admin password. Next, select the Anywhere radio button in the Allow applications downloaded from: section. This is necessary because it will not be possible to run the MAMP installation you downloaded without it: Open the image you've downloaded and simply move the Mamp folder to your Applications folder. That's all. Now that you've MAMP installed on your system, you may launch MAMP.app (located at Applications | Mamp | Mamp.app). While you're editing your MAMP settings, MAMP might prompt you for an administrator password. This is required because it needs to run two processes: httpd (Apache) and mysqld (MySQL). Depending on the settings you set for those processes, you may or may not need to enter your password. Once you open MAMP, click on Preferences button. Next, click on Ports. The default MAMP ports are 8888 for Apache, and 8889 for MySQL. If you use this configuration, you will not be asked for your password, but you will need to include the port number in the URL when using it (http://localhost:8888). You may change this by setting the Apache port to 80, for which you'll probably have to enter your administrator password. If you have placed your Magento installation in the Shop folder, it is advised to call your Magento installation through the following URL: http://127.0.0.1:8888/shop/, instead of http://localhost:8888/shop/. The reason for this is that Magento may require dots in the URL. The last thing you need to do is visit the Apache tab, where you'll need to set a document root. This is where all of your files are going to be stored for your local web server. An example of a document root is Users | Username | Sites. To start the Apache and MySQL servers, simply click on Start Servers from the main MAMP screen. After the MAMP servers start, the MAMP start page should open in your web browser. If it doesn't, click on Open start page in the MAMP window. From there please select phpMyAdmin. In PhpMyAdmin, you can create a database and start the Magento installation procedure, just like we did when installing Magento on a Windows machine. See the Time for action – installing Magento on a Windows machine section, point 8 to continue the installation of Magento. Of course you need to put the Magento files in your Mamp folder now, instead of the Windows path mentioned in that procedure. In some cases, it is necessary to change the Read & Write permissions of your Magento folder before you can use Magento on Mac. To do that, right-click on the Magento folder, and select the Get Info option. In the bottom of the resulting screen, you will see the folder permissions. Set all of these to Read & Write, if you have trouble in running Magento. Installing Magento at a hosting service There are thousands of hosting providers with as many different hosting setups. The difficulty of explaining the installation of Magento at a commonly used hosting service is that the procedure differs from hosting provider to hosting provider, depending on the tools they use for their services. There are providers, for instance, who use Plesk, DirectAdmin, or cPanel. Although these user environments differ from each other, the basic steps always remain the same: Check the requirements of Magento (there's more information on this topic at the beginning of this article). Upload the Magento installation files using an ftp tool, for instance, Filezilla (download this free at: http://filezilla-project.org). Create a database. This step differs slightly per hosting provider, but often a tool, such as PhpMyAdmin is used. Ask your hosting provider if you're in doubt about this step. You will need: the database name, database user, password, and the name of the database server. Browse to your domain and run the Magento installation process, which is the same as we saw earlier in this article. How to choose a Magento hosting provider One important thing we didn't discuss yet during this article is selecting a hosting provider that is capable of running your online store. We already mentioned that you should not expect performance for a couple of dollars per month. Magento will often still run at a cheap hosting service, but the performance is regularly very poor. So, you should pay attention to your choices here and make sure you make the right decision. Of course everything depends on the expectations for your online store. You should not aim for a top performance, if all you expect to do during your first few years is 10,000 dollars of revenue per year. OK, that's difficult sometimes. It's not always possible to create a detailed estimation of the revenue you may expect. So, let's see what you should pay attention to: Does the hosting provider mention Magento on its website? Or maybe they are even offering special Magento hosting packages? If yes, you are sure that technically Magento will run. There are even hosting providers for which Magento hosting is their speciality. Are you serious about your future Magento store? Then ask for references! Clients already running on Magento at this hosting provider can tell you more about the performance and customer support levels. Sometimes a hosting provider also offers an optimized demo store, which you can check out to see how it is performing. Ask if the hosting provider has Magento experts working for them and if yes, how many. Especially in case of large, high-traffic stores, it is important to hire the knowledge you need. Do not forget to check online forums and just do some research about this provider. However, we must also admit that you will find negative experiences of customers about almost every hosting provider. Are you just searching for a hosting provider to play around with Magento? In that case any cheap hosting provider would do, although your Magento store could be very slow. Take for instance, Hostgator (http://hostgator.com), which offers small hosting plans for a couple of U.S. dollars per month. Anyway, a lot of hosts are offering a free trial period, which you may use to test the performance. Installatron Can't this all be done a bit more easily? Yes, that's possible. If your host offers a service named Installatron and if it also includes Magento within it, your installation process will become a lot easier. We could almost call it a ''one-click'' installation procedure. Check if your hosting provider is offering the latest Magento version; this may not always be the case! Of course you may ask your (future) hosting provider if they are offering Installatron on their hosting packages. The example shown is from Simple Helix provider (http://simplehelix.com), a well-known provider specialized in Magento hosting solutions. Time for action – installing Magento using Installatron The following short procedure shows the steps you need to take to install Magento using Installatron: First, locate the Installatron Applications Installer icon in the administration panel of your hosting provider. Normally this is very easy to find, just after logging in: Next, within Installatron Applications Installer, click on the Applications Browser option: Inside Applications Browser, you'll see a list of CMS solutions and webshop software that you can install. Generally Magento can be located in the e-Commerce and Business group: Of course, click on Magento and after that click on the Install this application button. The next screen is the setup wizard for installing Magento. It lists a bunch of default settings, such as admin username, database settings, and the like. We recommend to change as little as possible for your first installation. You should pick the right location to install though! In our example, we will choose the test directory on www.boostingecommerce.com: Note that for this installation, we've chosen to install the Magento sample data, which will help us in getting an explanation of the Magento software. It's fine if you're installing for learning purposes, but in a store that is meant to be your live shop, it's better to start off completely empty. In the second part of the installation form, there are a few fields that you have to pay attention to: Switch off automatic updates Set database management to automatic Choose a secure administrator password Click on the Install button when you are done reviewing the form. Installatron will now begin installing Magento. You will receive an e-mail when Installatron is ready. It contains information about the URL you just installed and your login credentials to your newfangled Magento shop. That's all! Our just installed test environment is available at http://www.boostingecommerce.com/test. If all is well, yours should look similar to the following screenshot: How to test the minimum requirements If your host isn't offering Installatron and you would like to install Magento on it, how will you know if it's possible? In other words, will Magento run? Of course you can simply try to install and run Magento, but it's better to check for the minimum requirements before going that route. You can use the following method to test if your hosting provider meets all requirements needed to run Magento. First, create a text file using your favorite editor and name it as phpinfo.php. The contents of the file should be: <?php phpinfo(); ?> Save and upload this file to the root folder of your hosting environment, using an ftp tool such as Filezilla. Next, open your browser using this address: http://yourdomain.com/phpinfo.php; use your own domain name of course. You will see a screen similar to the following: Note that in the preceding screenshot, our XAMPP installation is using PHP 5.4.7. And as we mentioned earlier, Magento isn't compatible with this PHP version yet. So what about that? Well, XAMPP just comes with a recent stable release of PHP. Although it is officially not supported, in most cases your Magento test environment will run fine. Something similar to the previous screenshot will be shown, depending on your PHP (and XAMPP) version. Using this result, we can check for any PHP module that is missing. Just go through the list at the beginning of this article and verify if everything that is needed is available and enabled: What is SSL and do I need it? SSL (Secure Sockets Layer) is the standard for secure transactions on the web. You'll recognize it by websites running on https:// instead of http://. To use it, you need to buy an SSL Certificate and add it to your hosting environment. Some hosting providers offer it as a service, whereas others just point to third parties offering SSL Certificates, like for instance, RapidSSL (https://www.rapidssl.com) or VeriSign (http://www.verisign.com), currently owned by Symantec. We'll not offer a complete set of instructions on using SSL here, which is beyond the scope of this article. However, it is good to know when you'll need to pay attention to SSL. There can be two reasons to use an SSL certificate: You are accepting payments directly on your website and may even be storing credit card information. In such a case, make sure that you are securing your store by using SSL. On the other hand, if you are only using third parties to accept payments, like for example, Google Checkout or PayPal, you do not have to worry about this part. The transaction is done at the (secure part of the) website of your payment service provider and in such a case you do not need to offer SSL. However, there's another reason that makes using SSL interesting for all shop owners: trust. Regular shoppers know that https:// connections are secure and might feel just a bit more comfortable in closing the sale with you. It might seem a little thing, but getting a new customer to trust you is an essential step of the online purchase process. Summary In this article we've gone through several different ways to install Magento. We looked at doing it locally on your own machine using XAMPP or MAMP, or by using a hosting provider to bring your store online. When working with a hosting provider, using the Installatron tool makes the Magento installation very easy. Resources for Article: Further resources on this subject: Magento: Exploring Themes [Article] Getting Started with Magento Development [Article] Integrating Facebook with Magento [Article]

(For more resources on JasperReports, see here.) Refer to the installPostgreSQL.txt file included in the source code download (chap4) to install and run PostgreSQL, which should be up and running before you proceed. The source code also includes two files named copySampleDataIntoPGS.txt and copySamplePaymentStatusDataIntoPGS.txt. The copySampleDataIntoPGS.txt file will help you to create a database named jasperdb5 and create a table named CustomerInvoices with five columns (InvoiceID, CustomerName, InvoicePeriod, ProductName, and InvoiceValue) and copy sample data for this article. Similarly, the copySamplePaymentStatusDataIntoPGS.txt file will help you to create a database named jasperdb5a and create a table named PaymentDetails with two columns (InvoiceID and PaymentStatus) and copy sample data. You will be using two JRXML files MultiDBReport.jrxml and PaymentStatusSubreport.jrxml in this recipe. You will find these files in the Task4 folder of the source code download for this chapter. The MultiDBReport.jrxml file is the master report, which uses the other file as a subreport. The master report has to refer to its subreport using a complete path (you cannot use relative paths). This means you have to copy the two JRXML files to the c:JasperReportsCookBookSamples folder on your PC. I have hardcoded this complete path in the master report (MultiDBReport.jrxml). How to do it... You are about to discover tricks for using multiple databases in a single report in the following simple steps: Open the PaymentStatusSubreport.jrxml file from the c:JasperReportsCookBookSamples folder. The Designer tab of iReport shows an empty report, as shown in the following screenshot: Right-click on the Parameters node in the Report Inspector window on the left of the Designer tab, as shown next. Choose the Add Parameter option from the pop-up menu. The Parameters node will expand to show the newly added parameter named parameter1 at the end of the parameters list. Click on parameter1, its properties will appear in the Properties window below the palette of components on the right of your iReport main window. Click on the Name property of the parameter and type InvoiceID as its value. The name of the parameter1 parameter will change to InvoiceID. Click on the Parameter Class property and select java.lang.Integer as its value. Click on the Default Value Expression property and enter 0 as its value, as shown in the following screenshot. Leave the rest of the parameter properties at their default values. Click the Report query button on the right of the Preview tab; a Report query dialog will appear, as shown in the following screenshot: Type SELECT * FROM paymentdetails WHERE invoiceid = $P{InvoiceID} in the Query editor. The fields of the paymentdetails table will be shown in the lower-half of the Report query dialog. Click the OK button, as shown in the following screenshot: Double-click the Fields node in the Report Inspector window. You will see that it contains invoiceid and paymentstatus fields, as shown below. Drag-and-drop the paymentstatus field from the Fields node into the top-left corner of the Detail 1 section, as shown in the following screenshot: Select PaymentDetails in the datasources drop-down list, as shown in the left image given below. Then switch to the Preview tab; a Parameter prompt dialog will appear, which will ask you for the invoice ID, as shown in the right image given below. Enter 1001 as the value of the InvoiceID parameter. You will see a report containing a single record showing the payment status of the invoice having the ID 1001. Switch back to the Designer tab. Click anywhere in the Page Header section; its properties will appear in the Properties window below the palette. Select the Band height property and set 0 as its value, as shown in the following screenshot:

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.

APIs (Application Programming Interface) are application-to-application programming interfaces that support harvesting information on the web using the known web standards. These APIs are provided by the entities who wish to expose parts of their resources that a third party can use. The APIs run transparent to the user and exposes just what they want to expose, with some providing access to material for public consumption with others giving access to resources based on authentication. In a sense they may be called a basic form of SAAS. Amazon.com, Google etc have exposed their APIs for some time. Twitter and New York Times have also exposed their API's which can be used to do some digging into the information contained in them, a kind of web mining. Many others such as Netflix have provided their own APIs described on their web sites. What is Twitter API? Twitter API is provided by the Social Networking and Micro-blogging service. Twitter API adheres to the web standards and one can talk to Twitter using HTTP. You can just about access anything on the Twitter web site. One example of creating a Microsoft SQL Server Report using Twitter API is available here - Tweets with Reporting Services, wherein the response from the Twitter API was in XML format. JSON (JavaScript Object Notation) is another format in which data is returned when an API call is made. In this article we will be looking at API call that returns a JSON response. Twitter exposes a large number methods through their API's such as API's for Search, Timeline, Status, User, Direct Message, Friendship and many more. As previously mentioned the responses will be in XML or JSON. Also while some APIs may take parameters others may not. The Twitter API used in this tutorial We will be looking at trends in Twitter API exposed by the url, http://search.twiiter.com/trends.format. We will be using the GET method and we will expect a JSON response. Since the volume of traffic may overwhelm, the calls that you can make to this in an hour are limited (also known as rate limiting) but not critical for the demo in this tutorial. Here is a typical call to the trends method on the Twitter API. Herein we will search for trends on the Twitter site and expect a response in JSON, if we use json instead of Format in the next URL address. Instead of:http://search.twitter.com/trends.Formattype-in, the following for URL address,http://search.twitter.com/trends.json When you plug the above in a web Brower you would get a response trends.json which you may save to your hard drive or, use it in any way you like. The next quoted text is what you get in response (note that this is what I got on Saturday 31, 2009 and what you get will be different), the content of the file trends.json you saved to your computer. Note that presently you get about top ten trends from this API call. {"as_of":"Sat, 31 Oct 2009 20:44:46 +0000","trends":[{"name":"Happy Halloween", "url":"http://search.twitter.com/search?q=%22Happy+Halloween%22+OR+%22Feliz+ Halloween%22"},{"name":"#nxzerosetechaves","url":"http://search.twitter.com/search?q=%23nxzerosetechaves"},{"name":"Danyl","url":"http://search.twitter.com/search?q=Danyl"},{"name":"#HappyHalloween","url":"http://search.twitter.com/search?q=%23HappyHalloween"},{"name":"#potterday","url":"http://search.twitter.com/search?q =%23potterday"},{"name":"X Factor","url":"http://search.twitter.com/search?q=%22X+ Factor%22"},{"name":"It's Halloween","url":"http://search.twitter.com/search?q=%22It %27s+Halloween%22+OR+%22Its+Halloween%22"},{"name":"Trick","url":"http://search.twitter.com/search?q=Trick+OR+%23trick"},{"name":"Paranormal Activity","url":"http://search.twitter.com/search?q=%22Paranormal+Activity%22"},{"name":"This Is It","url":"http://search.twitter.com/search?q=%22This+Is+It%22"}]} First of all what you see returned is a JSON object. If you are new to JSON review this article on my blog. The various elements that you see such as 'name', 'url' etc are fields in the response that are all described in the API documentation(look for Return Values). Some of the API calls can return a ton of information and you will have to know the API method so that you can correctly parse this data. Another thing you would notice is that the JSON object you get out is a nested object with many levels. You may need a JSON Parser to get a clearer picture of this nesting and I recommend using the online parser at this site. Using the above site, the JSON Object would appear as shown (only a portion is shown). New York Times API New York Times made available to the developers sometime in the middle of October 2008 APIs that can search New York Times for various kinds of information . Just like in Twitter there are a large number of APIs that you can use such as: Article Search; Best Sellers; Campaign Finance; Congress; and many others. Interested users can get on to this resource by signing up here requesting what APIs they would like to use. After signing up, New York Times would provide keys for the APIs that you want to access. It is important therefore, that the call should include the keys provided to you. For example, I received keys to access the following resources: Movie Reviews, Article Search, Best Sellers and Times Newswire. The key for the Movies Reviews API appears as shown here (the one shown here has been doctored and will not work). Movie Reviews API Key: b57378910b9fd80ecc73461547c93e8a:10:50673441 Using the New York Times API It is a valuable resource since you can get for example with the Article Search API access to more than 2.8 million articles from 1981. Using this is quite simple, just paste the URL shown below into the address box of your browser. Note that the key shown here is fake (but of correct format). http://api.nytimes.com/svc/search/v1/article?query=India&facets=publication_year&api-key=6c208890a4880093c30020be8fe17a40:0:50633441 This will display in the browser the JSON object that is returned as shown. You can use the previously mentioned site to parse it for more friendly display. {"facets" : {"publication_year" : [{"count" : 2724 , "term" : "2008"} , {"count" : 2345 , "term" : "2006"} , {"count" : 2311 , "term" : "2009"} , {"count" : 2282 , "term" : "2007"} , {"count" : 2144 , "term" : "2002"} ,{"count" : 2111 , "term" : "2001"} , {"count" : 1988 , "term" : "2005"} , {"count" : 1951 , "term" : "2004"} , {"count" : 1921 , "term" : "1985"} , {"count" : 1798 , "term" : "2003"} , {"count" : 1761 , "term" : "1999"} , {"count" : 1720 , "term" : "2000"} , {"count" : 1642 , "term" : "1998"} , {"count" : 1442 , "term" : "1984"} , {"count" : 1382 , "term" : "1986"}]} , "offset" : "0" , "results" : [{"body" : "BARSUR, India — At the edge of the Indravati River, hundreds of miles from the nearest international border, India effectively ends. Indian paramilitary officers point machine guns across the water. The dense jungles and mountains on the other side belong to Maoist rebels dedicated to overthrowing the government. "That is their liberated" , "byline" : "By JIM YARDLEY" , "date" : "20091101" , "title" : "Maoist Rebels Widen Deadly Reach Across India" , "url" : "http://www.nytimes.com/2009/11/01/world/asia /01maoist.html"} ,.........(there is more of this but abbreviated here) Response Format As you can see the responses to the API calls return JSON objects in general of the form shown belo w (this one is of the form returned by the Twiiter API). What we propose to do is to use jQuery's GetJSON() method to get the JSON Objects and use Microsoft AJAX JavaScript files to display the data on the web page. Both jQuery javascript files and Microsoft ASP.NET AJAX files are both available on the Microsoft ECN (CDN). The GetJSON() method as well as the Microsoft ASP.NET AJAX templates can be easily implemented in the Visual Studio 2008 IDE. Alternatively Microsoft AJAX can also be used to retrieve data from the web sites. In this article the GetJSON() method will be used. {"x":{"y":[{"a1":"b1", "c1":"d1"}, {"a2":"b2", "c2":"d2"}]},.... "f":"g",....}

(For more resources on PrestaShop 1.3, see here.) Let's move on with our next step. Of course, exploring every tab in the back office would be advantageous, but we will specifically touch only those points that will affect your theming process. We will now look at how we can modify the following: Logo Top of page Adding FEATURED PRODUCTS block Footer Title Placing the other modules useful for your store on other section of your pages. Before going further, I would like to emphasize two important points. They are: Always work on a copy of your default theme: If you have not copied the default theme file, I would advise that when you start your development work, you copy the default theme file so that you have a backup or a comparison to work with. We will be working on the copy of the default theme, as in some cases, we will still change a few lines of codes to modify the theme. This means that if you ever make a huge blunder, you will at least have the original to start with again. If the worst ever happens, you can always upload the original file again to overwrite your errors, but that will be a big waste of time. Keep a quick reference list of any modifications made to any file: It may sound a bit tedious, but you will find this advice useful to heed. There are a few ways of making modifications to your theme, sometimes through modification of your other files (which are not in the theme folder). You may copy the file and put it into the theme folder to make the changes, or it is also possible to merely modify them by overwriting the file in its location. Whichever way you chose, when you need to modify files which are not in your custom theme folder, you should make a quick note of what changes you have made and where have you made them. Why? Because when there is a new version of PrestaShop, you will need to upgrade your PrestaShop site, thus the modifications you have made will be lost. The modifications in the theme folders will remain even if you update the version of your PrestaShop site. By keeping a list of the modifications you've made, it will be much easier to track back to where to re-apply them after you have upgraded your PrestaShop installation. Never procrastinate on making this quick list because you will always find that it is a waste of time to find and trace those changes later; even just six months down the road. Copying the default theme file When you download PrestaShop, by default, you will have a copy of the PrestaShop theme folder. Go to the PrestaShop_1.3.1/themes/PrestaShop folder. Copy this entire folder and save it on your computer. You may rename the theme accordingly, for example, theme1. Compress this into a ZIP file. Upload the renamed folder into the themes directory on your hosting through your cPanel or FTP. You will now have two themes in your /themes folder which are PrestaShop and theme1. You can now log in to your PrestaShop Back Office | Preferences | Appearance and switch to your theme1 that you just installed and click on the Save button. On this page, you may also control what logo, favicon, and the navigation pipes you want to use throughout your website. Now, let's start with the modification of these theme elements to complete the look of your new theme. Logo A logo is an important element of a company's or store's image, and it can contribute to the brand's marketing success. Therefore, getting a good quality logo is fundamental for the business. Getting a unique and attractive logo design can be daunting, especially for those who are not born with a flair for design. However, fortunately, there are various resources that you can use to get ideas or even create a very professional looking logo that you can use in your new online store. Some online resources for logo designs can be found at: http://www.logomaker.com—This is an online resource that allows you to freely create a logo, but you have to pay to download your new creation, which basically uses their online inputs. Quite attractive and interesting looking logos can be found and designed here. http://cooltext.com—This one describes itself as A free graphics generator for web pages and anywhere else you need an impressive logo without a lot of design work. It allows you to choose the image you would like through a few simple steps. You only need to enter the words or company name using a form and you'll have your own custom image created on the fly. The logo you designed is downloadable for free. http://www.simwebsol.com/ImageTool/Default.aspx—This is a Web 2.0 logo generator. Free to use and download. It requires you to fill in a few fields and generates the image file quite easily. However, the background is limited to RGB flat choices and you only have 23 images that can be chosen from to insert. http://www.onlinelogomaker.com/ - A full featured free online logo design tool with a clean and easy interface and thousands of logo templates Another element, which is quite important here, is the favicon. The Favicon is the little icon representing the website you are visiting which gets displayed in the address bar of every browser. Usually, the favicon and the logo are the same thing, except for their sizes and the formats. They are not necessarily the same though. You may find some online resources that you can use to generate a favicon for the store. Make sure you have prepared the favicon icon before you try to replace the current favicon. If you are unsure of how to go about making a favicon, you may generate it online (using,http://www.favicon.cc/ or http://www.freefavicon.com/). Save the file on your hard drive and then upload it to your PrestaShop store. Uploading it is shown in the next section. Time for action—Replacing the default logo and favicon on your site The logo and the favicon can be replaced through Back Office | Preferences | Appearance, as shown in the following screenshot:     Browse the file you want to use from your computer. Upload the files and click on the Save button. You need to refresh your back office browser before you replace the logo and the new favicon.ico file. You also need to clean up your browser's cache and refresh the browser to see the favicon in the frontend of the website.     Upon saving and refreshing your browser, the updated images will be displayed. What just happened? In this simple exercise, you have just uploaded the logo that you had created, and PrestaShop has, by default, placed it in the correct directory in your new theme1 directory through the back office panel. If you did not choose the new theme, for example, theme1 in Preferences | Appearance under Themes, the logo you upload will go to the wrong directory. The Center Editorial Block The Center Editorial Block is where you see the main image at the center column, as we indicated previously in the front office. This is an important block, as this is where your visitors first arrive when they visit your store. It gives a first impression to your site visitor, and therefore, you need to consider what to include in it very carefully. Time for action—Modifying the Center Editorial block The Centre Editorial Block can be modified through Back Office | Modules | Tools | Home text editor. In this section, you can also edit the Centre Block image, which is referred to as Homepage's logo, and this title can be quite misleading as it may be confused with the actual logo. However, we have covered this matter in the previous article and did a mapping of each field here to the front office page of the store. You only need to upload the image you want to replace it with and continue with editing the Homepage logo link, which is the link for this image (Homepage's logo). You may just leave it set to your current website address if you want (for example, www.mydomainname.com). You can also leave it blank if you don't want the image to be a link. Furthermore, you will see Homepage logo subheading, which is the small letters you see on the default theme page that appear under the image. Let's replace the Homepage's logo image, Homepage logo link, and a new Homepage logo subheading: Click on the Update the editor button. Review your changes in your front office browser. You will need to refresh the page once to see the effect. It is possible to work with different image sizes, but the width of the image will "disturb" your column settings. If you are not going to make any unnecessary changes, then it is best to use images of the safe maximum width for the center column which is 530 pixels. If you exceed this width it will push your right column outside the standard browser view. Now let's have a look at what you have achieved so far. What just happened? You have modified your Center Editorial Block by inserting a new Homepage's logo image, Homepage logo link, and a new Homepage logo subheading. Top of pages block We will look at the header section of the page. The default layout comprises the following in the header section: Currency block (links to the available currencies used on the site). Languages block (links to the available language translation of the pages interface). Permanent link block: Contact (icon that links to the contact form page) Sitemap (icon that links to the sitemap page) Bookmark (icon that helps you bookmark a particular page on the site) Search block User links block: Your Account (icon that links to the login page or registration page). When logged in, it links to the account page that lists everything the customer can do with their account. It is only when the viewer is logged out that it links to the authentication page Cart (icon that links to the shopping cart summary page ) Welcome, Log in (links to the login page or registration page)     Time for action—Modifying the Top of pages To get these elements back on the pages, you will need to install and enable the relevant modules. These simple steps will need little modifications unless you want to add a new currency and a new language. Let's enable these modules through these simple steps: Currency block—go to Modules | scroll down to Blocks | Currency block. Languages block—go to Modules | scroll down to Blocks | Language block. Search block—go to Modules | scroll down to Blocks | Quick Search block. Permanent link block—go to Modules | scroll down to Blocks | Permanent links block. By default, these modules tend to appear on the pages in the order you installed and enabled them. The first one will appear the leftmost while the last one will be the rightmost. You can shift the arrangement by installing them according to what you want to appear on the leftmost or the rightmost sides. Notice that the Permanent link block is on the right as we enabled it last. There is an easier way to do this as well, which we will cover in the next section. You can modify this by working on the position of the modules within the Top of pages hooks. There are two similar hooks, which can be quite confusing, that is, the Top of pages and Header. The blocks are positioned or "transplanted" in a Top of pages hook and not Header of pages. The Welcome, Log in, Cart, and the User login links can be enabled through Back Office | Modules | Blocks | User info block. Upon installing and enabling the module, you will have the Welcome, Log in, Your Account, and Cart link displayed on your front office. By default, all those are automatically hooked to the Top of pages once they are enabled. If it is not, you can have it hooked through transplanting the module to the hook, as shown in the next screenshot. This can be done by following these simple steps: Go to Back Office | Modules | Position | Transplant a module.     Choose the Module you want to transplant from the drop-down menu. Choose the hook from Hook into, the one you want the Module to go into. Click on the Save button. The arrangement of the blocks can be done by moving them around within the hooks, which we will see next. Go to Modules | Positions. There you can arrange the position of the modules within the hooks by dragging each of them to the required position. As you can see, there are the two similar hooks which may be confusing, namely, the Header of pages and the Top of pages. Compare it with what you have at the front office in the next screenshot.   The Quick Search block does not appear despite it being hooked at the Header of pages. The other blocks which are hooked to the Top of pages are displayed in the front office. The same thing with the User info block; you only see the one which is hooked to the Top of pages and not the one in the Header of pages. The Top of pages hook is used to display a module at the top of the page. The Header of pages hook is used to put code in the <head> tag of the website. If you want to move a module or delete it from the top of the page, you should use the Top of pages hook, not the Header of pages hook. Modules that are in the Header of pages hook should not be removed, since they are required for the module to function correctly. For example, if you remove the Quick search block from the Header of pages hook, the search autocomplete will not work, since the code for it is missing. The resulting JavaScript error will also cause other problems on the website such as the Categories block not displaying any categories. To move the modules to the left or right, you need to move them up within the hook. The lower it is within the hook, the more to the right the module will appear, whereas the upper within the hook will be displayed on the left. For example, the Currency block is first in the list, and it is displayed on the left of the Top of pages section on the webpage. What just happened? You just learnt the differences between the hooks Top of pages and Header of pages in PrestaShop. You also get to modify the blocks you want to use on the top of the page and how to move them around within the hook.

(For more resources on Oracle, see here.) The top three things As we've just seen, the most common things you can do are these: Get content approved: This is the most obvious use of the workflow we've just seen. Get people notified: Remember when we were adding workflow steps there was a number of required approvers on the Exit Conditions tab in the Add New Step dialog. If we set that to zero we accomplish one important thing: Approvers will get notified, but no action is required of them. It's a great way to "subscribe" a select group of people to an event of your choice. Perform custom actions: And if that's not enough you can easily add custom scripts to any step of a workflow. You can change metadata, release items, and send them to other workflows. You can even invoke your custom Java code. And here's another really powerful thing you can do with custom workflow actions. You can integrate with other systems and move from the local workflow to process orchestration. You can use a Content Server workflow to trigger external processes. UCM 10gR3 has an Oracle BPEL integration built in. This means that a UCM workflow can be initiated by (or can itself initiate) a BPEL workflow that spans many systems, not just the UCM. This makes ERP systems such as Siebel, PeopleSoft, SAP, and Oracle e-Business Suite easily accessible to the UCM, and content inside the UCM can be easily made available to these systems. So let's look at the jumps and scripting. Jumps and scripting Here's how to add scripting to a workflow: In Workflow Admin select a step of a workflow we've just created. Click on the Edit button on the right. The Edit Step dialog comes up. Go to the Events tab (as shown in the following screenshot): There are three events that you can add custom handlers for: Entry: This event triggers when an item arrives at the step. Update: This happens when an item or its metadata is updated. It's also initiated every hour by a timer event, Workflow Update Cycle. Use it for sending reminders to approvers or escalating the item to an alternative person after your approval period has expired. Exit: This event is triggered when an item has been approved and is about to exit the step. If you have defined Additional Exit Conditions on the Exit Conditions tab then those will be satisfied before this event fires. The following diagram illustrates the sequence of states and corresponding events that are fired when a content item arrives at a workflow step: Great! But how do we can actually add the jumps and custom scripts to a workflow step? How to add a jump to a workflow step Let's add an exception where content submitted by sysadmin will bypass our Manager Approval workflow. We will use a jump—a construct that causes an item to skip the normal workflow sequence and follow an alternative path. Here's how to do it: Add a jump to an Entry event of our very first step. On the Events tab of the Edit Step dialog, click on the Edit button—the one next to the Entry event. The Edit Script dialog displays (as shown in the following screenshot): Click on the Add button. The Add Jump dialog comes up (as shown in the following screenshot): Let's call the jump Sysadmin WF bypass. You don't need to change anything else at this point. Click on OK to get back to the Edit Script dialog. In the Field drop-down box pick Author. Click on the Select… button next to the Value box. Pick sysadmin (if you have trouble locating sysadmin in the list of users, make sure that the filter check-box is un-checked). Click the Add button below the Value field. Make sure that your clause appears in the Script Clauses box below. In the Target Step dropdown pick Next Step. Once you have done so the value will change to its script equivalent, @wfCurrentStep(1). If you have more than one step in the workflow, change 1 to the number of steps you have. This will make sure that you jump past the last step and exit the workflow. Here's how the completed dialog will look (as shown in the following screenshot): Click on OK to close. You're now back to the Events tab on the Edit Step dialog. Notice a few lines of script being added to the box next to the Entry event (as shown in the following screenshot): OK the dialog. It's time to test your changes. Check in a new document. Make sure you set the Author field to sysadmin. Set your Security Group to accounting, and Account to accounting/payable/current. If you don't, the item will not enter our workflow in the first place (as shown in the following screenshot): Complete your check-in and follow the link to go to the Content Info page. See the status of the item. It should be set to Released. That's right. The item got right out of the workflow. Check in a new document again, but use some other author. Notice how your item will enter the workflow and stay there. As you've seen, the dialog we used for creating a jump is simply a code generator. It created a few lines of script we needed to add the handler for the Entry event. Click on the Edit button next to that code and pick Edit Current to study it. You can find all the script function definitions in iDoc Reference Guide. Perfect! And we're still not done. What if you have a few common steps that you'd like to reuse in a bunch of workflows? Would you just have to manually recreate them? Nope. There are several solutions that allow you to reuse parts of the workflow. The one I find to be most useful is sub workflows.

  (For more resources on this topic, see here.) The reader can benefit from the previous article on Request Flow in Kohana 3. Routing in Kohana If you remember, the bootstrap file comes preconfigured with a default route that follows a very simple structure: Route::set(‘default’, ‘(<controller>(/<action>(/<id>)))’) ->defaults(array( ‘controller’ => ‘welcome’, ‘action’ => ‘index’, )); This tells Kohana that when it parses the URL for any request, it first finds the base_url, and then the next segment will contain the controller, then the action, then an ID. These are all optional setgments, with the default controller and action being set in the array. We have taken advantage of this route with other controllers like our Profile and Message controller. When we visit http://localhost/egotist/profile, the route sets the controller to profile, and since no action or ID is explicitly defined in the URL, the default action of ‘index’ is used. When we requested http://localhost/egotist/messages/get_messages from within our Profile Controller, we also followed this route; however, neither defaults were needed, and the route asked for the Messages Controller and its get_messages action. In our Profile controller, we are only using one array of example messages to test functionality and the expected behavior of our application. When we implement a data store and have multiple users with profiles in our application, we will need a way to decipher which profile a user wants to see. Because the default route already has an available parameter for ID, we can use that to pass an ID to our Profile Controller’s index action, and have the messages controller then find the proper messages for that user.   Time for action – Making profiles dynamic using ID Once a database is tied to our application, and more than one user has a profile, we will need some way of knowing which profile to display. A simple and effective way to do this is to pass a user ID in the route, and have our controller use that ID to find the right messages for the right user. Let’s add some more test data to our messages system, and use an ID to display the right messages. Open the Profile Controller in our application/classes/controller/ directory named profile.php. Since the action_index() method is the controller action that is called when a profile is viewed, we will need to edit it to look for the ID parameter in the URI like this: public function action_index(){ $content = View::factory(<profile/public>) ->set(<username>, <Test User>) ->bind(<messages>, $messages); $id = (int) $this->request->param(‘id’); $messages_uri = "messages/get_messages/$id"; $messages = Request::factory($messages_uri)->execute()->response; $this->template->content = $content;} Now, we are retrieving the ID from the route and passing it along in our request to the Messages Controller. This means that class must also be updated. Open the messages.php file located in application/classes/controllers/ and modify its action_get_messages() method as follows: public function action_get_messages(){ $id = (int) $this->request->param(‘id’); $messages = array( 1 => array( ‘This is test message one for user 1’, ‘This is test message two for user 1’, ‘This is test message three for user 1’ ), 2 => array( ‘This is test message one for user 2’, ‘This is test message two for user 2’, ‘This is test message three for user 2’ ) ); $messages = array_key_exists($id, $messages) ? $messages[$id] :NULL; $this->request->response = View::factory(‘profile/messages’) ->set(‘messages’, $messages);} Open the page http://localhost/egotist/profile/index/2/. It should look like this: Browsing to http://localhost/egotist/profile/index/1/ will show the messages for user 1, i.e., the test messages placed in the message array under key 1. What just happened? At the very beginning of our index action in our Profile Controller, we set our $id variable by getting the ID parameter from the route. Since Kohana has parsed our route for us, we can now access these parameters via the request object’s param() method. Once we got the ID variable, we then created and executed the request for the message controller’s get_messages action, and passed the ID to that method for it to use. In the Message Controller, we used the same method to extract the ID from the request, and then used that ID to determine which messages from the messages array to display. Although this works fine for illustrating routing for these two users, the code is far from ready, even without a data store or real user data, but it does show how the parameters can be read and used. Because most of the functionality in the controller will be replaced with our database and more precise data being passed around, we can overlook the incompleteness of the current controller actions, and begin looking at creating a URL that is better looking than http://localhost/egotist/profile/index/2/ for finding a user profile by ID. Creating friendly URLs using custom routes Consider how nice it would be if our users could browse to a profile without putting ‘index’ in the action portion of the URI, like this: http://localhost/egotist/profile/2. This looks much more pleasing, and is more in line with what we would like our URLs to look like in web apps. It is in fact very easy to have Kohana use a route to remove the index action from the URI. Routes not only make our URLs more pleasing and descriptive, but they make our application easier to maintain in the long run. We have more control over where our users are being directed from how the URL is constructed, without having to create controller actions designed to handle routing.   Time for action – Creating a Custom Route So far, we have been using the default route that is in our application bootstrap. As our application grows, so will the number of available ‘starting points’ for our user’s requests. Not every controller, action, or parameter has to comply with the default route, and this gives us a lot of flexibility and freedom. We can add a custom route to handle user’s profiles by adding it to our bootstrap.php file. Open the bootstrap.php file located in application/directory and modify the routes block so it looks like this: /** * Set the routes.Each route must have a minimum of a name,a URI * and a set of defaults for the URI. */Route::set(‘profile’, ‘profile/<id>’) ->defaults(array( ‘controller’ => ‘profile’, ‘action’ => ‘index’, ));Route::set(‘default’, ‘(<controller>(/<action>(/<id>)))’) ->defaults(array( ‘controller’ => ‘welcome’, ‘action’ => ‘index’, )); Now, we can view the profile pages without having to pass the index action in the URL. Open http://localhost/egotist/profile/2 in a browser; it should look like this: Browsing to profiles with a more friendly URL is made possible through Kohana’s routes. What just happened? By setting routes using the Route::set static method, we are essentially creating filters that will be used to match requests with routes. We can name these routes; in this case we have one named default, and one named profile. Kohana uses the second parameter in the set() method to compare against the requested URI, and will call the first route that matches the request. Because it uses the first route that matches the request, it is very important when ordering route definitions. If we put the default route before the profile route, the profile route will never be used, as the default route would always match first. Because it looks for a match, it does not use discretion when determining the right route for a request. So if we browse to http://localhost/egotist/profile/index/2, we will be directed to the default route, and get the same result. The default route may not be available for all the routes we create in the future, so create routes that are as explicit as we can for our needs. Right now, our application assumes any data that is passed after a controller segment named ‘profile’ must be the ID for which we are looking. In our current application setup, we only need digits. If a user passes data into the URL that is not numeric for the ID parameter, we do not want it to go to that route. This can be accomplished easily inside the Route::set() method.  

Getting ready You need a working installation of Joomla! 1.5.x. For exercise purpose, you can install that on your local computer. The web server should have PHP5 installed. Then you need to install Fabrik component. This component is available for free from http://fabrikar.com/download. Download the latest version of the component and install it from Extensions | Install/Uninstall screen in Joomla! administration panel. Also plan for the application you want to develop. For example, we are developing an event calender. This event calender will contain the following information: Event Category Event Name Venue Start Date & Time End Date & Time Event Description Attached Document Created by This is a very simple list of information we need. Based on the we will create two database tables: categories and events. The table structure is shown in the following diagram. The above table diagrams show that categories table is linked to events table by foreign key category_id. Similarly, we have added user_id field in events table, so that we can link it to jos_users table. Whenever a user creates an event, his or her user ID will be added to this field. For creating the tables in Joomla! database, connect to that database using phpMyadmin or some other interface, and run the following SQL command: CREATE TABLE `categories` (`id` INTEGER AUTO_INCREMENT DEFAULT NULL ,`name` VARCHAR(200) DEFAULT NULL ,PRIMARY KEY (`id`)) COMMENT 'contains categories of events';CREATE TABLE `events` (`id` INTEGER AUTO_INCREMENT DEFAULT NULL ,`category_id` INTEGER DEFAULT NULL ,`event_name` MEDIUMTEXT DEFAULT NULL ,`venue` VARCHAR(100) DEFAULT NULL ,`start` DATETIME DEFAULT NULL ,`end` DATETIME DEFAULT NULL ,`description` MEDIUMTEXT DEFAULT NULL ,`attachment` VARCHAR(250) DEFAULT NULL ,`user_id` INTEGER DEFAULT NULL ,PRIMARY KEY (`id`)) COMMENT 'list of events';ALTER TABLE `events` ADD FOREIGN KEY (category_id) REFERENCES `categories` (`id`); Successful execution of the above code block will create two tables and add a foreign key to events table linking it to categories table. With creation of these two table we are set to create our event calendar application. How to do it... Follow the steps below: From Joomla! Administration panel, click Components | Fabrik |  Connections. That shows existing database connections. By default, connection to Joomla! database is created. You can create  new database connection by clicking New button and filling in the form. Click on Tables link in this screen. That shows existing tables created in Fabrik. In Table screen, click on New button to add a new table. That shows Table: [New] screen. In Label field type Categories, and in Introduction field, type Event Categories. Then select Yes in Published radio box to the right side. Accept default values for other fields. Then click Access tab. That shows Access Rights. Accept the default values in Access tab. Now click Data tab. From here you have to configure which data table you want to use. From Connection drop down list, select site database. Then click on Link to Table drop down list and select categories table. In Order By drop down list, select name. There are some other options in this tab, but those cannot be configured until you save the table. Now click Save button to save the table.

Displaying author picture on posts Did you like the previous recipe in the first part? I hope you did! But personally, I must admit that even though displaying author information looks very cool, something is missing from the previous recipe. Can you guess what is it? It is a picture of the author, of course. Even if your author-related information is precise and complete, a picture is still essential. This is because it is the easiest, and quickest, way for a reader to recognize an author. But sadly, WordPress can't handle author pictures by default. Let's learn how to create a hack that will allow us to display the author's picture in the way that we want to. Getting ready As we'll be using author pictures in this recipe, you should start by requesting a picture of all of your authors. Although it isn't necessary, it will be really better if all of the pictures have the same width and height. A square of 80 to 110 pixels is a good standard. Also, make sure that all of your pictures have the same format, such as .jpg, .png, or .gif. How to do it Now that you have collected pictures of all of your authors, we can start to hack WordPress and insert author pictures in the posts First, you have to rename your images with the author IDs. You can also use author's last name if you prefer, but in this example I am going to use their IDs. Once you have your renamed authors' pictures, upload them to the wp-content/themes/yourtheme/images directory. Open the file single.php and add the following code within the loop: <img src="<?php bloginfo('template_url); ?>/images/<?php the_author_ID(); ?>.jpg" alt="<?php the_author(); ?>" /> Save the single.php file and you're done. Each post now displays a picture of its author! How it works The working of this code is pretty simple. You simply concatenated the result of the the_author_ID() function with the theme URL to build an absolute URL to the image. As the images are named with the author ID (for example, 1.jpg, 4.jpg, 17.jpg, and so on), the the_author_ID() function gives us the name of the picture to be displayed. You just have to add the .jpg extension. There's more... Now that you've learnt how to display the picture of the current author, you should definitely use this recipe to enhance the previous recipe. The following code will retrieve the author information, and display the author picture as we have learnt earlier: <div id="author-info"><h2>About the author: <?php the_author();?></h2><img src="<?php bloginfo('template_url); ?>/images/<?php the_author_ID(); ?>.jpg" alt="<?php the_author(); ?>" /><?php the_author_description(); ?><?php the_author();?>'s website: <a href="<?php the_author_url(); ?>"><?php the_author_url(); ?></a><br />Other posts by <?php the_author_posts_link(); ?></div><!--/author-info--> The outcome of the preceding piece of code will look similar to the following screenshot: Displaying the author's gravatar picture on posts Gravatars (which stands for Globally recognized avatars) is a popular service, that allows you to associate an avatar image to your email address. On October 18, 2007, Automattic (The company behind WordPress) acquired Gravatar. Since WordPress 2.5 the popular blogging engine is fully gravatar-compatible, which results, in the ability to include gravatars in comments. In this recipe, I'll show you how to modify the previous code to use the author gravatar instead of a personal picture. Getting ready As we're going to use Gravatars, you (and each of your authors) first need a gravatar account. Carry out the following steps to create a gravatar account and associate an image to your email address. Go to the web site http://en.gravatar.com/site/signup, and enter your email address into the text field. Gravatar will send you a confirmation via email. Check your emails and open the one received from Gravatar. Click on the link to confirm your email address. Choose a username and a Password for your account. Once your username and Password has been created successfully, you'll see a text that reads Whoops, looks like you don't have any images yet! Add an image by clicking here. Click on the given link, and choose to upload a picture from your computer's hard drive, or the Internet. Once you are done choosing and cropping (if necessary) your picture, you have to rate it. Click on G unless—except, if your avatar is meant for mature audiences only. Done! You now have your own gravatar. How to do it Open the file single.php from the theme you're using and paste the following code: $md5 = md5(get_the_author_email());$default = urlencode( 'http://www.yoursite.com/wp-content/themes/yourtheme/images/default_avatar.gif' );echo "<img src='http://www.gravatar.com/avatar.php?gravatar_id=$md5&amp;size=60&amp;default=$default' alt='' />"; How it works The first thing to do is to get an md5 sum from the author's email address. To do so, I used the php md5() function along with the get_the_author_email() function. I didn't use the_author_email() because this function directly prints the result without allowing you to manipulate it with php I then encoded the URL of a default picture that is to be shown if the author hasn't signed up to Gravatar yet. Once done, the gravatar can be displayed. To do so, visit the web site: http://www.gravatar.com/avatar.php with the following parameters: gravatar_id: The gravatar id, which is an md5 sum of the user email size: The gravatar size in pixels default:The absolute URL to an image which will be used as a default image if the author hasn't signed up to gravatar yet Adding moderation buttons to the comments A common problem with comments is spam. Sure, you can moderate comments and use the Akismet plugin. However, sometimes someone leaves a normal comment, you approve it, and then the spammer—who knows that his comments aren't being accepted by the moderator—starts to spam your blog. Even though you can do nothing against this (except moderating all of the comments), a good idea is to either add spam and delete buttons to all of the comments. This way, if you see a comment saying spam while reading your blog, then you can edit it, delete it, or mark it as spam. I got this useful tip from Joost de Valk, who blogs at www.yoast.com Getting ready The following screenshot shows normal comments without the edit, delete and spam buttons: There's nothing complicated at all with this recipe. However, you must be sure to know which kind of blog the users are allowed to edit or delete your comments. For a list of actions and user roles, see the section named Controlling what users can do, which is later in this article. How to do it Open the file functions.php and paste the following piece of code: function delete_comment_link($id){if (current_user_can('edit_post')){echo '| <a href="'.admin_url("comment.php?action=cdc&c=$id").'">del</a> ';echo '| <a href="'.admin_url("comment.php?action=cdc&dt=spam&c=$id").'">spam</a>';}} Save the file functions.php and open the file comments.php. Find the comments loop and add the following lines: <?phpedit_comment_link();delete_comment_link(get_comment_ID());?> Save the file comments.php and visit your blog. You now have three links on each of the comments to edit, to delete (del), and to mark as spam as shown in the following screenshot: How it works In this recipe we started by creating a function. This function first verifies whether the current user has the right to edit posts. If yes, then the admin URLs to mark the comment as spam or delete it are created and displayed. In the file comments.php, we have used the edit_comment_link(), which is a built-in WordPress function. Some themes include this by default. We then used the comment ID as a parameter to the delete_comment_link() function that you had created earlier.

Weird Hap'nins requirements will be the need to: Get external feed sources and allocate them to menu links on the web site Create the means to automatically fetch and display article items located in the feeds Display blocks of latest content from each feed source on the front page Theme The theme chosen is "Strange Little Town", which is a contributed theme that fits the description of this unique web site. Build Weird Hap'nins Vaughan Pyre is a very ambitious webpreneur. What he really hopes for is a web site that is completely self-maintaining, and on which he can place some Google AdSense blocks. Clicks from the visitors to his site will ensure that he makes lots of money. For this, he needs a site where the content updates regularly with fresh content so that visitors will keep coming back to click on some more Google ads. Vaughan's ultimate objective is to create several of these web sites. Modules This is, surprisingly, a very simple site to build, and much of the requirements can be achieved by using the Core Aggregator module. Indeed, were it not for the fact that Vaughan needs the content to automatically update, we needn't use any module other than the Aggregator module. Optional Core modules We will be using the following Core modules, which can be enabled via the Modules page: Aggregator—for aggregating syndicated content (RSS, RDF, and Atom feeds) Contributed modules We will also be using the following contributed modules from Drupal.org. Install, and enable them via the Modules page: Poormanscron—internal scheduler for users without a cron application Configure the Poormanscron module First we need to enable the Poormanscron module, so that the incoming feeds will be able to self-refresh. From the Administer page, we will access the Poormanscron configuration page, mainly to set the time interval between runs of cron to update feed items, as shown in the following screenshot: In this case, we have left the Time intervals at the default value of 60 minutes. Configure the Aggregator module The Aggregator module should be configured to define the feed sources, how often they will be polled, and how they're categorized. For this, if we select the Feed aggregator link on the Administer page, then we should arrive at the following page: On the Settings page, we will define some more requirements, as follows: Allowed HTML tags—which are the tags that are embedded in the incoming feed that we want Drupal to accept. The allowed tags do not include image tags. So if any images are coming with the feed, then they will be excluded. However, we don't want this to happen, so we have added the image tag <img> to the list. Items shown in sources and categories pages—we have defined this to be 20 items, but you may select another figure. Discard items older than—we want the feed items to be completely refreshed every week so we have set this at 1 week. Category selection type—we are not categorizing the feeds, so we will leave this setting as it is. Basic content The site is built around the Aggregator module, and no other Content type will need to be created. Vaughan has decided to initially use three feeds obtained from www.newsfeedmaker.com, as follows: Bad News—http://www.newsfeedmaker.com/feed.php?code=ddb874f7 Crime—http://www.newsfeedmaker.com/feed.php?code=33a5a46a Paranormal—http://www.newsfeedmaker.com/feed.php?code=936f006a It is from these feeds that we will create the necessary content. Tips and trapsAn excellent source for "mashup" feeds on any topic is pipes.yahoo.com. Add feeds On the Add feeds page, which is under the Feed aggregator configuration page, we finally get to define our feeds, and how often we want them to be polled. We want our Bad News feed to be polled every hour, so we have configured it this way. The same procedure is followed to create the feeds for Crime and Paranormal.

Designing a better view At this stage, you might ask: Why are we going through so much effort to serve a simple HTML page? Why not put everything in one file? For a simple site, that's a valid point—but whoever heard of a simple site? One of the coolest things about CI is the way it helps us to develop a consistent structure. So, as we add to and develop our site, it is internally consistent, well laid out, and simple to maintain. At the start, we need to take these three common steps: Write a view page Write a stylesheet Update our config file to specify where the stylesheet is After this is done, we need to update our controller to accept parameters from the URL, and pass variables to the view. First, let's redesign our view and save it as testview.php, at /www/codeigniter/application/views/testview.php. <html><head><!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0Strict//EN'http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd'><html ><title>Web test Site</title><link rel="stylesheet" type="text/css" href="<?php echo$base."/".$css;?>"></head><body><h1><?php echo $mytitle; ?> </h1><p class='test'> <?php echo $mytext; ?> </p></body></html> It's still mostly HTML, but notice the PHP "code islands" in the highlighted lines. You'll notice that the first bits of PHP code build a link to a stylesheet. Let's save a simple stylesheet as styles.css, at www/codeigniter/css/styles.css. It just says: h1{margin: 5px;padding-left: 10px;padding-right: 10px;background: #ffffff;color: blue;width: 100%;font-size: 36px;}.test{margin: 5px;padding-left: 10px;padding-right: 10px;background: #ffffff;color: red;width: 100%;font-size: 36px;} This gives us two styles to play with, and you'll see we've used both of them in the view. Firstly, let's add an entry to the config file: $config['css'] = 'css/styles.css'; This is simply to tell the name and address of the CSS file that we've just written to the site. But note that the link to the stylesheet is referenced at $base/$css: Where do those variables, $base and $css, get their values? And come to think of it, those variables $mytitle and $mytext at the end of the code? We need a new controller! Designing a better controller Now, we need a new controller. We'll call it Start and save it as start.php, at /www/codeigniter/application/controllers/start.php. This controller has to do several things: Call a view Provide the view with the base URL and the location of the CSS file we just wrote Provide the view with some data—it's expecting a title ($mytitle) and some text ($mytext) Lastly, accept a parameter from the user (that is using the URL request) In other words, we have to populate the variables in the view. So let's start with our Start controller. This is an OO class: <?phpclass Start extends Controller{var $base;var $css; Notice that here we've declared the $base and $css (the CSS filename) as variables or class properties. This saves us from having to redeclare them if we write more than one function in each class. But you can define and use them as local variables within one function, if you prefer. The constructor function now defines the properties we've declared, by looking them up in the config file. To do this, we use the syntax: $this->config->item('name_of_config_variable'); As in: function Start(){parent::Controller();$this->base = $this->config->item('base_url');$this->css = $this->config->item('css');} CI recovers whatever we entered in the config file against that name. Using this system, no matter how many controllers and functions we write, we'll have to change these fundamental variables only once. This is true even if our site becomes so popular that we have to move it to a bigger server. Getting parameters to a function Now, within the Start controller class, let's define the function that will actually do the work. function hello($name = 'Guest'){$data['css'] = $this->css;$data['base'] = $this->base;$data['mytitle'] = 'Welcome to this site';$data['mytext'] = "Hello, $name, now we're getting dynamic!";$this->load->view('testview', $data);} This function expects the parameter $name, but you can set a default value—myfunction($myvariable = 0), which it uses to build the string assigned to the $mytext variable. Well, as we just asked, where does that come from? In this case, it needs to come from the URL request, where it will be the third parameter. So, it comes through the HTTP request: http://127.0.0.1/codeigniter/start/hello/Jose This example code doesn't "clean" the passed variable Jose, or check it in any way. You might want to do this while writing the code. We'll look at how to check form inputs. Normally, variables passed by hyperlinks in this way are generated by your own site. A malicious user can easily add his or her own, just by sending a URL such as: http://www.mysite.com/index.php/start/hello/my_malicious_variable. So, you might want to check that the variables you receive are within the range you expect, before handling them. The last segment of the URL is passed to the function as a parameter. In fact, you can add more segments of extra parameters if you like, subject to the practical limits imposed by your browser. Let's recap on how CI handles URLs, since we've covered it all now: URL segment   What it does   http://www.mysite.com   The base URL that finds your site.   /index.php   Finds the CI router that sets about reading the rest of the URL and selecting the correct route into your site. If you have added the .htaccess file in the previous chapter, this part will not be visible, but will still work as supposed.   /start   The name of the controller that CI will call (If no name is set, CI will call whichever default controller you've specified).   /hello   The name of a function that CI will call, inside the selected controller (If no function is specified, it defaults to the index function, unless you've used _remap).   /Jose   CI passes this to the function as a variable.   If there is a further URL segment, for example, /bert   CI passes this to the function as the second variable. More variables   CI will pass further URL segments as consequent variables.   Passing data to a view Let's go back to the hello function: function hello($name){$data['css'] = $this->css;$data['base'] = $this->base;$data['mytitle'] = 'Welcome to this site';$data['mytext'] = "Hello, $name, now we're getting dynamic!";$this->load->view('testview', $data);} Notice how the hello() function first creates an array called $data, taking a mixture of object properties set up by the constructor and text. Then it loads the view by name, with the array it has just built as the second parameter. Behind the scenes, CI makes good use of another PHP function—extract(). This takes each value in the $data array and turns it into a new variable in its own right. So, the $data array that we've just defined is received by the view as a series of separate variables; $text (equal to "Hello, $name, now we're getting dynamic"), $css (equal to the value from the config file), and so on. In other words, when built, the $data array looks like this: Array([css] => 'mystyles.css';[base] => 'http://127.0.0.1/packt';[mytitle] => 'Welcome to this site';[mytext] => 'Hello, fred, now we're getting dynamic!';) But on its way to the view, it is unpacked, and the following variables are created in the view to correspond to each key/value pair in the array: $css = 'mystyles.css';$base = 'http://127.0.0.1/packt';$mytitle = 'Welcome to this site';$mytext = 'Hello, fred, now we're getting dynamic!';) Although you can only pass one variable to a view, you can pack a lot of information into it. Each value in the $data array can itself be another array, so you can pass pieces of information to the view in a tightly structured manner. Now navigate to http://127.0.0.1/codeigniter/start/hello/jose (note that the URL is different—it is looking for the start function we wrote in the index controller) and you'll see the result—a dynamic page written using MVC architecture. (well, VC at least! We haven't really used the M yet). You can see that the parameter jose is the last segment of the URL. It has been passed into the function, and then to the view. Please remember that your view must be written in parallel with your controller. If the view does not expect and make a place for a variable, it won't be displayed. If the view is expecting a variable to be set and it isn't, you are likely to get an error message (your view can of course accept variables conditionally). Also, a controller can use more than one view; this way we can separate our pages into sections such as the header, the menu, and so on. Each of these views can be nested one inside the other. Child views can even inherit variables passed by the controller to their parent view. Loading a view from inside another view is very easy; just put something like this PHP snippet in your HTML code: <body><div id="menu"><?php $this->load->view('menu'); ?> This way we can load a view inside a view, with all variables in the first one also available into the nested one.

Alfresco 3 Business Solutions It is becoming more and more common that an ECM solution should include the possibility of storing e-mails in the repository, so they can be managed and searched in the same way all other content can. When we talk about managing e-mails in the content management system, it is important to know exactly what we mean by that. Today most companies and organizations want to use Alfresco for e-mail archiving, which is not something that is easily supported out of the box. E-mail integration solutions There are a number of different ways that an e-mail system can be integrated with the Alfresco CMS system. We will look at three of these and present advantages and disadvantages with each one. The three different e-mail integration solutions are: E-mail client talking directly to Alfresco via the IMAP protocol E-mail client talking to Alfresco via custom built plugin and Web Scripts E-mail server talking to Alfresco via custom module and Web Scripts E-mail client talking directly to Alfresco via the IMAP protocol This is the solution that is available out of the box with Alfresco. From version 3.2 and onwards Alfresco supports the IMAP protocol, which is one way an e-mail client can talk to e-mail servers (the other way is POP). So, with this solution Alfresco can behave like an IMAP e-mail server. The following image illustrates how this solution works: The e-mail clients typically receive an e-mail in their Inbox and then they can drag-and-drop that e-mail into an Alfresco folder via the IMAP channel. Any attachment can be extracted and handled separately to the e-mail in the Alfresco repository. This is a manual process that requires the end user to manage what e-mails he or she wants to be stored in Alfresco. Nothing happens automatically and no e-mails are stored in Alfresco unless a user manually drag-and-drops them there To achieve automatic archiving of e-mails, a user could set up an e-mail rule in their e-mail client that automatically files some or all e-mails into an Alfresco folder. However, we would still have to manually set up this rule on all users' e-mail clients. So we could not say that this would be an archiving solution that is transparent to the user, as it does not automatically force all e-mails to be saved for auditing purposes. Further on, the e-mail client has to be running in order for the e-mail rule to execute. This solution is best thought of as an e-mail management solution where users collaborate and share information in e-mails. The advantages of this solution are: No client installation:In most e-mail clients we can set up an extra IMAP account connecting to Alfresco without the need to install any extra software on the client workstation. This includes Outlook, Lotus Notes, Mozilla Thunderbird, and GroupWise. Users don't have to change working style:This is a big thing, users do not want to start learning a complete new way of managing e-mails, they just want to work in the same way they always have. The Alfresco account just shows up as another e-mail inbox in the e-mail client. Users can drag-and-drop e-mails between mailboxes just as they normally do. They do not have to learn any extra functionality. Users don't have to change working style:This is a big thing, users do not want to start learning a complete new way of managing e-mails, they just want to work in the same way they always have. The Alfresco account just shows up as another e-mail inbox in the e-mail client. Users can drag-and-drop e-mails between mailboxes just as they normally do. They do not have to learn any extra functionality. Supported out-of-the-box:No need to install any extra Alfresco modules, just configure some properties and the solution is ready to go. The disadvantages of this solution are: No document search:Users cannot search for documents in Alfresco and then attach them to an e-mail they want to send. Cannot set custom metadata:Because this solution does not use any custom plugin on the e-mail client side there is no possibility of setting custom metadata for an e-mail, such as for example customer ID, before it is stored in Alfresco. However, you can often solve this problem by creating business rules on the server-side and apply custom metadata based on which folder an e-mail is dropped into. No archiving solution:This is an e-mail collaboration and e-mail sharing solution, it does not force e-mail to be stored in the repository for compliance and regulatory reasons. Because this solution doesn't require any client installation, or updates to the Alfresco server, it will probably be the most popular e-mail management solution. It can also easily be extended with folder rules to create sophisticated e-mail filing solutions. E-mail client talking to Alfresco through custom built plugin and Web Scripts There are one or two products out there that have taken a different approach to integrating e-mail clients with Alfresco. One of these products is Anovio Email Management solution for Outlook 2007 (http://www.anovio.de/aem). This product provides a solution that enables you to also work with documents from the e-mail client, and search for documents via the e-mail client. To do this they had to implement a plugin for the e-mail client that is almost exclusively Outlook, and use Web Scripts to talk to Alfresco. The IMAP channel approach is not used as it can only handle e-mails. The following picture gives us an overview of this solution: This solution is also an e-mail management solution as it is up to the end user to actually save the e-mail into the repository. There is no automatic archiving going on. The advantages of this solution are: Document search: You can do a full text search for documents in the repository via the e-mail client. A document can then be attached to an e-mail that is about to be sent. Users don't have to change working style: Users can drag-and-drop e-mails into the Alfresco repository in a way they are used to. They do not have to use, and learn, the extra document management functionality in the Outlook plugin if they do not want to. Stores attachments directly: Attachments can be stored directly into the repository without storing the e-mail. Stores attachments directly: Attachments can be stored directly into the repository without storing the e-mail. The disadvantages of this solution are: Client installationYou can do a full text search for documents in the repository via the e-mail client. A document can then be attached to an e-mail that is about to be sent. Does not work for all e-mail clientsIt works only with certain e-mail clients, such as for example Outlook 2007, in the case of the Anovio product. Users have to learn new functionalityIf users want to handle documents from the e-mail client then they have to learn new functionality. Also, there are usually new menus and features users have to learn even for the standard e-mail management functionality. No archiving solution:This is an e-mail collaboration and sharing solution, it does not force e-mail to be stored in the repository for compliance and regulation reasons. Not supported out of the box:It is not a part of the Alfresco package, so will need to be purchased separately. This kind of solution can be very good for users that frequently need to attach documents from the Alfresco repository to e-mails that they are sending. However, if there is a larger user base, the maintenance burden could be quite substantial as you would need to install the plugin on every user's PC. E-mail server talking to Alfresco through custom module and Web Scripts This is the classical e-mail archiving solution where the e-mail system integration has been done on the e-mail server-side. This solution is totally transparent for the end users and usually complies with security regulations. What this means is that all e-mails are archived automatically without the user having to do anything, which guarantees that every incoming and outgoing e-mail has been filed and can be audited later. There are—unfortunately, at the time of writing—no such solutions available for Alfresco. But for reference purposes this is how such a solution would typically look: This solution would require us to build an extension module for the e-mail server that captures all inbound and outbound e-mails and stores them in Alfresco without the users having to do anything. So all e-mails are captured and stored for archiving and auditing purposes. Users can then for example, access the e-mails through the standard IMAP channel, if they are stored as standard MIME messages according to RFC-822 (http://tools.ietf.org/html/rfc822) The advantages of this solution are: Supports archiving and auditingThis is the only solution that would be compliant with security regulations as users are not involved, and cannot decide if an e-mail should be stored or not. Users don't have to change working styleUsers can use their standard e-mail client to view archived e-mails. The disadvantages of this solution are: Requires server installation:We need to have access to the e-mail server and be able to install the integration module. This might be challenging in many situations when you might not be allowed to install anything on the e-mail server, or the e-mail server might be hosted externally so we would not have access to it. Attachments are not extracted:The attachments would probably not be extracted and sorted into their own subfolder. This is assumed as the purpose of an e-mail archiving solution to store the complete original e-mail for auditing reasons, and not for e-mail management use. Not a collaboration and sharing solutionE-mails are stored in an archiving structure and not in a project or case structure. Users would have more difficulty in collaborating around e-mail content. Duplicate e-mails exist:There would be a lot of duplicate e-mails because of security regulations such as Sarbanes-Oxley that requires all e-mails to be stored for auditing purpose, even if it is a duplicate. Not supported out of the boxIt is not a part of the Alfresco package so will need to be purchased separately, if it is available This solution is mentioned here so we can easily tell the difference between an e-mail management solution and an e-mail archiving solution when we discuss this with potential clients. There has been a lot of misunderstanding around what e-mail integration solutions are currently available for Alfresco, where they are sometimes referred to as e-mail archiving solutions, which they are not.

(For more resources on JavaScript, see here.) So without further ado, let us get started with a lighter topic—the difference between validating and testing. The difference between validating and testing There's a thin line separating validating and testing. If you have some idea about sets (as in sets from mathematics), I would say that validation can lead to better testing results, while testing does not necessarily lead to a valid code. Let us consider the scenario—you wrote a JavaScript program and tested it on major browsers such as the Internet Explorer and Firefox; and it worked. In this case, you have tested the code to make sure that it is functional. However, the same code that you have created may or may not be valid; valid code is akin to writing a code that has the following characteristics: Well formed Has good coding style (such as proper indentation, well-commented code, properly spaced) Meets the specification of the language (in our case, JavaScript) There may come a point in time where you will notice that good coding style is highly subjective—there are various validators that may have different opinions or standards as to what is known as "good coding style". Therefore, if you do use different validators to validate your code, do not freak out if you see different advice for your coding style. This does not mean that valid code leads to code that is functional (as you will see later) and that code that is functional leads to validated code as both have different standards for comparison. However, valid code often leads to less errors, and code that is both functional and valid is often quality code. This is due to the fact that writing a piece of JavaScript code, that is both valid and correct, is much more difficult than just writing a code that is correct. Testing often means that we are trying to get the code working correctly; while validation is making sure that the code is syntactically correct, with good style and that it meets the specification of the language. While good coding styles may be subjective, there is often a coding style that is accepted by most programmers, such as, making sure that the code is properly commented, indented, and there is no pollution of the global namespace (especially in the case of JavaScript). To make the case clearer, following are three situations that you can consider: Code that is valid but wrong–validation doesn't find all the errors This form of errors would most probably be caused by logic errors in JavaScript. Logic errors can be syntactically correct but they may be logically flawed. A classic example would be an infinite for loop or infinite while loop. Code that is invalid but right This would most probably be the case for most functional code; a piece of JavaScript may be functionally correct and working, but it may be invalid. This may be due to poor coding style or any other characteristics in a valid code that are missing. Later on in this article, you will see a full working example of a piece of JavaScript code that is right but invalid. Code that is invalid and wrong–validation finds some errors that might be difficult to spot any other way In this case, the code error can be caused by all three forms of JavaScript errors that are mentioned in the article such as loading errors, runtime errors, and logic errors. While it is more likely that errors caused by syntax errors might be spotted by good validators, it is also possible that some errors are buried deep inside the code, such that it is difficult to spot them using manual methods. Now that we have some common understanding as to what validation and testing is about, let us move on to the next section which discusses the issues surrounding quality code. Code quality While there are many views as to what is quality code, I personally believe that there are a few agreed standards. Some of the most commonly mentioned standards may include code readability, ease of extension, efficiency, good coding style, and meeting language specifications, and so on. For our purpose here, we will focus on the factors that make a piece of code valid—coding style and meeting specifications. In general, good coding style almost guarantees that the code is highly readable (even to third parties) and this will help us to spot errors manually. Most importantly, having a good coding style allows us to quickly understand the code, specially if we need to work in teams or are required to debug the code on our own. You will notice that we will focus on the importance of code validity for testing purposes in later parts of the article. But now, let us start with the first building block of quality code—valid HTML and CSS. HTML and CSS needs to be valid before you start on JavaScript We have a common understanding that JavaScript breathes life into a web page by manipulating the Document Object Model (DOM) of the HTML documents. This means that the DOM must be present in the code before JavaScript can operate on it. Here's an important fact that is directly related to HTML, CSS, and browsers—browsers are generally forgiving towards invalid HTML and CSS code as compared to compilers for languages like C or Python. This is because, all browsers have to do is parse the HTML and CSS so as to render the web page for its browsers. On the other hand, compilers are generally unforgiving towards invalid code. Any missing tag, declarations, and so on will lead to a compilation error. Therefore, it is ok to write invalid or even buggy HTML and CSS, yet get a "usual" looking web page. Based on the previous explanation, we should see that we would need to have valid HTML and CSS in order to create quality JavaScript code. A short list of reasons, based on my personal experience, as to why valid HTML and CSS is an important prerequisite before you start working on JavaScript are as follows: Valid HTML and CSS helps ensure that JavaScript works as intended. For example, consider a situation where you might have two div elements that have the same id , code that is supposed to work on the above mentioned HTML element with the id. This will result in unintended consequences. Valid HTML and CSS helps improve the predictability on how your web page will work; there is no point trying to fi x buggy HTML or CSS using JavaScript. You are most probably better off if you start with valid HTML and CSS, and then apply JavaScript. Invalid HTML and CSS may result in different behaviour in different browsers. For example, an HTML tag that is not enclosed may be rendered differently in different browsers. In short, one of the most important building blocks of creating quality JavaScript code is to have valid HTML and CSS. What happens if you don't validate your code You may disagree with me on the previous section as to why HTML and CSS should be valid. In general, validation helps you to prevent errors that are related to coding style and specifications. However, do take note that using different validators may give you different results since validators might have different standards in terms of code style. In case you are wondering if invalid code can affect your JavaScript code, I would advise you to make your code as valid as possible; invalid code may lead to sticky issues such as cross-browser incompatibility, difficulty in reading code, and so on. Invalidated code means that your code may not be foolproof; in the early days of the Internet, there were websites that were dependent on the quirks of the early Netscape browser. Back track to the time where the Internet Explorer 6 was widely used, there were also many websites that worked in quirks mode to support Internet Explorer 6. Now, most browsers are supporting or are moving towards supporting web standards (though slightly different, they are supporting in subtle manners), writing valid code is one of the best ways to ensure that your website works and appears the way it is intended to. How validation can simplify testing While invalid code may not cause your code to be dysfunctional, valid code often simplifies testing. This is due to the focus on coding style and specifications; codes that are valid and have met specifications are typically more likely to be correct and much easier to debug. Consider the following code that is stylistically invalid: function checkForm(formObj){alert(formObj.id)//alert(formObj.text.value);var totalFormNumber = document.forms.length;// check if form elements are empty and are digitsvar maxCounter = formObj.length; // this is for checking for emptyvaluesalert(totalFormNumber);// check if the form is properly filled in order to proceedif(checkInput(formObj)== false){alert("Fields cannot be empty and it must be digits!");// stop executing the code since the input is invalidreturn false;}else{;}var i = 0;var formID;while(i < totalFormNumber){if(formObj == document.forms[i]){formID = i;alert(i);}i++;}if(formID<4){formID++;var formToBeChanged = document.forms[formID].id;// alert(formToBeChanged);showForm(formToBeChanged);}else{// this else statement deals with the last form// and we need to manipulate other HTML elementsdocument.getElementById("formResponse").style.visibility = "visible";}return false;} The previous code is an extreme example of poor code style, especially in terms of indentation. Imagine if you have to manually debug the second code snippet that you saw earlier! I am pretty sure that you will find it frustrating to check the code, because you will have little visual sense of what is going on. More importantly, if you are working in a team, you will be required to write legible code; in short, writing valid code typically leads to code that is more legible, easier to follow, and hence, less erroneous. Validation can help you debug your code As mentioned in the previous section, browsers are in general forgiving towards invalid HTML and CSS. While this is true, there may be errors that are not caught, or are not rendered correctly or gracefully. This means that while the invalid HTML and CSS code may appear fine on a certain platform or browser, it may not be supported on others. This means that using valid code (valid code typically means standard code set by international organizations such as W3C) will give you a much greater probability of having your web page rendered correctly on different browsers and platforms. With valid HTML and CSS, you can safely write your JavaScript code and expect it to work as intended, assuming that your JavaScript code is equally valid and error free. Validation helps you to code using good practices Valid code typically requires coding using good practices. As mentioned frequently in this article, good practices include the proper enclosing of tags, suitable indentation to enhance code readability, and so on. If you need more information about good practi ces when using JavaScript, feel free to check out the creator of JSLint, Douglas Crockford, at http://crockford.com.. Or you can read up John Resigs blog (the creator of JQuery) at http://ejohn.org. Both are great guys who know what great JavaScript is about. Validation To summarize the above sections, the DOM is provided by HTML, and both CSS and JavaScript are applied to the DOM. This means that if there is an invalid DOM, there is a chance that the JavaScript that is operating on the DOM (and sometimes the CSS) might result in errors. With this summary in mind, we'll focus on how you can spot validation errors by using color coding editors.

How to Integrate with CMS? While attempting integration of one CMS with another, some simple principles should be remembered. For all integration attempts, you have to consider the following aspects: Master-slave relationship: While integrating one CMS with the other, one of the applications act as the master and the other as the slave. If you integrate application A to application B, then application B will be considered as master. Master applications maintain authentication and sessions for both applications. While integrating Zen Cart with some other CMS, first consider whether Zen Cart will be the master or the slave. If you are integrating Zen Cart with an existing website, Zen Cart is going to be the slave. On the other hand, when you are adding blogging functionality to the Zen Cart shop by integrating WordPress with Zen Cart, Zen Cart is going to be the master. User and Group Management: One purpose of integrating two CMSs is to have a common user and group management system. Zen Cart integration may be tight, where both Zen Cart and an other CMS will use the same database for user and group management. On the other hand, loose integration will allow periodic or event-based synchronization of user or group databases. Tight integration becomes easier when both CMSs use the same type of user database. If the user databases are very different from each other, then tight integration may not be possible and some sort of fallback solution such as synchronizing the databases may be used. Visual integration: Users see the integration only through the visual integration. In fact, visual integration should be such that users will be unaware of integration attempt. While integrating the two CMSs, the visual template of the master should preferably be used for both CMSs. However, using a master's template system is difficult and a central template system should be developed which can be used for both applications. Now, we will see how to integrate Zen Cart with other CMSs. You will notice that at least one of the above-mentioned aspects is present in such integrations. Joomla!/Mambo If you are using Joomla!/Mambo and want e-commerce functionality, you have a number of choices. Among these, the best one is using the VirtueMart component. The VirtueMart component for Joomla!/Mambo is quite similar to Zen Cart or osCommerce. Only a few features of Zen Cart or osCommerce are missing in VirtueMart. However, if you still want to integrate Zen Cart into the existing Joomla!/Mambo website, you have two options-and neither is easier than the other: Use Zen Cart as a wrapper or, develop a component based on Zen Cart. Using Zen Cart as a wrapper is in its true sense not an integration. It runs separately and Joomla! provides a menu link. Clicking on this link will show Zen Cart in a wrapper window. If you are experienced with Joomla! or Mambo, you can figure out how a menu item can be added to show the application in a wrapper. However, adding a wrapper may appear to be an integration if you modify the Zen Cart template accordingly. As the Zen Cart shop appears in the wrapper, it would be wise not to use headers and sidebars in the Zen Cart template. Links to the categories and other menus can be provided in the headers. A separate login mechanism should also be provided in the Zen Cart template. Developing a bridge for Zen Cart and Joomla! is a hot topic in the Zen Cart forum. Users of both Joomla! and Zen Cart agree that integration or bridging of these two will be of great value. However, due to the framework of these two systems, developing such a bridge has some complexities and takes some time. Recently, a discussion on this topic has led to the development of such a bridge by the open-source enthusiasts. Please watch the following thread:http://tinyurl.com/65ypyu. Another possibility is JFusion plug-in for Joomla! (available at www.jfusion.org) which is a framework for integrating several forums to Joomla!. The developer of JFusion has proposed developing such a plug-in for Zen Cart as well. It is hoped that JFusion will be able to integrate Zen Cart to Joomla! soon. Drupal Drupal is a powerful CMS and is widely used. There are a wide range of modules available for Drupal and it is used for different types of websites. There are a great number of Drupal users who want to integrate Drupal and Zen Cart-as both are considered useful in their category. Until recently, there was no easy way to integrate Drupal and Zen Cart. Very recently, Zen Cart Integration module has been released as a development version. For now, it works on Drupal 5.x and Zen Cart 1.3.7. Once this module is installed and configured, you can create Zen Cart categories and products from Drupal. As other nodes, these products and categories will be displayed as nodes in Drupal. When visitors click on these products they see product details as a Drupal node, but when the product is added to cart, it redirects to the Zen Cart shop. This module also provides a single sign-on facility. For integrating Zen Cart into Drupal, download the module from http://drupal.org/project/zencart. Before we proceed with the integration of Drupal and Zen Cart, assume that you have installed Drupal and Zen Cart on the same server. Let us suppose, Drupal is installed in e:wwwdrupal57 directory and Zen Cart 1.3.7 is in e:wwwzc directory, and these two uses separate database on the same MySQL server. Follow these steps: Download and unzip Zen Cart integration module: For integrating Zen Cart into Drupal, download the module from http://drupal.org/project/zencart. On your computer, unzip the zencart-5.x-1.x-dev.tar.gz package. You will get a folder named zencart, under which there are some files and a subfolder named zencart. Copy files for Zen Cart: Inside the zencart subfolder you will find the includes folder. Copy this subfolder, that is /zencart/includes, to your Zen Cart installation directory, that is e:wwwzc. This will overwrite the e:wwwzcincludes directory, but will not overwrite any files. Once you have copied all the files in this folder, you are finished with Zen Cart. Install Zen Cart installation module in Drupal: Copy the zencart directory with all the files inside it, except the zencart subfolder, to Drupal's installation directory, that is e:wwwdrupal57. As an administrator in Drupal, you can install this module from Drupal's Administer | Site Building | Modules section. In the module list you will see the Zen Cart Integration module group. You will find the following modules in this group: Zencart-This is the main module for integrating Zen Cart shopping cart to Drupal. This is required by other modules in this group. Zencart Catalog-This module allows creation of Drupal nodes for Zen Cart products and categories. Zencart Category Node Hierarchy-This module depends on the Node Hierarchy module and organizes Zen Cart products and categories. Download the Node Hirarchy module from http://drupal.org/project/nodehierarchy and install it before enabling this module. To enable these modules, select checkboxes in Enabled column and click Save configuration button at the bottom of the list. Configure Zencart Integration module in Drupal: After enabling the modules, you can configure those from Administer | Site Configuration | Zencart Integration screen. The Zen Cart Status section will provide you information about your Zen Cart installation. The module will search and find the Zen Cart installation and show its version, path to Drupal installation and other information. The Zen Cart Settings section will give you the opportunity to mention the Zen Cart installation directory path. Type it into the Path to Zencart field. The Zen Cart Page Redirects section allows you to configure page redirects from the Zen Cart page to Drupal node. Zen Cart Catalog section allows you to configure redirect from the Zen Cart catalog items to Drupal. While using this integration module, you create Zen Cart catalog and products from Drupal. If you want to create these categories and products from inside Zen Cart and synchronize those with Drupal, then check Update product info on cron. This will synchronize product information both on Drupal and Zen Cart by running cron command on linux/unix. Checking Redirect Product Info Pages will automatically redirect visitors from the Zen Cart product info pages to equivalent Drupal nodes. Similarly, checking Redirect Category Listing Pages will automatically redirect visitors from the Zen Cart category pages to equivalent Drupal nodes. The Zen Cart Users section allows you to configure single sign-on options for Drupal and Zen Cart. If you want to allow Zen Cart existing customers to login to Drupal, then check the Allow Zen Cart Customers to login to Drupal checkbox. On the other hand, if you want to allow Drupal users to login to Zen Cart as customers, check Allow Drupal Users Customers to login to Zen Cart as Customers. Checking Allow Single Sign-On will allow users to login once and access both Drupal and Zen Cart.                                                                                                                                                                                                                                                                                                         The Zencart Integration screen has the following sections: Once you have configured these options, click the Save configuration button, or revert to defaults by clicking the Reset to defaults button. Create Content Type in Drupal for Zen Cart categories and products: If you have ever used Drupal, you know how to create content types in Drupal. You can add new content type from Administer | Content Management | Content types | Add content type. Now you will get a Zen Cart Catalog group. From this section you can define whether this type will be used as a Zen Cart product or category. You can also configure node hierarchy-ability to be parent or child (default is parent). In the Identification section, type a human readable name, for example Zen Cart Product, in the Name field. Then type a machine readable name of this content type, for example zc_product, in the Type field. Provide a description of this content type in the Description field. In the Submission Form section, provide a label for the title and body field, minimum number of words, and explanation or submission guidelines. Configure default options in the Workflow section. Finally, click the Save content type button. Create two content types—one for the Zen Cart category and another for the Zen Cart product. Add Category and Product in Drupal: You can create categories and products from Create Content section. In the list, click on Zen Cart Category. This will open Submit Zen Cart Category form. In this form, type the category name in Title field, type a description of this category in Body field. In the Node Hierarchy section, you can select a parent category. Check Category is Active to make this category visible. Configure other options like Menu settings, URL path settings, Publishing options, and so on and click the Submit button to create the category Similarly, you can create Zen Cart products by clicking on the Zen Cart Product content type. This will display the Submit Zen Cart Product form. Fill in the Submit Zen Cart Product form with appropriate information, such as product name, model, quantity in stock, tax class, base price, and so on. You can select its parent category in the Node Hierarchy section. Check the Create Menu option to make a menu item for this product. Configure other options like Menu settings, URL path settings, Publishing options, and so on and click the Submit button to create the product. Test Zen Cart Integration to and from Drupal: Now it is time to test whether the Drupal-Zen Cart integration is working or not. First, go to your Zen Cart shop, for example, http://localhost/zc. There you will find the categories and products you have added. Click on any of these, and you will be redirected to the respective Drupal node. Again, in the Drupal, click on a product link, type a quantity and click the Add to Cart button. That will redirect you to the Zen Cart shop's Your Shopping Cart Contents page. Similarly you can test single sign-on features by signing in to either Drupal or Zen Cart and trying to purchase items from these two shops. Gallery2 Gallery2 is a web-based software product that lets you manage photos on your own website. It creates a catalog of photos which visitors can view as thumbnails as well as in its original size. It has an intuitive interface to create and maintain albums. It can create thumbnails automatically and can be used for image resizing, rotation, ordering, captioning, searching, and some other functions. You can use Gallery2 to build a community site for sharing photos. You can create the community using Gallery2 and registered users can share their photographs by uploading their own photos. You need to integrate Gallery2 with Zen Cart if you want to sell photos from your photo gallery. Gallery2 has a great mechanism to integrate with Zen Cart. The Gallery2/Zen Cart integration module is available at the Gallery2 download site http://dakanji.com/g2stuff/zcg2-3_2_1a-full.zip. Using it, users can organize their photos and other multimedia files into Gallery2, and offer them for sale through Zen Cart. In integrating Gallery2 with Zen Cart, you have to configure Zen Cart first. Follow these steps for Zen Cart: Download the Gallery2/Zen Cart Integration module and extract it. Copy the zencart/includes folder into your Zen Cart installation directory. This directory contains some templates for Zen Cart. Copying these files will not overwrite any existing file. Login to your Zen Cart administration panel and create a new product category, such as Photographs. Photo items from Gallery2 will go to this category. Select Tools | Template Selection and choose one of the Gallery2 Integration templates provided. You can take a copy of the template folder (../includes/templates/pgxxx) and modify stylesheet.css. You can also modify these templates. Edit ../includes/languages/pgxxx/english.php if you want to change language strings or date formats. Replace ../includes/templates/pgxxx/images/logo.gif with your site's logo. Remember that for Gallery2/Zen Cart integration, both Zen Cart and Gallery2 data tables need to be in one database. In Gallery2, you need to make the following changes: Upload the module files in the gallery2/ directory to your Gallery2 installation's modules directory. In Gallery2 Site Administration, click on Plugins and find Zen Cart under the Commerce heading. Then click Install. After Installation, click Configure. Enter the entire server path to your Zen Cart installation, for example, /home/your_name/public_html/zencart/. Select the category you created in Zen Cart earlier (for example Photographs) from the drop-down menu. Click activate next to the Zen Cart listing on the module page. Refresh the page and click on the Zen Cart link under Admin Options to edit product details. Edit permissions for the individual items as you wish. The module will have assigned permissions to non-album items on activation. If you do not want to sell an item, you will need to disable that item in Zen Cart as the module adds all data items in your gallery to Zen Cart. You can add photograph items from Gallery2. Adding any item to the Gallery2 album will simply show that item in Zen Cart. You can add product options from Gallery2 by clicking on the Zen Cart link in your Gallery2 site administration menu. When you have installed the Gallery2/Zen Cart bridge, you will find a product type in Zen cart named Product-Gallery. All the items from Gallery2 need to be of this type. If you edit any item from Zen Cart and change the product type of any Gallery2 item, the link with the Gallery2 will be broken. Also, note that the Gallery2 bridge will co-exist with Zen Cart image handler and lightbox add-on for Zen Cart. These will handle product images for Zen Cart, whereas Gallery2 add-on only handles images added in Gallery2. You cannot assign the Main category in Zen Cart as the root product category for Gallery2. The category you are selecting in the Gallery2 bridge configuration must be a sub-category product. Once the configurations are done, you can see the photographs from Zen Cart. Visitors can also order photographs from Zen Cart. While you are in Gallery2, you can also place an order by clicking the add to cart link, which is redirected to Zen Cart. WordPress WordPress is an extremely powerful and widely used open-source blogging platform. It has a wide community of developers and users, and almost all kinds of plugins are available for it. Although there are some shopping cart plugins for WordPress, they are not full-blown shopping carts like Zen Cart or osCommerce. E-commerce plug-ins available for WordPress have limited features. Those who are running blogs using WordPress may want to integrate it with Zen Cart to provide e-commerce functionality to their blogs. In fact, there is a Zen Cart module for integrating these two. You can download that module from www.zen-cart.com. After downloading the plug-in WordPress on Zen Cart, you have to install it on the webserver. You can install the plug-in in two ways: first, in an environment where you have a working WordPress installation, and second, when you have not installed WordPress. WordPress and Zen Cart Installed in Separate Directories When you have an existing installation of WordPress, generally it will be in a separate directory from that of the Zen Cart installation. If your web document root directory is public_html, then the installation directories may be: /public_html/blog and /public_html/shop. Follow these procedures to install WordPress on Zen Cart plug-in: Step1: Install WordPress If you have not installed WordPress yet, then download the WordPress files from www.wordpress.org and unzip the files. Then, upload the files to your webserver's /public_html/blog directory. Now, change the permission of this directory to 777 and point your browser to http://yourdomain.com/blog/wp-admin/setup-config.php. The installation wizard for WordPress will be displayed. Follow the instructions on the wizard and give the necessary information. Once all of the information is given, WordPress will be installed. Step 2: Configure WordPress During installation, an administrative account will be created. Note the username and password for this account. Then, point your browser to http://yourdomain.com/blog/wp-admin/. The login page will be displayed. Type the username and password for the administrative account and click on the Login button. You will see the dashboard for administering WordPress. Go to Options | General. Now, change the Blog Address (URL) to Zen Cart's URL http://yourdomain.com/shop/. From the administration dashboard, go to Presentation | Themes and select WordPress Default 1.6. Step 3: Upload WordPress on Zen Cart When you unzip the WordPress on Zen Cart plug-in zip file, you will find that there is a directory called ZC_ROOT and WP_ROOT. Now, upload the contents of ZC_ROOT directory to Zen Cart's installation path on the server, that is, /public_html/shop/. Similarly, upload the contents of the WP_ROOT directory to WordPress' installation path, that is, /public_html/blog. Before uploading the contents of the ZC_ROOT directory, please change the name of the /ZC_ROOT/includes/templates/MY_TEMP/ directory to that of the template directory you are using for your Zen Cart shop Step 4: Edit WordPress File For older versions of WordPress, you may need to edit the /wp-include/template-loader.php file. Open the file in a text editor and replace all exit; with return;. However, you may not need this for the newer versions of WordPress. WordPress 2.3.1 can work without this modification. First, try without this modification. Step 5: Edit Zen Cart File You also need to edit another file in the Zen Cart installation. Open the /includes/extra_configures/wordpress-config.php file under the Zen Cart installation folder and find the following line: define ('ABSPATH','/var/www/vhost/example.com/public_html/blog/'); Type the appropriate WordPress path, that is, /home/username/public_html/blog/. The above line will look like this: define ('ABSPATH','/home/suhreed/public_html/blog/'); If you are trying it on Windows, you may need to put the absolute path, as in, e:/www/blog. Step 6: Configure Sideboxes from Layout Boxes Controller Once the file modifications have been done, login to the Zen Cart administration panel. Go to Tools | Layout Boxes Controller. The screen will notify you that some new sideboxes-wp_cats.php, wp_archives.php, wp_pages.php, wp_links.php, and wp_sidebar.php-have been found. To use these sidebars, click on the reset button at the bottom. To show these sideboxes on your Zen Cart shop, click on the sidebar and change its left/right column status.

  Drupal Web Services Integrate social and multimedia Web services and applications with your Drupal Web site. Explore different Web services and how they integrate with the Drupal CMS. Reuse the applications without coding them again using the Web services protocols on your Drupal site. Configure your Drupal site to consume various web services by using contributed Drupal modules for each specific task or application. Drive the content from your Drupal site to Facebook, Twitter and LinkedIn using effective Drupal Web services An easy to follow guide that opens up a method of easily sharing data and content resources between applications and machines that are running different platforms and architecture.       What are web services? In order for our Drupal site to communicate and interact with other web applications, such as Flickr, Amazon, Mollom, or Twitter, we need to use standard communication protocols in the web development world called web services. Web service protocols will allow applications that reside on external websites and servers to interact and communicate with our Drupal website that is running on our own server. Web services will also allow our Drupal site to pass along content and data to external web applications existing on remote servers. When we define web services, we need to point out that this type of communication provides for interoperability. This means that a web service communication can happen between two completely different environments but still work because we use standard protocols to make it happen. Web services allow us to call another application on a remote server. A good analogy to this is using your cell phone to call a friend or colleague. You have one type of cell phone using one type of cell phone service. You call your colleague's cell phone. They have another type of cell with a different service provider, but the call goes through and is successful because the two services communicate with each other using standard cell phone communication protocols. The web service call happens through coded protocols that are translated into a language and standard protocol that both computers can understand. Generally, this is done by using the XML language to translate the programmed request into the other external applications. Web applications have a standard in which they can usually read XML files. XML is a text-based format, so nearly all computer systems and applications can work with the XML format. The web services protocol also uses a concept called remoting or Remote Procedure Calling (RPC) that allows one application to initiate or "call" a function inside of an application on a remote server. Our Drupal site can communicate with an application on a remote server and call a function in that application. For example, we might want to make our Drupal website call and interact with our Flickr photo gallery, or we may want to take all of our Drupal home page content and push it over to our Facebook account. We can do both of these actions using the web service protocols. XML and web services As mentioned above, the base foundation for web services is a protocol or code called XML. For our Drupal site residing on our server, to talk and interact with a website or application on another server, we need to use XML, which is a language commonly understood between different applications. Our site and server understands XML as does the application we want to communicate with. We can do this over the standard HTTP protocol for website communication, as HTTP is the most standard protocol for Internet communication. The reason we use XML for communication between the applications and the sites is because XML replaces the proprietary function (whether the function is in RPC or another programming language or interface) and formats it into the standard XML code format. This allows applications to understand each other easily. An analogy to this is: if we have two people, one from Germany and the other from France, speaking to one another, and neither person knows the other's language but both of them know English, then they must speak in English, as it's a language they both understand and can easily communicate in. It's a similar situation when XML is used to translate a web service's function into a commonly understood format. So first we need to send the function call to a remote application. Our calling application or website creates the XML document that will represent the programmed function we want to execute. The XML is then transmitted over HTTP to the remote application and it can then be interpreted and understood by the remote application. The remote application then executes the function based on the XML formatting. Some examples of web service's methods are SOAP (Simple Object Access Protocol), UDDI (Universal Description, Discovery and Integration), WSDL (Web Services Description Language), XML-RPC (XML Remote Procedure Call), JSON (JavaScript Object Notation), JSON-RPC, REST (Representational State Transfer), and AMF (Action Message Format). We are not going to look at these interfaces in detail now. For now, it's helpful for us to understand that these protocols and platforms exist and that our Drupal site can provide web services to other applications via these multiple interfaces and platforms. Here's a diagram that outlines a simple web service request and response. This is a request sent from our Drupal site (client) over HTTP to an external server to request data. The data exists on the server (remote) in the form of a URI (Uniform Resource Identifier) item. The response is sent back to our Drupal site through XML. The REST protocol Let's look briefly at one web service protocol and technology, and define it. As mentioned before, there are many technologies you can use to implement web services. REST (Representational State Transfer) is one such technology. The reason REST is a preferred technology within the web development and Drupal community is due to its flexibility and standards. REST allows us to do the following when we initiate a web service using its protocol: Use a standard method such as XML as our message format Send the message over standard protocol such as HTTP Provide or connect to specific resources where each resource (image, document, page, and node) is given a unique resource identifier (a URI) We can take this concept and try it out on our Drupal site by writing some PHP code that makes an HTTP request to another web application resource. For example, we may want to make a call to a Picasa photo gallery and feed a select number and type of photos back to our Drupal site and display the photos in a Drupal node on our site. The request targets this specific resource by making a GET request to the URI of the resource. The application we are communicating with sends a response back to us in XML format. That XML can then be integrated into our Drupal site using a module, for example. The request might be made to a user's Flickr or Picasa photo gallery. The request gets returned to our Drupal site as XML and we parse this XML into our Drupal site and the user's photos or gallery then get displayed on our site. This is just one protocol example. Greg Hines of pingVision provides a good introductory resource on REST and Drupal in the document titled RESTful Web Services and Drupal. The document is available on pingVision's website as a PDF download from: http://pingvision.com/files/restful_web_services_and_drupal.pdf Standards compliance As discussed in the REST protocol's example, web services and Drupal's use of web services follow specific standards. In order to maintain as much interoperability and flexibility as possible, all of the protocols used respond for the most part using XML as the standard response mechanism and format. Additionally, all the communication between services, in our example between a client and a server, happens over HTTP (the standard web protocol). This is a uniform protocol that is used for transport and communication of the service. All transports take place uniformly using GET, POST, PUT, and DELETE requests, for example. The HTTP requests are stateless, meaning that the request over HTTP happens once at one given moment and is isolated from all other activated requests. So the request stands alone. If it succeeds, it gets a response. If it fails, it gets no response from the server or application it's communicating with. The request can be repeated an infinite number of times. Finally, all of the resources we try and access are those that we are sending to another application using a unique resource identifier (URI) to identify and define what they are. So images on our site have unique identifiers as well as those residing in another web application. Each of these unique identifiers allows for addresses or locations for each node or file in question. So each resource in a web service's communication has an address. Each resource has one URI and each address has one URI. Some examples of this would be the following locations on my Drupal site: http://variantcube.com/ http://variantcube.com/recommended-drupal-resources http://variantcube.com/node/68 http://variantcube.com/search/node/podcast http://variantcube.com/rss.xml Another reason we want to be standards compliant, when writing or working with web services, is for simplicity. We do not need any special tools to program web services as long as we follow these standards. We can use the web application modules and PHP, and stick to these coding standards and protocols. Why are web services useful? Web services are useful for a number of reasons, especially when it comes to Drupal and Drupal's relationship and interaction with other web content management systems and applications. The web has a huge number of web applications, so web developers and content developers can pass their content to the web browsers and make it available to the web visitors. This is why the Internet is useful to us. We can go to a website and view the content. Whenever we do that, we're looking at content that is proprietary to a specific web application. In Drupal, our content is in the form of nodes, for example. We may want to share these nodes with other websites that are non-Drupal, such as a Wordpress-powered site. Web services are useful because they present us with an architecture where a resource on a site (an image, textual content, such as a node ID or block ID, a video or audio file) is given a unique identifier. For example, in Drupal, every node has an ID. Every file you upload to a Drupal site also has a unique path to it. This is extremely useful since all applications share this common semantic standard. We name things similarly on all of our web applications. We can then leverage this by writing code in PHP, for example, the one that calls these resources. The application server that houses the resource then responds to our request using an XML document. Why use web services in Drupal? With web services, we can take our Drupal content and share this content with other web applications and, essentially, with the web at large. Our content is no longer just our content and it is not specific to our Drupal website. It can be shared and integrated. Drupal's codebase is PHP-based and many of the popular web applications being used today, including Wordpress, Joomla!, and Flickr, are also PHP-based. So we have a common programming language we can work with and use to integrate these applications. Here are some concrete examples. Perhaps your Human Resources Department wants to integrate its job postings and applications with another web application such as Monster.com. Web services can allow this to happen. Your office's payroll department may want to connect to its bank account in order to pass data from the payroll reports over to its bank reporting mechanism. Web services can allow this to happen. You may want to take all of the photos you upload to your Drupal site in image galleries built with the Views module, and take these photos and send them to Flickr so that they automatically show up in your Flickr account or on Flickr's public site. Web services can make this happen. This leads to another advantage of using web services with Drupal and why we would choose to use Drupal in the first place. Instead of having to upload our photos twice—once to our Drupal site and then repeating the procedure to our Flickr site—web services allows us to upload the images to our Drupal site once and then automatically send that data over to Flickr without having to upload one (or even a batch of images) again. It saves us time and speeds up the entire process of generating web-based content. Additionally, there may be applications we want to use in our Drupal site, for example applications where we want to consume content without having to code again. We can just reuse these applications using the web services protocols and get this application content into our Drupal site. So we can consume web services. Examples of this would be converting currency on our site, feeding weather reports and other weather data into our site, feeding natural disaster scientific data into our site from services that provide it, feeding language translation services, feeding music podcasts, and more. Instead of having to reprogram this type of content, we can grab it from another web application and show it automatically on our site using web services Simply put, this opens up a method of easily sharing data and content resources between applications and machines that are running on different platforms and architecture. We have opened up a gold mine of capabilities here because we can talk to applications that run different software from our Drupal site and on different computing platforms. How Drupal uses web services Drupal can use web services following any of the protocols mentioned earlier, including XML-RPC, REST, and SOAP. Drupal can consume web services by requesting data from other web applications using RSS and XML-formatted requests. As a web developer, you can write your own service code in Drupal using PHP. You can also use the Services module as well as other service-specific contributed modules to create these web service requests. In this next section, we're going to look at both these examples. First, we'll see how Drupal works as a service consumer, where basically it is a client requesting data from an external server. We'll also look at how Drupal can provide services using the Services module, RSS, AMFPHP, and XML-RPC. Drupal as a service consumer Let's outline some brief examples of how Drupal consumes content and data from other web applications, including Mollom, Flickr, and Facebook. You can configure your Drupal site to consume various web services by using contributed Drupal modules for each specific task or application you are trying to consume. Drupal can consume services from applications that will help your website prevent spam, integrate photos, integrate taxonomy and tags, and enhance your Drupal free tagging and autotagging abilities, and integrate with applications such as Facebook and Twitter.