Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required.
Arrow left icon
All Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Newsletter Hub
Free Learning
Arrow right icon
timer SALE ENDS IN
0 Days
:
00 Hours
:
00 Minutes
:
00 Seconds

How-To Tutorials - CMS & E-Commerce

830 Articles
article-image-introduction-drupal-web-services
Packt
29 Nov 2010
13 min read
Save for later

Introduction to Drupal Web Services

Packt
29 Nov 2010
13 min read
  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.
Read more
  • 0
  • 0
  • 2988

article-image-replication-alert-monitor-monitoring-management
Packt
26 Nov 2010
10 min read
Save for later

Replication Alert Monitor: Monitoring Management

Packt
26 Nov 2010
10 min read
IBM InfoSphere Replication Server and Data Event Publisher Design, implement, and monitor a successful Q replication and Event Publishing project Covers the toolsets needed to implement a successful Q replication project Aimed at the Linux, Unix, and Windows operating systems, with many concepts common to z/OS as well A chapter dedicated exclusively to WebSphere MQ for the DB2 DBA Detailed step-by-step instructions for 13 Q replication scenarios with troubleshooting and monitoring tips Written in a conversational and easy to follow manner We use the ASNMCMD command to manage a running RAM monitor. When we issue the asnmcmd command, we need to specify: The monitor server name The monitor name And then one of the following keywords: chgparms <parameters>, reinit, status, stop, qryparms, suspend, resume. Where <parameters> can be: monitor_interval=<n>, autoprune= [yn], alert_prune_limit=<n>, trace_limit=<n>, max_notifications_per_alert=<n>, max_notifications_minutes=<n>| We can issue this command from a different screen from which the monitor was started. Checking which monitors are active To check which monitors are active, we can use the ASNMCMD command with the STATUS parameter. So to check the status of the monac1 monitor on mondb, we would issue: $ asnmcmd MONITOR_SERVER=mondb MONITOR_QUAL=monac1 STATUS ASN0600I "AsnMcmd" : "" : "Initial" : Program "asnmcmd 9.1.0" is starting. ASN0520I "AsnMcmd" : "MONAC1" : "Initial" : The STATUS command response: "HoldLThread" thread is in the "is resting" state. ASN0520I "AsnMcmd" : "MONAC1" : "Initial" : The STATUS command response: "AdminThread" thread is in the "is resting" state. ASN0520I "AsnMcmd" : "MONAC1" : "Initial" : The STATUS command response: "WorkerThread" thread is in the "is resting" state. If there is nothing running, then we get the following messages: ASN0600I "AsnMcmd" : "" : "Initial" : Program "asnmcmd 9.1.0" is starting. ASN0506E "AsnMcmd" : "ASN" : "Initial" : The command was not processed. The "Monitor" program is presumed down. Note that there is a slight delay of a few seconds between the ASN0600I message and the ASN0506E message. We can check when a monitor last ran using the following query: $ db2 "SELECT SUBSTR(monitor_qual,1,10) AS monqual, last_monitor_time, start_monitor_time, end_monitor_time, lastrun, lastsuccess, status FROM asn.ibmsnap_monservers" MONQUAL LAST_MONITOR_TIME START_MONITOR_TIME MONAC1 2007-03-16-10.18.57.750000 2007-03-16-10.18.57.750000 END_MONITOR_TIME 2007-03-16-10.18.59.765000 LASTRUN LASTSUCCESS STATUS 2007-03-16-10.18.57.750000 2007-03-16-10.18.57.750000 0 Changing or reinitializing a monitor If we change any of the following while the monitor is running such as contact information, alert conditions, or parameter values: $ asnmcmd MONITOR_SERVER=mondb MONITOR_QUAL=monac1 CHGPARMS MONITOR_INTERVAL=10 Then we do not have to stop and start the monitor, we can just reinitialize it as follows: $ asnmcmd MONITOR_SERVER=mondb MONITOR_QUAL=monac1 REINIT Stopping a monitor To stop a monitor called monac1, we would issue the following command: $ asnmcmd MONITOR_SERVER=mondb MONITOR_QUAL=monac1 STOP Suspending or resuming a monitor We cannot suspend a monitor from the Replication Center, we can only use ASNCLP scripts. We can stop checking Q Capture and Q Apply for all defined alert conditions using the ASNMCMD SUSPEND command. When we want to resume monitoring again, then we issue the ASNMCMD RESUME command. Note that using the ANSMCMD command is an all or nothing approach. The SUSPEND option will suspend all monitoring qualifiers. So what happens if we just want to suspend monitoring one monitored sever (DB2A or DB2B)? In this case, we would have to create a monitor suspension. We can suspend a monitor once only or on a repeatable basis. If we want to suspend a monitor on a repeatable basis, then it's best to first create a suspension template and then create a monitor suspension. If we want to suspend a monitor server once only, then we just need to create a monitor suspension. All dates and times for monitor suspensions are based on the clock at the system where the monitor is running (MONDB). The time format is HH:MM:SS and the date format is YYYY-MM-DD. The ASNCLP command to create a monitor suspension template is: CREATE MONITOR SUSPENSION TEMPLATE <template_name> START TIME <starting_time> REPEATS occ-clause Where occ_clause can be: DAILY FOR DURATION <n> [HOURS | MINUTES] Or: WEEKLY DAY OF WEEK <day> FOR DURATION <n> [HOURS/MINUTES/DAYS] Where <day> can be Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, or Saturday. The ASNCLP command to create a monitor suspension is: CREATE MONITOR SUSPENSION <name> [FOR SERVER <server_name> | ALIAS <server_alias>] STARTING DATE <date> [USING TEMPLATE <template_name> | STARTING TIME <starting_time>] ENDING DATE <date> ENDING TIME <ending_time> So when should we use templates? We should use them: If we want to suspend more than one monitor at the same date or time. If we want to suspend a monitor on anything but a daily basis. Note that, we can specify a day of week when we create a monitor suspension template, which is not possible in the monitor suspension definition. There are eight ASNCLP commands which deal with monitor suspensions: ASNCLP command:Description:LIST MONITOR SUSPENSIONGenerates a list of suspensions on a monitor control server.ALTER MONITOR SUSPENSIONAllows us to change the following properties of a monitor suspension: • The template that is used • The start or end date for using a template • The start or end date for suspending the monitor program one timeDROP MONITOR SUSPENSIONDeletes a monitor suspension from the monitor control tables.LIST MONITOR SUSPENSION TEMPLATEGenerates a list of monitor suspension templates on a monitor control server.ALTER MONITOR SUSPENSION TEMPLATEAllows us to change the frequency and length of monitor suspensions as defined in a suspension template.DROP MONITOR SUSPENSION TEMPLATEDeletes a monitor suspension template from the monitor control tables.CREATE MONITOR SUSPENSION TEMPLATECreates a monitor suspension template.CREATE MONITOR SUSPENSIONCreates a monitor suspension. Even though we want to monitor Q replication, we need to specify SQL replication in the ASNCLP SESSION line. So let's look at the ASNCLP command to create a monitor suspension template called LUNCH which starts daily at 12:00 and lasts for one hour: ASNCLP SESSION SET TO SQL REPLICATION; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; SET SERVER MONITOR TO DB mondb; CREATE MONITOR SUSPENSION TEMPLATE lunch START TIME 12:00:00 REPEATS DAILY FOR DURATION 1 HOURS; In the preceding command, we have not specified a server on which to apply the suspension—we have only defined the monitor server where to store the metadata. We have also not specified a start and end date—only a start and end time. Once we have created a monitor suspension template, we can define a monitor suspension for a specific server (that is, source or target) and a specific date range, which uses the template we defined previously. ASNCLP SESSION SET TO SQL REPLICATION; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; SET SERVER MONITOR TO DB mondb; SET SERVER TARGET TO DB db2b; CREATE MONITOR SUSPENSION NAME s1 FOR SERVER db2b STARTING DATE 2007-03-20 USING TEMPLATE lunch ENDING DATE 2007-12-31; In the above monitor suspension code, we do not have to specify a time value, because the time value is specified in the template definition. Note that now we have to specify a server for the template to work against. We can also define a monitor suspension without making reference to a template by specifying all the information that we need (this would be the once only processing model): CREATE MONITOR SUSPENSION NAME s2 FOR SERVER db2a STARTING DATE 2007-03-20 STARTING TIME 12:00:00 ENDING DATE 2007-12-31 ENDING TIME 13:00:00 In the above monitor suspension definition we have not specified a template, so we have included the start and end dates and times. We can list our monitor suspension templates and monitor suspensions using the following ASNCLP command: ASNCLP SESSION SET TO SQL REPLICATION; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; SET SERVER MONITOR TO DB mondb; LIST MONITOR SUSPENSION TEMPLATE; LIST MONITOR SUSPENSION; This produces the following output: ==== CMD: LIST MONITOR SUSPENSION TEMPLATE; ==== TEMPLATE NAME START TIME FREQUENCY DURATION UNITS ------------------ ---------- --------- -------- ------- LUNCH 12:00:00 SUNDAY 1.0 HOURS 1 Template(s) found. ==== CMD: LIST MONITOR SUSPENSION; ==== SUSPENSION NAME SERVER NAME TEMPLATE NAME FREQUENCY DURATION ------------------ ------------------ ------------------ --------- S1 TARGET LUNCH SUNDAY 1.0 SUSPENDUNITS FIRST SUSPENSION STOP -------- ------- ------------------- ------------------- HOURS 2007-03-20-12:00:00 2007-12-31-00:00:00 1 Suspension(s) found. We can see the monitor suspension template called LUNCH, which we created and the monitor suspension S1. We can alter a monitor suspension template by using the ASNCLP command ALTER MONITOR SUSPENSION. Suppose we want to change the suspension day from Sunday to Monday, then the ASNCLP command would be: ASNCLP SESSION SET TO SQL REPLICATION; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; SET SERVER MONITOR TO DB mondb; ALTER MONITOR SUSPENSION TEMPLATE lunch; LIST MONITOR SUSPENSION TEMPLATE; To drop a monitor suspension, we would use the DROP MONITOR SUSPENSION ASNCLP command: ASNCLP SESSION SET TO SQL REPLICATION; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; SET SERVER MONITOR TO DB mondb; SET SERVER TARGET TO DB db2b; DROP MONITOR SUSPENSION s1; Dropping a monitor suspension involves running the following SQL: DELETE FROM ASN.IBMSNAP_SUSPENDS WHERE SUSPENSION_NAME = 'S1' To drop a monitor suspension template, we would use the DROP MONITOR SUSPENSION TEMPLATE ASNCLP command: ASNCLP SESSION SET TO SQL REPLICATION; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; SET SERVER MONITOR TO DB mondb; DROP MONITOR SUSPENSION TEMPLATE lunch; Dropping a monitor suspension template involves running the following SQL: DELETE FROM ASN.IBMSNAP_TEMPLATES WHERE TEMPLATE_NAME = 'LUNCH' So let's look at an example in a bidirectional scenario as shown in the following diagram: In this example, we have created four monitors to monitor Q Capture and Q Apply on each of the two servers. The monitor_qual are MONAC1, MONAA1, MONBA1, and MONBC1. The monitor_server is MONDB. If we want to perform maintenance on the DB2B database every Sunday afternoon at 16:00 for one hour, we would create a monitor suspension template as follows: ASNCLP SESSION SET TO SQL REPLICATION; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; SET SERVER MONITOR TO DB mondb; CREATE MONITOR SUSPENSION TEMPLATE tmaintbaft START TIME 16:00:00 REPEATS WEEKLY DAY OF WEEK SUNDAY FOR DURATION 1 HOURS; And then, we would create a monitor suspension as follows: ASNCLP SESSION SET TO SQL REPLICATION; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; SET SERVER MONITOR TO DB mondb; SET SERVER TARGET TO DB db2b; CREATE MONITOR SUSPENSION NAME maintbaft FOR SERVER DB2B STARTING DATE 2007-03-20 USING TEMPLATE tmaintbaft ENDING DATE 2007-12-31; The ibmsnap_alerts table The IBMSNAP_ALERTS table contains a record of all the alerts issued by the Replication Alert Monitor. The table records what alert condition occurred, at which server, and when they were detected. Some common errors in the ALERT_CODE column are: ASN5153W MONITOR "<monitor_qualifier>". The latency exceeds the threshold value for program "<program_name>". The server is "<server_name>". The schema is "<schema>". The latency is "<latency>" seconds. The threshold is "<threshold>" seconds. ASN5157W MONITOR "<monitor_qualifier>". The Q subscription "<subscription_name>" is inactive. The server is "<server_name>". The schema is "<schema>". State information: "<stateinfo>". Summary In this article we described the Replication Alert Monitor and how to monitor the Q replication setup. Further resources on this subject: Lotus Notes Domino 8: Upgrader's Guide [Book] Q Replication Components in IBM Replication Server [Article] IBM WebSphere MQ commands [Article] WebSphere MQ Sample Programs [Article] Q Subscription Maintenance in IBM Infosphere [Article]
Read more
  • 0
  • 0
  • 1533

article-image-drupal-web-services-twitter-and-drupal
Packt
26 Nov 2010
10 min read
Save for later

Drupal Web Services: Twitter and Drupal

Packt
26 Nov 2010
10 min read
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. Introduction Twitter is a popular and widely used micro-blogging application and website. You can sign up for a Twitter account and post tiny snippet-based blog entries, 140 characters or less, to your Twitter home page. You can log in to your Twitter account and post your 140 character entry into the What's happening? text area box and then click on the Tweet button to publish it. The tweet will appear on your account's home page—your default Twitter home page—and it will be shared on the main Twitter home pages of your followers. To send a tweet to another user, you can use the hash tag in front of their username in your post. So, for example, if I was going to send myself a tweet, I would add this in my text area box before adding my post: #jamesweblabs. For more on the history and functionality of Twitter, check out the Wikipedia entry at: http://en.wikipedia.org/wiki/Twitter. Twitter also has a detailed Help and support documentation section on its main site at http://support.twitter.com/.   You may want to integrate Twitter with your Drupal site, to do things such as posting all of your most recent tweets into a Drupal block that will appear on your home page. You also may want to run this block automatically via a web service integration so that the block updates automatically whenever you post a new tweet to your Twitter account. Drupal and Twitter can easily integrate through these web services by using contributed modules. In this article, we're going to install, configure, and use the Twitter module so that we can integrate our Twitter account with our Drupal user account; we can also post tweets to the sidebar block on our site. With the Twitter module, we'll also expose some of its fields to the Views module and be able to create more powerful and dynamic listings of Twitter-based content. We'll also look at other contributed modules including Tweet. The Twitter API The Twitter API and service integration with Drupal uses the REST (Representational State Transfer) API protocol and a Streaming API protocol. Twitter does state in its API documentation that the service does not offer unlimited usage. Twitter does impose limits on the number of requests and updates made to its service API. The REST service is HTTP-based and uses GET and POST requests. GET is used to retrieve data so, in our case, this will be used when our Drupal site tries to receive the latest Tweet posted to your Twitter account. POST requests are used when you submit, update, or delete node data that you have sent over to Twitter and posted as a Tweet using the Twitter module. Using REST as the protocol, the API does support various formats for data transfer including XML, JSON, RSS, and Atom. For more details on the Twitter API and how to use it, see the Twitter API documentation for developers at: http://dev.twitter.com/pages/every_developer. The Twitter module The Twitter module is available via its Drupal project page at http://drupal.org/project/twitter. The module allows for integration with Twitter's API web service. It allows you to integrate your Twitter account with your Drupal user account; post Tweets to a block in Drupal; and allows your Drupal users to post to their Twitter account using Drupal node content. Drupal Views also integrates with the module and you can create your own customized Views-based listings of Twitter content. The module gives you a default block called User Tweets and also a user profile page titled user's tweets. We'll set both of these up in the examples that follow. Integrating the Twitter module with Drupal Download the 6.x-3.0-beta2 version of the Twitter module. This is the Other release version, not the recommended release. The reason we're going to install the Other release version is that recently Twitter changed their web service API to use authentication provided by the OAuth protocol. This change happened recently, in September 2010, when Twitter redesigned their website and made other security improvements and enhancements to their API. In order to support OAuth in the integration, you need to make sure to use the 3.0-beta2 version of the Twitter module. You can download it from: http://drupal.org/project/twitter It's listed under the Other releases heading: Once downloaded, upload this Twitter module folder to your /sites/all/modules location on your web server. You also need to download the OAuth module and add that to your /sites/all/modules. OAuth is required by the Twitter module, so you must install it. The OAuth module is available at: http://drupal.org/project/oauth. Again, with this module, you need to make sure to use the other release (earlier version) of 6.x-2.02. This 2.x version is the version that works with the Twitter 3.0-beta2 module. Make sure you have the correct versions of both of these modules before uploading to your site. This is very important. If the module versions are not the ones mentioned here, you may run into errors or other issues with functionality. So, make sure to install these exact versions. Go ahead and upload both of these modules to your /sites/all/modules. Once uploaded, browse to your modules admin page and look for the OAuth and Twitter module suites under the Other modules fieldset. For OAuth, you're looking for the Oauth and the OAuth Client Test modules. Enable the OAuth module as shown in the following screenshot: Then, scroll down and look for the Twitter, Twitter actions, Twitter Post, and Twitter Signin modules. Enable all four of these modules: Save your module configuration. Registering your website with Twitter Now that we've installed the necessary modules on our Drupal site, we need to set up the Twitter side of our functionality. In order to integrate the Twitter module with the Twitter web service, you need to create two Twitter-related items. The first is a Twitter account. If you do not already have a Twitter account, you can go to twitter.com and sign up for a brand new Twitter account. Go to: https://twitter.com/ Click on the Sign Up button and then proceed through the account sign-up steps. Setting up a Twitter application Now, we need to configure a new Twitter developer application. Once you have a Twitter account, log in to your Twitter account and then go to the twitter.com/apps URL to sign up for a new developer's application on Twitter. Make sure you are signed into your Twitter account already when you go to the apps URL. Launch the apps URL from: https://twitter.com/apps This page will show you any applications you have configured in Twitter. For our site, we're going to set up a brand new application, so, click on the Register a new application hyperlink: Clicking on that link will load a Register an Application form as shown in the following screenshot. Let's fill that out with the following info: Application Name Description of application Application Website (this is the URL of your website) Organization Name Website address (again this is the URL/home domain of your website) Scroll down on the form and then complete the form by adding and completing the following fields: Application Type—make sure to select Browser here Callback URL—this is the callback URL that the Drupal Twitter module provides The Callback URL is information that is provided by your Twitter module settings inside your Drupal site. To locate the correct Callback URL to add to the application sign-up form, go to your Twitter setup configuration settings in your Drupal site by browsing to: Site configuration | Twitter setup (admin/settings/twitter). On this page, you will see the Callback URL noted at the top of the OAuth Settings fieldset. You should see something similar to this: Go back to your Twitter application sign-up form and add this Callback URL. Now, make sure the Default Access type is set to Read & Write. Finally, make sure to check the Yes, Use Twitter for login. This will allow you to authenticate your posts to your Twitter account username and password when you try to post Drupal content to your Twitter account. So, make sure that box is checked. Your app form should now look like this: Complete the reCAPTCHA field at the bottom of the form and then click on the Save button. Twitter will load a page confirming your application is successfully configured and show you your application details. This includes your Consumer key, Consumer secret, Request token URL, Access Token URL, and Authorize URL. For integration with our Drupal site, we're going to need the Consumer key and secret. Leave this app details confirmation page open and then open up your Drupal site in another browser tab. Configuring the Twitter module once you have your app setup With your Drupal site open, go back to your Twitter module configuration form in your Drupal site at the following path: admin/settings/twitter. Here, you want to copy and paste your Twitter Consumer key and secret code into the respective fields for OAuth Consumer key and OAuth Consumer secret. Also, make sure to check the box next to Import Twitter Statuses. This will allow for your Drupal site to request posts from your Twitter account and add links to these tweets on your user account page, and also in a User Tweets block in one of your site's regions. This is what allows for the total cross-pollination and integration of your Drupal site with your Twitter account. It's very powerful and flexible for running the Twitter import functionality on your site. Finally, set the Delete old statuses drop down to 1 week. This will keep your Tweets block up to date on your Drupal site and show only updated and recent tweets. Let's go ahead and do that. You should have a screen that looks like this: Go ahead and Save configuration. Now, let's check and tweak some of the other Twitter module settings before we test our posts. Click on the Post link at the top of your Twitter setup page. On this page, you can specify what content types and respective Drupal content you want to announce and post to your Twitter account. Let's make sure we check the boxes next to the Blog entry, Page, and Story types. Of course, you can enable all of your content types if you need to, but for this example, we'll just post our new blog entries over to our Twitter account. The Default format string field shows you the format of the link that will be posted over to your Twitter account announcing your new Drupal content. So, when you post a node to your Drupal site using the blog type, the post will appear on your Twitter account in the following format as a hyperlink back to your post on Drupal: New post: !title !tinyurl This will show the Drupal node title, !title, value along with a tinyurl formatted hyperlink back to your Drupal post. So, for example, the resulting post on Twitter will look like this: ·New post: Testing post to Twitter http://tinyurl.com/33jnclx — 1 hour 53 min ago Your Post screen should now look like this: Save your Post page configuration.
Read more
  • 0
  • 0
  • 3956
Visually different images

article-image-opencart-faqs
Packt
25 Nov 2010
4 min read
Save for later

OpenCart FAQs

Packt
25 Nov 2010
4 min read
OpenCart 1.4 Beginner's Guide Build and manage professional online shopping stores easily using OpenCart. Develop a professional, easy-to-use, attractive online store and shopping cart solution using OpenCart that meets today's modern e-commerce standards Easily integrate your online store with one of the more popular payment gateways like PayPal and shipping methods such as UPS and USPS Provide coupon codes, discounts, and wholesale options for your customers to increase demand on your online store With hands-on examples, step-by-step explanations, and illustrations Q: What are the system requirements for OpenCart? A: The following screenshot shows the minimum system requirements for OpenCart for installation and running without problems. You should contact your hosting provider if you are not sure whether these settings are set or not. Q: What are the methods to upload files to a web host? A: There are two common methods for uploading files to a web host: Using cPanel File Manager Utility Using an FTP Client Q: Can we run more than one store on a single OpenCart installation? A: Yes. We can run more than one store on a single OpenCart installation. Q: What are GeoZones? A: Geo Zones represent the groups of countries or smaller geo sections under these countries. A Geo Zone can include countries, states, cities, and regions depending on the type of country. OpenCart uses Geo Zones to identify shipping and tax rate price regulations for a customer's order. Here is an example: Q: What if we want to edit anything in Geo Zones? A: If we want to edit any Country and / or Zone definition in Geo Zones, we should visit System | Localisation | Zones menu in the administration pane. Q: What is SEO? A: SEO (Search Engine Optimization) is a group of processes which is applied for websites to increase their visibility in search engine results to get more qualified traffic. For an online store, it is very important to apply at least the basic SEO techniques. Q: Where can we find the new modules of OpenCart? A: www.OpenCart.com contributions and forum pages are the essential sources to find new modules and/or ask for new ones from developers. Q: What do you mean by Payment Gateway? A: A payment gateway is an online analogue of a physical credit card processing terminal that we can locate in retail shops. Its function is to process credit card information and return the results back to the store system. You can imagine the payment gateway as an element in the middle of an online store and credit card network. The software part of this service is included in OpenCart but we will have to use one of the payment gateway services. Q: What are the payment methods in OpenCart? A: The current OpenCart version supports many established payment systems, including PayPal services, Authorize.net, Moneybookers, 2Checkout, and so on, as well as basic payment options such as Cash on Delivery, Bank Transfer, Check/money order, etc. Q: In which currency is the total amount calculated? A: PayPal automatically localizes the total amount according to the PayPal owner's account currency. Q: Whats the difference between PayPal Website Payment Standard and PayPal Website Payment Pro? A: PayPal Website Payment Standard is the easiest method to implement accepting credit card payments on an online store. There are no monthly fees or setup costs charged by PayPal. PayPal Website Payment Pro is the paid PayPal solution for an online store as a payment gateway and merchant account. The biggest difference from PayPal Website Payment Standard is that customers do not leave the website for credit card processing. The credit card information is completely processed in the online store as it is the popular method of all established e-commerce websites. Q: Which of the two PayPal products is recommended? A: For a beginner OpenCart administrator who wants to use PayPal for the online store, it is recommended to get experience with the free Standard payment option and then upgrade to the Pro option.
Read more
  • 0
  • 0
  • 2233

article-image-customizing-backend-editing-typo3-templates
Packt
22 Nov 2010
11 min read
Save for later

Customizing the Backend Editing in TYPO3 Templates

Packt
22 Nov 2010
11 min read
TYPO3 Templates Create and modify templates with TypoScript and TemplaVoila Build dynamic and powerful TYPO3 templates using TypoScript, TemplaVoila, and other core technologies. Customize dynamic menus, logos, and headers using tricks you won’t find in the official documentation. Build content elements and template extensions to overhaul and improve TYPO3’s default back-end editing experience. Follow along with the step-by-step instructions to build a site from scratch using all the lessons in the book in a practical example. Updating the rich text editor While we are making life easier for the editors, we can work on one of the areas they have to spend the most time in: the Rich Text Editor (RTE). The rich text editor allows anybody editing text or content in the TYPO3 backend to add formatting and styling such as bold or italics without using special syntax or HTML, and see the results in the text area immediately. This is also known as a WYSIWYG (What You See Is What You Get) editor and we've used it in the previous chapters to edit our own content: Out of the box, TYPO3 comes with the htmlArea RTE (extension key: rtehtmlarea), and it really is a good editor to work with. The problem is that it's configured by default to fit everybody, so it doesn't really fit anybody particularly well without a little bit of modification: it has it's own classes that we probably don't actually use, toolbars that may give too many options, and it blocks some handy tags such as the embed and object tags that we need for embedded video. Luckily, the htmlArea RTE is very configurable like everything in TYPO3 and allows us to override or add to almost all of its rules. There's an entire TSref document (http://typo3.org/documentation/documentlibrary/extension-manuals/rtehtmlarea/current), so we're not going to try to cover everything that is possible. The TSref is being updated with the new releases, so I recommend checking it out if you have any questions or want to get more information on configurations that we have only glossed over or skipped. As a final note, some of the configuration properties in this section will work on other RTE options, but many are special for the htmlArea RTE. We are going to talk about the htmlArea RTE because it is already installed by default and has a lot of powerful options, but you may choose to install a different editor as an extension in the future. TYPO3 allows us to replace the RTE in the backend with TYPO3 extensions, and we might want to replace the default htmlArea RTE if we need to support older browsers or use special features like plugins for editing images. If you are using a different editor, you may need to look at its documentation for any differences in configuration. Editing the TSconfig Configuration of the RTE is done completely in the TSconfig for the user or the page. We've used the TypoScript template for frontend configuration and layout, but the TSconfig is mainly used for configuring backend modules in TYPO3 like the RTE. The rich text editor is a backend module, so we need to use the TSconfig to configure it for our editors. The TSconfig can be modified through the Page properties view on any page in the Options tab (shown in the following screenshot): Above you can see an example of the TSconfig with some of the modifications that we are going to look at for the RTE. Of course, you can edit the TSconfig on any page in the page tree that you would like, but we are going to be working on the Root page. Like templates, the TSconfig is inherited from the parent pages in the page tree, so we can modify all of the instances of the RTE in the entire site by modifying the Root page. CSS properties The first thing that we want to update in our editor is the CSS. Without special configuration, the htmlArea RTE uses its own default CSS to decide how the different options such as headings, bold, italics, and so on, look in the text area preview. We can update the TSconfig, to load our own external stylesheet for the RTE that more closely resembles our working frontend site; the editors will see the same basic styling for paragraphs and headings as the visitors and have a better idea of what their content will look like in the frontend. According to the TSref on htmlArea, the following stylesheets are applied to the contents of the editing area by default in ascending order (we'll talk about each one in a moment): The htmlarea-edited-content.css file from the current backend TYPO3 skin (contains selectors for use in the editor but not intended to be applied in the frontend) A CSS file generated from the mainStyleOverride and inlineStyle assignments Any CSS file specified by contentCSS property in the page TSConfig We don't need to worry about the first file, htmlarea-edited-content.css. The TYPO3 skin that styles everything in the backend controls it. By default, there is an extension named TYPO3 skin, and we can simply override any of the styles by using the contentCSS property that we will see in a minute. The mainStyleOverride and inlineStyle properties are controlled by the htmlArea RTE, and TYPO3 generates a CSS file based on their settings in the extension. The mainStyleOverride contains all of the default text settings including sizes and font choices. If we are using our own CSS, we will want to ignore the original styles, so we are going to use the ignoreMainStyleOverride property in our TSconfig. To ignore set this property for our RTE, we can add the following line to the TSconfig on our main page: RTE.default.ignoreMainStyleOverride = 1 The inlineStyle assignments in TYPO3 create default classes for use in the RTE. You've probably already noticed some of them as options in the style drop-downs in the editor (Frame with yellow background, Justify Center, Justify Right, and so on). If we override the inlineStyle assignments, the default classes are removed from the RTE. Of course, we don't need to eliminate these classes just to use our own, but we can do this if we are trying to clean up the RTE for other editors or want to make our own alignment styles. Finally, we can use the contentCSS property to load our own external stylesheet into the RTE. To use our own stylesheet, we will use the following code in the TSconfig to use a new stylesheet named rte.css in our editor: RTE.default.contentCSS = fileadmin/templates/css/rte.css At this point, we're all pretty used to the syntax of TypoScript, but a review might be in order. In the previous line of TypoScript, we are updating the contentCSS property in the default instances of the RTE object with the new value fileadmin/templates/css/rte.css. If you understand that line, then everything else we're about to cover will be easy to pick up. As we want to use our own CSS file and override the defaults at once, this will be the TypoScript for our TSconfig: RTE.default { contentCSS = fileadmin/templates/css/rte.css ignoreMainStyleOverride = 1 } Of course, the next thing we need to do is create our new stylesheet. We don't want to use the complete stylesheet that we are using for the frontend because it could be thousands of lines and will have a lot of formatting and page layout rules that we don't need for simple text editing. Instead, we can just copy the most important text and paragraph styles from our style.css file in the fileadmin/templates/css/ directory into a new file called rte.css. In addition, we're going to add two new classes to style.css and copy them over; we'll create a class named blue to set the font color to pure blue and a class named red to set the font color to pure red. This should be the content of our new file, rte.css: p, ul, div { color: #666; font-size: 12px; line-height: 18px; } h1 { font-size: 24px; line-height: 36px; margin-bottom: 18px; font-weight: 200; font-variant: small-caps; } h2 { margin-bottom: 18px; line-height: 18px; font-size: 18px; } h3 { font-size: 15px; line-height: 18px; } h4, h5, h6 { font-size: 12px; line-height: 18px; } ul, ol { margin: 0px 0px 18px 18px; } ul { list-style-type: circle; } ol { list-style: decimal; } td { padding: 5px; } :link, :visited { font-weight: bold; text-decoration: none; color: #036; } .blue { color: #0000ff; } .red { color: #ff0000; } With our new CSS we will notice at least a subtle difference in our RTE. In the following screenshot, we can see the original RTE on the left and the updated RTE on the right. As you can see, our text is now spaced out better and lightened to match the frontend: As we have overridden the default classes without creating any new ones, the Block style and Text style drop-downs are both empty now. In the RTE, block styles are used for the "blocks" of our content such as paragraphs and headings while the text styles are applied directly to words or pieces of text within a larger block. Put simply, if we wanted a whole paragraph to be blue, we would use the Block style drop-down, and we would use the Text style drop-down if we only wanted a single word to be blue. Both of these drop-downs use our CSS classes for styling, so we'll go ahead and create our new classes in the TSconfig. Classes properties All of the classes in our external CSS file (rte.css) are made available as soon as we declared the file with the contentCSS property. If we want to use them, we just need to associate them with a style type (paragraph, character, image, and so on) for the default RTE. If we wanted to associate the blue and red classes with text styles, for example, we would add the following to our page's TSconfig: RTE.default.classesCharacter = blue, red Before we assign the classes to a type, we should declare them in the TSconfig so they show up properly in the RTE. By declaring the classes, we can set the titles we want to show in the RTE and how we want the titles to be styled in the drop-downs. Without declarations, the styles will still show up, but the titles will just be CSS class names. We want to declare them in TSconfig with specific title to make our editors' lives easier. We can add the following code to the TSconfig to declare the classes in our RTE and set more descriptive titles that will be shown in blue or red in the drop-down menus: RTE.classes { blue { name = Blue Text value = color: blue; } red { name = Red Text value = color: red; } } We can use CSS classes for more than just the text style, of course. The table below shows all of the main ways that we can associate and use classes in the htmlArea RTE, but you can read more in the htmlArea TSref. Go ahead and try some of them out with the example TypoScript lines that are shown. RTE class properties Toolbar properties Along with what shows up inside the content of the RTE, we can modify the toolbar itself to control what editors are able to see and use. By controlling the toolbar, we can make the RTE easier for editors and make sure that the branding and styling is consistent. The table below shows some of the most useful properties we can use to alter the toolbar available to editors. We can actually go much further in editing the individual buttons of the toolbar, but this is changing enough between major releases that I recommend using the TSref as a reference for your version of the htmlArea RTE. HTML editor properties Finally, we can change the way that the RTE works with HTML. For example, the RTE uses paragraph tags (&ltp></p>) for all blocks in our text area, but we can replace this behavior with break tags (&ltbr />) if we want. The RTE also strips certain tags, and we can change that with RTE properties as well. The following table shows the most common properties that we can use in the Page TSconfig to modify the HTML in the htmlArea RTE. Even if we don't need anything else in this section; using allowTags to allow embedded video can make our editor" lives easier if we want to embed YouTube or Vimeo players in our website. All of this information is also available in the TSref for the htmlArea if you need an updated reference.
Read more
  • 0
  • 0
  • 3755

article-image-working-flexible-content-elements-typo3-templates
Packt
19 Nov 2010
17 min read
Save for later

Working with Flexible Content Elements in TYPO3 Templates

Packt
19 Nov 2010
17 min read
  TYPO3 Templates Create and modify templates with TypoScript and TemplaVoila Build dynamic and powerful TYPO3 templates using TypoScript, TemplaVoila, and other core technologies. Customize dynamic menus, logos, and headers using tricks you won’t find in the official documentation. Build content elements and template extensions to overhaul and improve TYPO3’s default back-end editing experience. Follow along with the step-by-step instructions to build a site from scratch using all the lessons in the book in a practical example.        Introducing flexible content elements I just said flexible content elements are like mini-templates, but they are actually a little more sophisticated than that. TYPO3 templates, traditionally, are just used to design the pages of your website. Well, flexible content elements are there as a way to create our own specialized types of content elements. Flexible content elements give us most of the power that we've had in the main TemplaVoila templates; the workflow and structure is almost exactly the same. We still have a data structure and a mapped object for each template, and we can still create backend layouts and preview images to help our editors. So, we already have all the raw skills we need to start creating them, but we just need a few examples of where we would want them. Creating a flexible content element really is just like creating a new content type for our sites utilizing the power of TemplaVoila. Once created, they can be embedded into any templates or even other FCEs. We can use references to link them across separate pages. We can copy them around between TYPO3 installations easily. We can even update the main template object or data structure of an FCE and watch our changes reach to every instance of that content element in our page tree. The best examples of this are going to be some of the ones we're about to build: a contact section, a div to wrap around other content elements, a multi-column element, and a custom product layout. Creating our first flexible content element The first FCE we're going to create is going to be simple enough to show us the basic workflow, but it's also a pretty handy trick so that we can add our contact information onto multiple pages using consistent formatting across our site. We're going to create a new flexible content element for our contact information using microformats (http://microformats.org/) so that Google and some browsers can read our address, phone number, and email address easier. Normally, this would require a lot of extra work to place it on multiple pages, but we can create an FCE that our editors can add to any page just like a normal content element. Building the content element Of course, the first thing that we should do is create an HTML file that we can use for our mapping. FCEs are normally mapped to a part of a complete HTML template, while page templates are mapped to the whole file. For our example, we will create one universal HTML file to hold all of our flexible content element HTML snippets called template_fce_snippets.html in the fileadmin/templates/ directory. At this point, we can create our HTML that the FCE will be based on. Like we said before, we are going to use microformats so that our contact information can be read by software more easily. To use microformats, we are just going to add some specific class names to the span and div tags around our information. If you would like to see more information about microformats, I recommend going to http://microformats.org/. For now, we can add this code into our template_fce_snippets.html file: <!DOCTYPE HTML> <html> <head> <meta charset="utf-8" /> </head> <body> <div id="contact_info_section"> <h3 id="contact_info_title">Contact Us</h3> <div class="vcard"> <div class="fn org">Example.com</div> <div class="adr"> <div class="street-address">1214 Rebekah Ave. </div> <span class="locality">Dallas</span>, <span class="region">TX</span> <span class="postal-code">75154</span> <span class="country-name">USA</span> </div> <div class="tel">(212) 555-1212</div> <a class="email" href="mailto:[email protected]">[email protected]</a> </div> </div> </body> </html> We are ready to start creating the TemplaVoila structures now, so we can go to the TemplaVoila Control Center in the backend of our installation now. We can create a new data structure by going to the Template Files tab in the control center. To create a new template object and data structure simultaneously based on our new HTML file, we need to click on the Create... link for our template file, fileadmin/templates/template_fce_snippets.html. Now we need to choose the root data element. Go ahead and choose the main div tag (circled in the following screenshot). We need to make sure we set the mapping mode to OUTER (Include tag). Due to an oddity in TemplaVoila, outer mapping is the only way to make sure that we actually keep the contact_info_section class after mapping. It may be counter-intuitive, but TemplaVoila treats root elements exactly the opposite of all other elements in its implementation of outer and inner mapping modes. Click on Set to start creating our data structure. Now that we have set the root, we can add our own fields to the FCE data structure. All of our contact information can be static, so we will just create a field for the header. Like the page templates, we will create a new field by filling the in name, field_header, at the bottom of the page as shown in following screenshot, and click on Add. Now we can fill in the form for our new field. We will set the Title to Header, and we can set the Sample Data as [Header goes here]. As we are using this as a header, we can choose Header field as our Element Preset. After we have filled out the form as shown in the following screenshot, we can click on Add to save our settings. Map the header field to the h3 tag in our HTML template and click on Set to save the mapping. We've finished creating our small content element, so we can click on the Save as button in our builder screen and save our progress. We are creating a new data structure, so we will need to fill out the CREATE Data Structure/ Template Object portion of the TemplaVoila save screen. We will give our new element an easy title, Contact Information. We also need to make sure we choose Content Element from the Template Type drop down because we are creating an FCE instead of a page template this time. Our screen should look something like shown in the following screenshot before we click on the CREATE DS / TO button: Testing our new content element We can add our element to any page the same way we've been adding text or graphic elements in the past through the Page view. Go to the main page in the backend of TYPO3 and click on the new element button (circled in the following screenshot). Added to the choices of standard or extension-based elements, we can see our own flexible content element, Contact Information [Template], listed. Go ahead and choose it to add it to the page. The next screen we see is the content editing screen where we can fill in the header for our new element: Finally, we can save our new content element and see the output on the frontend (highlighted in the following screenshot): Creating a flexible HTML wrapper As a website grows, we sometimes run into times where we would like to assign a special style to a content element or group of content elements, but there is no easy way to do this in TYPO3 without creating a new page template. All we really want to do is wrap a div tag around the group of elements we are styling with a CSS class to give them any style we need from our own stylesheets. For example, we might want to highlight a group of content elements with a color background or border. We will create a flexible content element to output a div tag with a blank class attribute that can contain normal page content elements. The FCE will have a field for the class, so our editors can fill in whatever class they need to use later. We're also keeping control over the options that editors have. They are still restricted to using CSS classes, as opposed to arbitrary style attributes, so we have not given them too much freedom. Building the content element First, we can create our HTML to which the FCE will be mapped. All we need is a div tag with a blank class attribute, so we can just add our snippet to the bottom of /fileadmin/templates/template_fce_snippets.html. We will also add some HTML comments around our new snippet so that we can always identify it in the HTML file: <!-- BEGIN HTML Wrapper --> <div class=""></div> <!-- END HTML Wrapper --> Now, we go back to the TemplaVoila module in the backend. From the Template Files tab in the TemplaVoila Control Center, click on Create... next to the file fileadmin/templates/template_fce_snippets.html label. Go ahead and choose our new div tag between the HTML comments (circled in the following screenshot) and click on Set to start creating our data structure. Again, choose OUTER (Include tag) as our mapping mode. The first field we need to create is the wrapper field for the content element. We have already set the div tag as the root element, but we still need to create a separate field to handle content elements or we won't be able to add content into our new FCE in the Page view. Like before, we can create a field by filling in the new field text area with a new name, field_wrapper, and clicking on the Add button. Now we can create the field with the following values just like we did when we added fields to our main templates. Like our page templates, we are going to use the Page-Content Elements preset because it allows us to place other content elements inside our new field: Field: field_wrapper Element Title: Wrapper Sample Data: [Content goes here] Element Preset: Page-Content Elements Once we have created and saved our new field, we can map it to the div tag by clicking on the Map button. We can use inner mapping this time because we want to keep the tag and this is not the ROOT field. The next field we need to create is the class field so that we can edit the class from the page module. Instead of an element, we are creating an attribute. To create the new field, fill in the name, field_class, at the bottom of our page and click on Add. Choose Attribute from the drop down on the left side and fill out the field values: Title: Class Sample Data: [Class field] Element Preset: Plain input field After we have created the new class attribute and saved it, we can map it to the class attribute in our div tag. If we click on the Map button for the class field, we see that we can only choose the div tag to map to; this is okay. If the div tag is grayed out or disabled, we probably need to check that the root element was set with OUTER mapping. After we click on the div tag, we are presented with a slightly different mapping screen than we have seen before. Up until now, we have been mapping tags instead of attributes, so our choice has been INNER or OUTER mode. When mapping attributes, this drop down will show any blank attributes that exist within the HTML template for that tag. If we wanted to set a relation attribute, for example, the HTML just needs to have rel="" present in the tag with or without a value. For now, we can choose ATTRIBUTE "class" (= ) from the drop down and click on the Set button to continue. We've created all of the fields we need for this small content element, so we can click on the Save as button to save our progress. We will give our new element an easy title, HTML Wrapper. We also need to make sure we choose Content Element from the Template Type drop down again. Testing our new content element We now have a data structure and template object created as a flexible content element and mapped, so we are ready to test. We can test with almost any class from our stylesheet, but we'll make it easy by adding a new class style to the bottom of our style.css file with a color background, rounded corners, and a slight shadow to highlight content: .alert { background-color: #BBCCDD; padding: 10px; -webkit-border-radius: 10px; -moz-border-radius: 10px; border-radius: 10px; box-shadow: 2px 2px 5px #888; -webkit-box-shadow: 2px 2px 5px #888; -moz-box-shadow: 2px 2px 5px #888; } As an example, we can highlight a couple of bullet lists on the Bulletlist page that the TemplaVoila wizard created. Go to the Bulletlist page in the backend of TYPO3 and choose to add a new element like we did for the Contact Information FCE. This time, choose HTML Wrapper [Template] for our new element. The next screen we see is the editing screen, and we can see that the titles we gave our data structure fields are showing up along with the different form elements we just declared. We can add elements to the wrapper here, but it's easier in the page module. Instead, we'll just set the Class field to alert to match our stylesheet, and save our new element. Finally, in the page module, we can drag elements into our new content element, and our new div tag with a class we have set in the settings will wrap around them. We can drag two of our bullet lists into the FCE: If we look at our edited page on the frontend, we can see the new CSS styling applied immediately: Creating a multi-column layout element As helpful as a wrapping div tag can be, we should start getting a little bigger with our goals. One thing that we run into all the time in the real world of site development is the need to have multi-column elements. With the rise of grid-based design and content-heavy sites, it's getting more popular to start adding two columns into the main content area under a single column article or something similar. Unfortunately, there are a lot of variations on this idea of mixing and nesting multi-column layouts, and it's not always possible or smart to create a template for every possible variation in a limited amount of time. You can easily waste all your time creating templates with a two-column element over a three-column element over a two-column element over a single-column element. I know that sounded confusing, and that's the problem. Instead, we can create a handful of useful multi-column flexible content elements that our editors can use anywhere they need to and in any order they need to. They can even nest them inside of each other if we do this right. Right now, we're going to make a quick FCE with two columns that take up roughly half of the current content area. We're just going to start by adding some basic styling to our main stylesheet, fileadmin/templates/style.css: .multi_column_element { display: inline-block; width: 100%; } #nested_column_1 { float: left; clear: left; } #nested_column_2 { float: right; clear: right; } .half { width: 49%; } As you can see above, we are using inline-block as the display setting for the entire element. If we don't set that, then the elements below it can creep up when we start using floats. For more information on CSS values like inline-block, I recommend the tutorials from w3schools.com (http://www.w3schools.com/css/). In addition, our style floats the first column, nested_column_1, to the left and clears anything to its left. The second column, nested_column_2, floats to the right and clears anything to the right of it. If we assign the class half to both columns, then they will both take up a little under 50% of the total width with a little whitespace in the middle. After we've modified the CSS, we need to update our HTML file. Once again, we'll add our new HTML code with identifying comments into our HTML template, /fileadmin/templates/template_fce_snippets.html. Go ahead and add some basic code to the main FCE HTML file to create two divs for columns: <!-- BEGIN 1/2 + 1/2 Element --><div class="multi_column_element"> <div class="nested_column half" id="nested_column_1">Column 1</div> <div class="nested_column half" id="nested_column_2">Column 2</div> </div> <!-- END 1/2 + 1/2 Element --> Now we're going to follow most of the same steps from the previous examples starting with the creation of a new data structure: From the Template Files tab in the TemplaVoila Control Center, click on Create... next to the file fileadmin/templates/template_fce_snippets.html label. Choose the main div tag that wraps around the entire HTML template as the root field. Again, we need to make sure we set the mapping mode to OUTER (Include tag). Create a new field for the first column named field_column_1. As the float is set completely in CSS, we will not refer to the columns as left or right columns here. This means we could swap the columns in CSS or assign different identifiers in the HTML without breaking our data structure. Go ahead and create our new field with these values: Field: field_column_1 Element Title: Column 1 Sample Data: [Column #1 goes here] Element Preset: Page-Content Elements Save the first field and map field_column_1 to the div tag with the ID nested_column_1. Make sure that you select inner mapping so that the classes and identifiers are left in the div tag. Create a new field for the second column with almost the same values as the first column: Field: field_column_2 Element Title: Column 2 Sample Data: [Column #2 goes here] Element Preset: Page-Content Elements Save the second column field and map it to the div tag with the ID nested_column_2 in the HTML. Click on the Save as button to save our new data structure and template object. Set the title as something memorable, Two-Column Element, before choosing Content Element as the Template Type and clicking CREATE DS / TO. As easy as that, we've just created another FCE. We can test this one on the main page of our test site by creating a new content element with our new FCE, Two-Column Element, and dragging our current blocks into either side: With two even columns, our front page should look something like this:
Read more
  • 0
  • 0
  • 3077
Unlock access to the largest independent learning library in Tech for FREE!
Get unlimited access to 7500+ expert-authored eBooks and video courses covering every tech area you can think of.
Renews at $15.99/month. Cancel anytime
article-image-drupal-6-theming-adding-and-optimizing-css-files
Packt
19 Nov 2010
8 min read
Save for later

Drupal 6 Theming: Adding and Optimizing CSS Files

Packt
19 Nov 2010
8 min read
Drupal 6 Theming Cookbook Over 100 clear step-by-step recipes to create powerful, great-looking Drupal themes Take control of the look and feel of your Drupal website Tips and tricks to get the most out of Drupal's theming system Learn how to customize existing themes and create unique themes from scratch Part of Packt's Cookbook series: Each recipe is a carefully organized sequence of instructions to complete the task as efficiently as possible Including a CSS file in a theme This recipe details the steps involved in adding a CSS file to the theme via its .info file. In this case, we will be adding a CSS file to the mytheme sub-theme which we created in the previous article. Getting ready Create a CSS file inside the theme's folder named mytheme.css and add the following example rule to it: * { color: #996633 !important; } This rule should override and change the color of all text on the page to a brownish hue. How to do it... Adding a CSS file to a theme is best accomplished via its .info file. Navigate to the theme's folder at sites/all/themes/mytheme and open the mytheme.info file in an editor. Add the following line to this file to include our CSS: stylesheets[all][] = mytheme.css If the CSS file is stored along with other stylesheets in a sub-folder named css, the syntax would include the relative path to the file as follows: stylesheets[all][] = css/mytheme.css. Once done, save the file and exit the editor. Since we have modified the .info file and introduced a new file, our changes will not take effect until the theme registry is rebuilt. Therefore, clear the Drupal cache and view the site to confirm that our new stylesheet has been included correctly. The theme should now display all text in brown. How it works... Drupal checks the .info file and notes that we have declared stylesheets using the stylesheets variable. The syntax of this variable is similar to that of an array in PHP. The all index in the syntax represents the media type as used in CSS declarations. The next screenshot displays a section of the source code of a page which confirms the inclusion of the new stylesheet, mytheme.css. We can also see that our sub-theme is including the stylesheets declared by its base theme—Garland—as well as its own stylesheets. In the preceding screenshot, we can see that Drupal references each stylesheet along with a query string. For example, mytheme.css is included as mytheme.css?e. This rather quirky suffix is a trick used by Drupal to ensure that browsers do not use stale copies of a cached CSS file while rendering our site. We can test this by clearing the Drupal cache and viewing the source code once again. Now, our stylesheets should have a different suffix— perhaps, something like mytheme.css?A—thereby tricking browsers into believing that these are different files and using them instead of their cached copies. There's more... One of the advantages of using a sub-theme is that we can easily override elements of the base theme. This includes stylesheets as well. Overriding the base theme's stylesheet If the base theme includes a stylesheet named layout.css, adding a stylesheet of the same name in the sub-theme will override the base theme's stylesheet. In other words, Drupal will include the sub-theme's stylesheet instead of that of the base theme. Enabling CSS optimization CSS optimization in Drupal is accomplished through two steps—aggregation and compression. This optimization provides a significant boost to performance both on the server as well as for the user. This recipe details the steps to be performed to enable this feature in Drupal. Getting ready CSS optimization is a requirement only when a site is ready to go live. Until such time, it is recommended that it be left switched off as CSS changes during development will not take effect unless the Drupal cache is cleared. How to do it... Optimization and other performance-related features are sequestered within admin/ settings/performance (Home | Administer | Site configuration | Performance). This performance configuration page should have a section titled Bandwidth optimizations which should contain options for CSS and Javascript optimization. Look for the setting named Optimize CSS files and set it to Enabled as in the following screenshot: Public File system As the screenshot states, the optimized CSS file is cached using Drupal's file system which needs to be set to public to ensure that the user's browser can access and download it. Therefore, it is necessary to set Download method of the Drupal file system to Public. This can be done via admin/settings/file-system (Home | Administer | Site configuration | File system). Once done, click on the Save configuration button at the bottom of the page to save our changes. How it works... Aggregation involves the collating and joining of multiple CSS files into a single stylesheet, while compression reduces the resulting file to a smaller size by trimming out unnecessary elements such as whitespace. The former helps in reducing the number of files that the server has to load and serve. The latter saves on bandwidth and time. The previous and following screenshots demonstrate CSS optimization at work. The previous screenshot is a snippet of the HTML source of a Drupal page running on a stock Garland theme. As displayed, this involves the server performing look-ups and serving eight separate CSS files—seven for all media types and a print stylesheet—for each and every page served. If this is extrapolated to sites of greater complexity, the number of files and, consequently, the server and bandwidth load, begin to take on significant proportions and can seriously impact performance. The preceding screenshot is of the same page as before with one difference—CSS optimization is now turned on. The number of CSS files has now been reduced to only two—one for all media types and the other being the print media type. These stylesheets are stored in the files folder and are cached copies. As a result, each page load now only involves the webserver serving two files instead of the previous eight. There's more... CSS optimization and other performance improvements should be used with care. When to use it CSS optimization is only necessary to improve performance on production sites. Enabling it beforehand will only hinder theme development. Enabling optimization can sometimes be handy when working on sites which are using more than 31 stylesheets—a not too infrequent occurrence on sites using a plethora of modules and an elaborate theme—as this is an upper-bound for Internet Explorer. IE will only load the first 31 stylesheets and ignore the rest. Drupal's CSS optimization feature reduces this number to one, thereby conveniently working around the issue. An alternative is to use modules such as IE CSS Optimizer (http://drupal.org/project/ie_css_optimizer). Other optimizations Other optimization settings can also be configured on the performance page. These include page caching, block caching, and JavaScript optimization. It is also worthwhile browsing the caching and performance modules that are available as contributed modules via http:// drupal.org/project/modules under the category Performance and scalability. Creating the mysite module to hold our tweaks In the course of developing our site, we will frequently come across situations where various elements of the site need to be tweaked in PHP using Drupal's APIs. While a lot of theme-specific cases can be stored in template files, certain tweaks which are theme-agnostic require that we store them in a module to ensure that they are available to all themes. This recipe covers the creation of a module to hold all these bits and pieces. Getting ready Create a folder inside sites/all named modules. This is where custom and contributed modules are usually housed. How to do it... The following list details the procedure involved in creating a module named mysite to hold our theme-agnostic customizations and other odds and ends: Create a folder inside sites/all/modules named mysite where mysite refers to the name of our site. Create a file named mysite.info within the mysite folder. Edit this file and add the following code inside: name = Mysite description = A module to hold odds and ends for mysite. core = 6.x Save the file. Create another file named mysite.module which will hold our odds and ends. Save and exit the editor. Finally, enable the module via the module administration page at admin/build/ modules (Home | Administer | Site building | Modules). How it works... Just as with themes, modules require a .info file which provides information to Drupal on compatibility, dependencies, and so on. Once Drupal ascertains that the module is compatible with the version installed, it loads the .module file of the same name and processes it accordingly. We can test if the module is working by adding a snippet such as the following: <?php /** * Implementation of hook_init(). */ function mysite_init(){ // Display a message on every page load. drupal_set_message("Welcome to MySite!"); } As the comment suggests, the preceding snippet will display a welcome message on every page load. There's more... The Drupal community routinely comes up with modules to ease the pain of development. Module builder There's a module available named Module builder which can be used to generate a skeleton of a general module. This can subsequently be populated as per our requirements. It is available at http://drupal.org/project/module_builder.
Read more
  • 0
  • 0
  • 2193

article-image-introducing-graphic-menu-typo3
Packt
16 Nov 2010
9 min read
Save for later

Introducing Graphic Menu in TYPO3

Packt
16 Nov 2010
9 min read
TYPO3 Templates Create and modify templates with TypoScript and TemplaVoila Build dynamic and powerful TYPO3 templates using TypoScript, TemplaVoila, and other core technologies. Customize dynamic menus, logos, and headers using tricks you won’t find in the official documentation. Build content elements and template extensions to overhaul and improve TYPO3’s default back-end editing experience. Follow along with the step-by-step instructions to build a site from scratch using all the lessons in the book in a practical example. Our graphical menu, GMENU, has the ability to use a TYPO3 class, GIFBUILDER, to create images on the fly. We are going to look at GIFBUILDER in depth in just a moment, but the basic idea is that GIFBUILDER can help us build complex graphics for our menus dynamically so that we can use fonts that are not be supported by all browsers, build button-like graphics, and use drop-shadows and embossing for effect. This means that we don't need to update Photoshop every time that we want to change the menu titles or replace the font, and we also don't have to learn or use Flash or JavaScript just to create flexible menu titles. We gain a lot of freedom and power with GMENU, but it does have some disadvantages compared to TMENU. Depending on our needs, we will be generating an image for every state (normal, rollover, active, and so on), for each menu item anytime we make a change. The nice thing is that TYPO3 will cache our images, so they are only generated after we make a change and reset the cache. Overall, we will use the server a little more heavily anytime we reset the cache, and our users will need to download images for each menu item. The last disadvantage is just that it is more complex than TMENU. If our frontend developers or designers have already provided us with some awesome CSS/JavaScript or Photoshop images, then we may only need a text-based menu. In return for those possible disadvantages, we will get freedom and cross-browser compatibility, so let's see what we can do before we make any decisions. Introducing GIFBUILDER GIFBUILDER is a universal object in TypoScript that uses some basic TypoScript code to generate images using the ImageMagick (or GraphicsMagick) library in PHP. Generating images with ImageMagick is normally very complex, and we would have to learn a fair amount of PHP to make anything. Using GIFBUILDER, makes it relatively easy to make these same dynamic images without learning PHP or opening Photoshop. GIFBUILDER can actually be used for any images that we would want to create in TypoScript, but we are going to be using it specifically for GMENU in this article to turn our text fields into typographic images complete with layers and effects. We are going to learn about three main objects in GIFBUILDER that will help us create our menu items: Boxes: We can layer simple boxes to make borders or button effects. Images: We can use uploaded or external image files as backgrounds or just display them as menu items. Text: Most importantly, we can use text objects to show our page titles in non-web fonts with drop-shadow or emboss effects. A complete list of the properties available to GIFBUILDER is beyond the scope of this article, and not really necessary to build most menus. If you have any problems with GIFBUILDER, you may need to check your ImageMagic configuration in the TYPO3 Install Tool. The BOX object The BOX object is one of the key TypoScript objects in GIFBUILDER. The BOX object is, like it sounds, just a simple graphical box defined by its size and color. By itself, it's not that helpful, but we can add boxes as layers to generate borders and backgrounds that will be flattened into our final generated images. We are only going to use two properties for our boxes: BOX.dimensions defines the dimensions of the box in the format x, y, w, h where x, y is the offset for the top right-corner and w, h is the width and height of the box. BOX.color defines the color of the inside of the box. Here is an example of a gray box, 400 pixels wide, 20 pixels tall, and offset 3 pixels down and to the right: lib.subMenu.1.NO { 5 = BOX 5.color = #aaaaaa 5.dimensions = 3,3,400,20 } The IMAGE object The next object we can use, IMAGE, will bring in an image for normal display or basic tiling and masking. The IMAGE object can be used for complex displays, but we are only looking at menu applications and will just look at a few options: The TEXT object Finally, we're going to look at the options for a TEXT object in GIFBUILDER. TEXT objects are used to display any text we want in GIFBUILDER, but will be mainly using them to show the title of each page as a menu item. This list of properties is much more exhaustive because this would obviously be one of the most important objects to customize when we're creating a menu using graphical text: GIFBUILDER layers We work with GIFBUILDER by creating new objects for the GIFBUILDER, designing them with properties, and layering them by number values. Each layer is stacked in ascending order (larger numbers on top), and then TYPO3 generates a final image by flattening all of the layers into one image. It sounds a little complex, but look at this example: lib.subMenu.1.NO { 5 = BOX 5.color = #aaaaaa 5.dimensions = 3,3,400,20 10 = TEXT 10.text.field = title 10.fontSize = 12 } In the example that we just saw, lib.subMenu.1.NO is our GIFBUILDER object. Although the numbers used to identify objects (5 and 10 in the example) are sometimes arbitrary in TYPO3, they are very important for GIFBUILDER because they define the ordering in layers. GIFBUILDER stacks it's subobjects from lowest number to highest. So, in the example that we just saw, TYPO3 is generating an image in a logical sequence: A gray box is defined. The dimensions of the gray box are defined to make it 400 pixels wide and 20 pixels. A text object is created on top of the gray box to show the title field of the page from the menu item. The size of the text for the title is set to 12 pixels. TYPO3 generates a flattened image of our menu item title in a gray box. Using this system, we can stack very simple objects on top of each other to draw basic buttons. GIFBUILDER properties The GIFBUILDER object will apply itself to all items in a GMENU menu. For the basic GIFBUILDER object, we are only going to look at two properties: XY defines the size of the image (width and height) backColor defines the background color for the entire image The interesting trick for XY (and some of the other dimension properties) is that it can be based on hard-coded numbers and TypoScript constants, or it can be a calculation based on the size of another item. In the following code, the size of the GIFBUILDER object is tied directly to the size of the TEXT object declared below it: 10 = TEXT 10.text.field = title XY = [10.w]+10,[10.h]+10 The references [10.w] and [10.h] read the current width and height of the object associated with 10. Then, we add 10 pixels onto each one to give ourselves a little bit of room for spacing. We'll use this technique in GMENU to make sure that our boxes and graphic objects always line up with our titles. GMENU properties The first thing that you'll probably notice going from TMENU to GMENU is that we are about to multiply the number of properties at our disposal dramatically. We've already covered the common menu properties. We're just going to cover the most basic or necessary properties in the following tables to get an idea of what we can do. If it looks intimidating, don't worry. Most of the properties are created logically and build upon our earlier knowledge. Most importantly, there's no requirement to learn all of GIFBUILDER before we start playing around. The menu object itself has just a few key properties that we need to look at: Creating our first graphic menu The first change we can accomplish is updating our main menu with a custom font and some rollover functionality. We can do that with minimum fuss, and it'll update our whole look nicely. I chose a freeware font from Larabie Fonts (http://www.larabiefonts.com) called Deftone because it'll show off GIFBUILDER, and my boss loves it. You can use any TrueType font file you would like, though. Some fonts seem to work better with ImageMagick then others, so you may need to experiment. In any case, let's start updating our menu: We need to change lib.mainMenu.1 = TMENU to lib.mainMenu.1 = GMENU to use the GMENU objects. We want a consistent height for our entire menu, so we'll enable useLargestItemY in our template: lib.mainMenu.1.useLargestItemY = 1 Let's update the normal menu state first. We won't be using the div tags around our menu items, so want to add a class to our images: lib.mainMenu.1.NO.ATagParams = class="menu-link" We can set the background color and dimensions of our menu items. We are going to use 10 for our text object, so we can go ahead and use that as part of the size calculation to make our items exactly the same width and 5 pixels taller than the text: lib.mainMenu.1.NO { backColor = #ffffff XY = [10.w],[10.h]+5 } Now we can create the TEXT object. This is our main menu, so we're just going to use the title as our text content. We're also going to use the Deftone font at a size of 36 in a classic black: lib.mainMenu.1.NO { 10 = TEXT 10.text.field = title 10.fontFile = fileadmin/templates/deftone.ttf 10.fontSize = 36 10.fontColor = #000000 10.align = left } The main menu is already looking better, but we can add some flair by tilting the text up with the angle property. Because of the angle changing the dimensions, we'll push the text down a little more by adding a 50 pixel offset to the height: lib.mainMenu.1.NO { 10.offset = 0,50 10.angle = 3 } After all of our modifications, this is what our menu should look like:
Read more
  • 0
  • 0
  • 1417

article-image-getting-started-bpm
Packt
16 Nov 2010
9 min read
Save for later

Getting Started with BPM

Packt
16 Nov 2010
9 min read
Getting Started with Oracle BPM Suite 11gR1 – A Hands-On Tutorial Learn from the experts – teach yourself Oracle BPM Suite 11g with an accelerated and hands-on learning path brought to you by Oracle BPM Suite Product Management team members Offers an accelerated learning path for the much-anticipated Oracle BPM Suite 11g release Set the stage for your BPM learning experience with a discussion into the evolution of BPM, and a comprehensive overview of the Oracle BPM Suite 11g Product Architecture Discover BPMN 2.0 modeling, simulation, and implementation Understand how Oracle uses standards like Services Component Architecture (SCA) to simplify the process of application development Describes how Oracle has unified services and events into one platform Built around an iterative tutorial, using a real-life scenario to illustrate all the key features Full of illustrations, diagrams, and tips for developing SOA applications faster, with clear step-by-step instructions and practical examples Written by Oracle BPM Suite Product Management team members           Read more about this book      (For more resources on Oracle, see here.) BPM yields high business benefits in many dimensions when adopted successfully. Thus it is prudent to be familiar, right from the start, with the essential considerations that lead to a successful BPM adoption, and conversely, the absence of which is likely to lead to failure and frustration. However, before we dive into a discussion on how we should prepare for BPM projects, a couple of clarifications are in order. First, we should point out that not all processes are business processes. A process, particularly a digital description of a process, is essentially a depiction of a sequence of activities along with applicable flow control and business logic. In digital applications such processes appear in a variety of places. Take for example a "customer information update" activity with cross-departmental scope. This may involve updating multiple back-end IT applications, and the exact update operation may differ from application to application in how much to update and in what format to communicate with the application; there may be conditions under which certain updates may or may not take place, and so on. Often, processes are used to explicitly state all the individual tasks and associated logic behind a complex activity such as this system-wide customer information update. While such a customer information update activity will be recognized as an important and essential process at a business level, its lower level details may be expressed by an information mediation process that may be of little interest to a line of business owner. Thus, the associated process is not a business process. In general, business processes will involve activities with direct relevance to the business and the process itself will typically embody all, or a significant part, of some business value-chain. Compared to the processes that guide data exchange between applications, business processes also typically engage more roles, often played by human participants, and involve complicated decision making, some of which requires sophisticated articulation of business rules; some others require live actions by the human participants. Depending on the situation, certain tasks in a business process may have to be transferred from one participant to the other. In some cases, a business task may require joint activity of several participants, as in collaboration. These behind-the-scenes, technical workflow processes that exchange data between applications and perform other integration flows in support of the business tasks are generally referred to as service orchestrations to distinguish them from core business processes. The second clarification concerns the abbreviation BPM, which is commonly used to imply Business Process Modeling, or Business Process Monitoring, or even Business Performance Management. Here we are referring to the full lifecycle of business processes of which modeling and monitoring are specific parts. Business performance management has a finance focus, and of course, business processes can feed useful information to such financial calculations. Areas of focus for successful BPM adoption Successful BPM adoption often involves changes in organizational behavior and focus, acquisition of skills in the necessary technology and tools, and implementation of suitable working practices. These practices range from planning to implementation of business processes, working with process instances, and monitoring and management of such processes, including post-implementation process improvement activities. These are areas of focus that are critical for BPM adoption success. Process-centric or process-driven organizations behave differently than others, in that their leaders are strongly committed to business process excellence, and their employees at all levels are better aware how the business conducts itself. Their processing of business transactions has clearer definition, better visibility, and end-to-end traceability. Such organizations make necessary investments in improving their existing processes and creating newer ones faster than their competition. Suitable change in organizational behavior, when warranted, is critical for successful BPM adoption. The implementation of such organizational changes concerns various aspects of organizational development, such as organizational culture, managerial actions and incentive compatibility, and is not strongly tied to a specific BPMS. Mastering adequate skills in a BPMS suitable for the scope of BPM adoption is critical for efficient and successful delivery of individual projects. BPM practice, that is, the discipline and organized activities that lead to successful BPM projects, combines BPM methodology with proper use of tools and can be seen as one of the ways an organization committed to process excellence conducts itself. This article will focus on some of the practice aspects of a BPM project. The scope of a BPM project can also vary from company to company. A BPM project may be limited to simply working on a specific process, either creating a new one or improving an existing one. We would call this a tactical project. On the other hand, a BPM project may be the starting point of a broader scoped BPM adoption that is intended to span multiple sub-organizations and is meant to include families of BPM applications. We would call this a strategic initiative. Of course, you may also be dealing with a BPM project that is one of many being executed under a bigger BPM program. Clearly, your preparation will be somewhat different depending on what type of project you are involved in. Regardless of the scope of your BPM project, an essential step in assuring project success is to identify the Critical Success Factors (CSFs) of your project. You need to also ensure that these CSFs are relevant to the key stakeholders of the project, including those who fund the project or own or use the outcome of the project. Once you know the scope of your BPM adoption, an immediate question is, do you have the right capabilities, both in type and level, to execute the chosen initiative successfully? Oracle's BPM methodology provides a BPM Capability Maturity Model framework to articulate your BPM capabilities. It groups nearly a hundred individual capabilities into eight capability domains: business and strategy, organization, governance, project process and service portfolios, architecture, information, infrastructure, and operations, administration, and management—the first half of this list focuses more on organizational aspects while latter half is more technology focused. Oracle's BPM maturity model also classifies an organization on its level of expertise within each of the capabilities (and thus within each of the capability domains) in one of five maturity levels: Ad-hoc, Opportunistic, Systematic, Managed, and Optimized. The higher the level of maturity, the higher is the ability to execute; conversely, lower levels of maturity identify areas that may require improvement. Target maturity levels for each of the capability domains depend on the scope and goals of a BPM initiative, and any gap between the required and available maturity levels for any of the capabilities, if not remedied, can be a potential source of risk adversely affecting successful execution of the BPM initiative. The following diagram shows capability types and maturity levels per Oracle's BPM methodology: Starting with the right business process Something that begins in the right way has a better chance of ending well. This is no different in the case of BPM projects. So, what process would you pick as the focus of your BPM project? In other words, what are the important process selection criteria? Processes can be characterized by the amount of complexity they exhibit in terms of their suitability for explicit representation (as this is needed for digital modeling), number of activities, amount of logic, diversity of process stakeholders, number and spread of the back end application they connect to, and the type and number of human user interfaces the process needs to support. Process complexity can also be interpreted as a cost and/or risk measure. Processes can also be classified on the basis of the business impact they are likely to make—this is a benefit measure. Thus, processes that have low cost or complexity and a high business impact or benefit are easy picks for starting BPM projects and should be assigned the highest priority. Conversely, processes with high complexity and low business impact should be given the lowest priority. Other possible combinations of process cost and benefit would have intermediate priorities. Of course, this cost-benefit analysis is useful when you have the possibility of choosing one or few processes from a larger set of possible candidate processes. In some cases certain organizational mandates may require you to consider a process which has been prioritized according to more diverse cost-benefit rankings, for example, a process that may be needed for ensuring certain legal compliance. Once a process is chosen for a BPM project, it is advisable for the program or project managers to assess BPM capability maturity of the teams involved in the project in the context of the requirements of that project. Should significant gaps be found between the as-is and the required capabilities, strategies for timely bridging of such gaps should be included as part of the project plan.
Read more
  • 0
  • 0
  • 1433

article-image-introducing-hierarchical-menu-typo3
Packt
16 Nov 2010
6 min read
Save for later

Introducing Hierarchical Menu in TYPO3

Packt
16 Nov 2010
6 min read
TYPO3 Templates Create and modify templates with TypoScript and TemplaVoila Build dynamic and powerful TYPO3 templates using TypoScript, TemplaVoila, and other core technologies. Customize dynamic menus, logos, and headers using tricks you won’t find in the official documentation. Build content elements and template extensions to overhaul and improve TYPO3’s default back-end editing experience. Follow along with the step-by-step instructions to build a site from scratch using all the lessons in the book in a practical example. Page tree concepts We are about to dive into all of the little details, but there are a few basic concepts that we need to review first. So, we're going to make sure we have a more complete definition that avoids any confusion: Page tree: Our TYPO3 page tree is all of the pages and folders that we work with. This includes the home page, about us, subpages, and even non-public items such as the storage folder in our example site. If we have a very simple website it could look like this: Home About Us Staff Level: Our page tree will almost always have pages, subpages, and pages under those. In TYPO3, these are considered levels, and they increase as you go deeper into the page tree. For example, in our extremely simple website from the example above both Home and About Us are at the base (or root) of our page tree, so they are on level 0. The staff page is underneath the About Us page in the hierarchy, so it is on level 1. If we added a page for a photo gallery of our last staff lunch as a subpage to the staff page, then it would be at level 2: Home (Level 0) About Us (Level 0) Staff (Level 1) Staff Lunch Gallery (Level 2) Rootline: TYPO3 documentation actually has a few different uses for the term "rootline", but for the menu objects it is the list of pages from your current page or level moving up to the root page. In our example above, the current rootline from the Staff Lunch Gallery is Staff Lunch Gallery | Staff| About Us Before we look at all the different kinds of menus in TYPO3 and all their little differences, we need to explore the base TypoScript object for all of them: HMENU. HMENU generates hierarchical menus, and everything related to menus in TYPO3 is controlled by it. As the base object, HMENU is the one thing that every type of menu is guaranteed to have in common. If we understand how HMENU is creating its hierarchical menu, then everything else is just styling. We can already see an example of HMENU being used in our own TypoScript template setup by looking at the menus that the TemplaVoila Wizard generated for us: ## Main Menu [Begin] lib.mainMenu = HMENU lib.mainMenu.entryLevel = 0 lib.mainMenu.wrap = <ul id="menu-area">|</ul> lib.mainMenu.1 = TMENU lib.mainMenu.1.NO { allWrap = <li class="menu-item">|</li> } ## Main Menu [End] ## Submenu [Begin] lib.subMenu = HMENU lib.subMenu.entryLevel = 1 lib.subMenu.wrap = <ul id="submenu-area">|</ul> lib.subMenu.1 = TMENU lib.subMenu.1.NO { allWrap = <li class="submenu-item">|</li> } ## Submenu [End] We can see that the wizard created two new HMENU objects, lib.mainMenu and lib.subMenu, and assigned properties for the entry level and HTML tags associated with each menu. We're about to learn what those specific properties mean, but we can already use the code from the wizard as an example of how HMENU is created and how properties are defined for it. Types of menu objects The HMENU class does not output anything directly. To generate our menus, we must define a menu object and assign properties to it. In our current menus, the TemplaVoila Wizard generated a menu object for each HMENU in the following highlighted lines: ## Main Menu [Begin] lib.mainMenu = HMENU lib.mainMenu.entryLevel = 0 lib.mainMenu.wrap = <ul id="menu-area">|</ul> lib.mainMenu.1 = TMENU lib.mainMenu.1.NO { allWrap = <li class="menu-item">|</li> } ## Main Menu [End] ## Submenu [Begin] lib.subMenu = HMENU lib.subMenu.entryLevel = 1 lib.subMenu.wrap = <ul id="submenu-area">|</ul> lib.subMenu.1 = TMENU lib.subMenu.1.NO { allWrap = <li class="submenu-item">|</li> } ## Submenu [End] There are a handful of classes for menu objects that can be used by HMENU to generate menus in TYPO3, but we are going to be concentrating on the two most powerful and flexible options: TMENU and GMENU. The TemplaVoila Wizard used TMENU in our current menu, and it is used to generate text-based menus. Menus built with TMENU output the title of each page in the menu as a text link, and then we can use HTML and CSS to add styling and layout options. Menus created with the GMENU class are considered graphic menus. We can use GMENU to dynamically generate images from our page titles so that we can use fancy fonts and effects like drop-shadow and emboss that are not supported in CSS by all browsers equally. Menu item states The menu system in TYPO3 allows us to define states for different menu options. For example, using the state definitions, we can customize the behavior of menu items when they are active or rolled over. The normal state (NO) is available and set by default, but all of the menu item states must be enabled in TYPO3 by adding code to our template like this: lib.mainMenu.1.ACT = 1. All menu objects share a common set of menu item states from the table below: HMENU properties Because HMENU is the root of all of our other menu objects, any of the properties that we learn for HMENU will be applicable to all of our menu options that we might use on future websites. I've included a list of the TypoScript properties that we are most likely to use in the TypoScript template setup, but you can see the complete list in the TSref (http://typo3.org/documentation/document-library/references/doc_core_tsref/current). If you haven't used TypoScript much, and this is too much information all at once, don't worry. It will make more sense in a few pages when we start experimenting on our own site. Then, this will serve as a great reference. As we've already witnessed in the main menu, TYPO3 sorts our menu by the order in the page tree by default. We can use this property to list fields for TYPO3 to use in the database query. For example, if we wanted to list the main menu items in reverse alphabetical order, we could call the alternativeSortingField in our template: lib.mainMenu.1 = TMENU lib.mainMenu.1.alternativeSortingField = title desc
Read more
  • 0
  • 0
  • 2563
article-image-updating-software-koha
Packt
16 Nov 2010
4 min read
Save for later

Updating Software in Koha

Packt
16 Nov 2010
4 min read
  Koha 3 Library Management System Install, configure, and maintain your Koha installation with this easy-to-follow guide A self-sufficient guide to installing and configuring Koha Take control of your libraries with Koha library management system Get a clear understanding of software maintenance, customization, and other advanced topics such as LDAP and Internationalization Written in a style that applies to all Linux flavors and Koha versions Orientation to updating software Before we can update the Koha software, let us learn about Koha's software versions and how to choose the version to upgrade to. In this section we also learn about the components of a software update, and how to install each component of the update properly. Understanding Koha's software versions To choose which new version to upgrade to, let us first understand how the Koha software is organized. Branches At any given point Koha has at least two main software branches: Stable: This branch is older and is considered stable or bug free for the most part. Only bug fixes are allowed on this branch. Development: This branch is where new features are developed. This branch is ahead of the stable branch, meaning it has all the features of the stable branch and the new features in development. Heads Both branches—stable and development have heads. A heads is the tip of the branch, pointing to the latest change made in that branch. At the time of writing of this article, there are two heads available in Koha's Git repository. 3.0.x: This is the tip of the stable branch master: This is the tip of the development branch Tags Both branches have multiple tags. Tags point to specific points in a branch's change history. For instance we see these tags related to the stable branch: v3.00.06: This is the latest stable branch v3.00.05: An earlier version of the 3.0.x branch v3.00.04: An earlier version of the 3.0.x branch v3.00.03: An earlier version of the 3.0.x branch And these tags are available for the development branch: v3.02.00-beta: This is the 3.02 branch in the beta testing stage v3.03.00-alpha: This is the 3.02 branch when released for alpha testing Choosing a version to update to We can choose to move to the head of the stable branch or the head of the development branch or to any tag in one of these branches. Here are some pointers to help you decide: On production servers, we upgrade to the latest stable tag in the stable branch To take an early look at new features being developed, switch to the alpha or beta tag in the development branch, if available If you want to take a look at the very latest version of the software, switch to head of the development branch Understanding components of software updates When bugs are fixed or new features are added in Koha, different types of files and programs can change such as these: Perl, Java script, HTML, CSS, and other types of files in kohaclone folder Tables, columns, constraints, indexes, system preferences, and other types of changes in Koha's database Indexes and properties in Zebra configuration files Directives in Koha's Apache2 configuration files An overview of the installation process To ensure that software updates are installed properly, we need to follow these steps: Download software updates: We can download updates using Git. Git automatically detects our current version and downloads updates from Koha's online repository. Switch to a specific software version: Depending on our purposes, we will choose a version that we want to upgrade to. Install Perl module prerequisites: The new version of the software may depend on new Perl modules; we will need to install these. Install the new version of Koha: We will install the new Koha version using the make utility; this process is similar to that of a fresh Koha install. Configure Apache2: The new version of the software may have an updated Apache2 configuration file. We will need to configure this new file. Upgrade the database: We will use Koha's web installer to upgrade the database to the new version. Rebuild Zebra indexes: The new software version may contain updates to Zebra configuration files. To have these changes reflected in search results, we will need to do a full rebuild of Zebra's indexes. Restart Zebra server: To load new Zebra configurations we will have to restart zebrasrv.
Read more
  • 0
  • 0
  • 2179

article-image-different-types-q-replication
Packt
16 Nov 2010
5 min read
Save for later

The different types of Q Replication

Packt
16 Nov 2010
5 min read
There are four basic types of Q replication: Unidirectional Bidirectional Peer-to-peer Event Publishing Replicating to a stored procedure or a Consistent Change Data (CCD) table are a subset of unidirectional replication. Let's look at each of these in more detail. Unidirectional replication In unidirectional replication, we can replicate all of the rows and columns of a source table or we can just replicate a subset of the rows and columns. We cannot really perform any transformation on this data. If we want to perform some sort of transformation, then we would need to replicate to a stored procedure. Replicating to a stored procedure Stored procedure replication is a subset of unidirectional replication in which the target is not a table as such, but a stored procedure, as shown in the following diagram: A stored procedure can transform the data and output the results to a target table. This target table is not known to Q Apply. These stored procedures can be written in SQL, C, or Java. Prior to DB2 9.7 the source table and the stored procedure must have the same name, and the target table name can be any name we like. Bidirectional replication In bidirectional replication, we replicate copies of tables between two servers, each of which has a copy of the table. Note that we can only set up bidirectional replication between two servers. Unlike unidirectional replication, where we can replicate a subset of rows and columns, this is not possible in bidirectional replication. The tables on both servers can have different names, but must have the same number of rows and columns. The columns must have identical column names of compatible data types. It is not possible to do any data transformation using this type of replication. Because we are updating records on both servers, it is possible that the same record will be updated at the same time on both servers. Although Q replication provides a conflict detection mechanism, we strongly advise that the driving application should be written or modified in such a way that such conflicts be avoided. The conflict detection provided by Q replication should be treated as a safety net and not the primary conflict resolution mechanism. This mechanism allows us to choose which data values are used to detect conflicts (key column values only, changed column values, or all column values) and which server should win if such a conflict is detected. The row in the losing system is rolled back and the record is written to the IBMQSNAP_EXCEPTIONS table for review. One of the related subjects to conflict detection is the concept of which server takes precedence in a conflict, or to put it more bluntly, which server is the master and which is the slave! If there is a conflict, then whichever server takes precedence will not apply changes from the other server. This ensures that the servers remain in sync. There is a more egalitarian option, which is that no server takes precedence. In this situation, rows are applied irrespective of whether or not there is a conflict, which ultimately leads to a divergence of the contents of the databases, which is not good! There are two types of bidirectional replication—the first type is where we have an active/passive setup and the second type is where we have an active/active setup. The type of replication you choose will have implications on which server is defined as the master and which as the slave and what to do if a Q subscription is inadvertently inactivated. In an active/passive setup, the passive server should be made the master. In an active/active setup, the choice of which system is the master is a decision you have to make. Peer-to-peer replication Peer-to-peer replication allows us to replicate data between two or more servers. This is different from bidirectional replication, which is only between two servers. Each server has a copy of the table (which can have a different schema and name), but must have the same number of rows and columns and these columns must have identical column names and compatible data types. It is not possible to do any data transformation using this type of replication. In peer-to-peer replication, there is no such thing as a master or slave server—each server will have the most recent copy of the table—eventually! What this means is that there will be a slight delay between the first server having a copy of the table and the last server having that copy. This is an asynchronous process, so at any one time the tables might be different, but once applications stop updating them, then the tables will converge to the most recently updated value. This type of processing means that there isn't any "manual" conflict detection as such (it is handled automatically by Q Apply), because the latest update will always win. If two applications update the same record at exactly the same time, then Q replication uses the server number allocated when the peer-to-peer environment was set up to determine the winner. This type of processing means that two columns are added to each of the tables in the Q replication environment, where the first column is a timestamp of when the row was last updated (GMT) and the second column is the machine number. These updates are performed through triggers on the tables.
Read more
  • 0
  • 0
  • 3433

article-image-kohas-web-installer-crontab-and-other-server-configurations
Packt
15 Nov 2010
6 min read
Save for later

Koha's Web Installer, Crontab, and other server configurations

Packt
15 Nov 2010
6 min read
Executing Koha's web installer In this section of the article, we will learn how to execute Koha's web installer. The web installer performs several important functions such as creating Koha's database structure or populating mandatory administrative settings. It can also populate optional settings and sample data such as MARC frameworks or patron categories. The installer is launched from the staff client interface using Koha's MySQL user and is a series of interactive steps. At the end of the process we will be able to launch Koha's staff interface and its OPAC. Understanding the web installer's functions Koha's web installer performs the following functions: Checks for the existence of Koha's database, the connectivity to the database, and if the database user has the required privilege on the Koha database. Creates Koha's database structure—its tables, relationships between tables, database constraints, and other rules. Accepts user input on important configuration questions such as Language or MARC flavor. Populates the Koha database with several mandatory administrative settings such as the default system preferences. Populates the Koha database with several optional administrative settings and sample data such as MARC bibliographic frameworks, sample libraries, or sample patron categories. Configures Koha catalog search to use Zebra or to use database indexing. Understanding how to execute the web installer Here are some important points to note about executing Koha's web installer: The web installer is launched from the staff interface. We use a MySQL database user and password to login into the installer; this user must have privileges over Koha's database. Choosing the correct MARC flavor—MARC21 or UNIMARC is very important; it is not possible to change this configuration once the database is created. If you are evaluating or testing Koha, you should choose to import most or all of the optional settings and sample data. This way you can start using Koha right away. The optional settings and sample data can be deleted or edited from Koha's staff client at any time, but this can be significant amount of work. If you have made a mistake in the configuration settings and want to start over, simply drop and recreate Koha's database from the MySQL prompt; you will be able to launch the web installer once again. Understanding optional data available for import Let us understand some of the optional setting and sample data that we can choose to install using the web installer. Settings for MARC frameworks MARC frameworks define how data is captured for different types of material. The frameworks control things such as, which MARC fields are used, which of these fields is mandatory, or which fields are under authority control. The installer has three sets of optional settings that we can import: Matching rules: Matching rules are used during import of catalog records to match incoming records to those already in the database. Further action can be taken on matched records such as overwriting old records or adding holdings records. Two matching rules are available: one matches on ISBN and other on ISSN. Fast Add framework: This framework is designed for quickly adding catalog records; it has fewer fields when compared to other frameworks. Simple MARC 21 Bibliographic frameworks: A set of bibliographic frameworks for common types of material such as books, CDs, or serials. Other data Here is a listing of data we can import under the Other data section: Authorized values: Authorized values are lists of values that control data entry into catalog fields. Here we can import lists along with sample values for fields such as collections, shelving locations, or item statuses. Currencies: A set of currencies with sample exchange rates for use in Koha's Acquisitions module. Sample patron types and categories: A set of sample patron categories such as Student, Teacher, or Staff. Patron categories are used to define rules such as membership duration; the categories are also used to define circulation policy such as loan period. Sample Label and Patron Card Data: A set of sample layouts and templates for use in Koha's label and patron card generation, and printing tool. Sample Holidays: A sample set of holidays for use in Koha's calendar. The calendar is used in Koha's circulation module to calculate due dates and fines. Default Item Types: A sample set of item types. Item types are used to define circulation policy such as loan period or fine amount. Sample Libraries: A sample set of libraries, patrons, catalog items, circulation rules are linked to libraries. Sample News Items: A set of sample news items, for display on the OPAC and the staff interface. Default messages or notices: A set of sample notices. These are used in various Koha modules, for instance the Overdue notice can be configured to be sent to patrons with overdue items. Sample Patrons: A set of patron records. Sample Z3950 servers: A sample set of Z39.50 servers such as that of the Library of Congress. These servers are used in Koha's cataloging module for copy catalog records into Koha. Executing the web installer Here are step-by-step instructions on executing the web installer: Log in using the MySQL user and password; in this article we have used the user kohaadmin. In Step 1, choose your language; you should see just one option here—en for English or fr for French. In Step 2, the installer checks the database connectivity and user privileges. In Step 3, the installer populates the database with tables before prompting the user to install basic configuration settings. Select your MARC flavor—Unimarc or MARC 21. It is important to make the right choice here. Consult with your library staff if you are unsure of what to choose. Choose to import optional data related to MARC frameworks. Choose to import other optional data such as authorized values, currencies, or patron categories. Click on Import to install the settings and sample data. Choose to use Zebra or the regular database indexing. Click on Finish to complete the execution of the web installer. Launching Koha Once the installer finishes it should automatically redirect to the staff interface: Log in using the MySQL user and you should see Koha's staff interface home page: To launch the OPAC navigate to the OPAC url and you should see a screen such as this:  
Read more
  • 0
  • 0
  • 2345
article-image-apache-roller-40-creating-theme
Packt
15 Nov 2010
11 min read
Save for later

Apache Roller 4.0: Creating a Theme

Packt
15 Nov 2010
11 min read
  Apache Roller 4.0 – Beginner's Guide A comprehensive, step-by-step guide on how to set up, customize, and market your blog using Apache Roller   Create, optimize, and maintain your own blog server using Apache Roller Incorporate multimedia content from popular web tools like YouTube, Google Maps, Twitter. and SlideShare in your posts Customize the appearance of your blog with visually appealing, powerful themes and templates Increase your blog's search engine ranking and keep track of visitors using Google Webmaster Tools         Read more about this book       For the following exercise, you'll need to download Chapter 7's support code from the book's website. Extract the chapter07.zip file's contents into a directory in your hard disk. For example, I used Ubuntu Linux in the exercise, created a chapter07 directory inside my Desktop directory, and copied the mytheme directory inside Desktop/chapter07. All the steps in the exercise are based on these assumptions. Creating a directory for your theme Every Roller theme has a directory and some required files such as weblog.vm, _day.vm, and theme.xml. The next exercise will show you how to create a directory for your new theme inside Roller's themes directory, and how to copy these required files from the support files. Time for action – creating a directory for your theme Now, I'll show you all the necessary steps to create your new theme directory inside Roller's themes directory in a Linux Ubuntu system, and then copy all the required files. If you're using Windows or any other flavor of Linux, the procedure is very similar: Go to your Roller themes directory and create a directory named mytheme: Open a terminal window, go to the themes subdirectory inside Desktop/chapter07, and type sudo cp * /usr/local/tomcat/webapps/roller/themes/mytheme to copy all the mytheme files to your Roller installation: In the end, your mytheme directory will have four files, as shown in the following screenshot: Now restart Tomcat and wait until it's running again. Then open your web browser, log into Roller, and go to the Design tab to see the Weblog Theme page: Click on the Shared Theme option and select My First Roller Theme from the drop-down listbox: Click on the Update Theme button to change your current Roller theme, and then click on the See how your blog will look with this theme link: Roller will open a new web browser tab to show you a preview of the new theme you selected: Close the preview tab and leave the Front Page: Weblog Theme page open for the next exercise. What just happened? The mytheme theme has a very basic functionality. That's because the CSS stylesheet (mystylesheet.css) is empty, so I'm going to show you how to add styles to your headings, links, and all the other elements displayed in your weblog. However, first we need to see a quick introduction to the four files that every Roller theme must have in order to run without any trouble: File Definition Tip weblog.vm Describes the main page of your weblog. In this file, you set the structure for your weblog, using macros and elements from Roller and the Velocity template language. _day.vm   Describes how to display one day's worth of entries in your weblog. Here you can configure how to display each entry's title, content, and comments, for example. You can set the font's color and size of each element, based on the CSS stylesheet definitions. mystylesheet.css Stylesheet override file that defines the CSS style code used by your weblog. Here you define all your weblog's styles, such as size and color for headings and fonts used in your posts. theme.xml Theme definition file that describes each file used in your weblog. You need to include some basic data about your theme, the stylesheet file, the weblog and _day templates, and every other file and/or resource used in your weblog. The stylesheet override file The first thing we need to do in order to change your new theme's visual appearance is edit the stylesheet override file: mystylesheet.css. We can do this in two ways: Edit the file directly from the mytheme directory inside Roller's themes directory, or use Roller's Custom Theme feature. If we use the first option, we'll need to restart Tomcat every time we make a modification to mystylesheet.css. On the other hand, if we choose the second option, we can edit the stylesheet inside Roller's admin interface and see how our changes affect our weblog's visual appearance immediately, so I'm going to show you how to use the second option. Time for action – editing the stylesheet override file It's very easy to edit the stylesheet override file for your custom theme inside Roller, and the next exercise will show you how to do it: Go to the Front Page: Weblog Theme tab in your web browser, select the Custom Theme option, click on the I want to copy the templates from an existing theme into my weblog checkbox, and click on the Update Theme button: Roller will show you the following success message: Now click on the Templates link to see a list of the templates you currently have in your custom space: Looking at the template list in the previous screenshot, there are some templates from the other custom theme and we need to remove them now. Click on the Remove link of the custom.css, mytemplate, and _css templates to delete them from your custom space, as we won't need them anymore, and they don't belong to mytheme. After removing all the unneeded files, there should be only two templates in your list: Now click on the Stylesheet link to see and start editing your mystylesheet.css file's code: As you can see, your custom stylesheet is empty. If you click on the Front Page link in Roller's menu bar, you'll see your weblog's current front page: Now click on your web browser's Back button to return to the stylesheet editing page, and add the following code to your custom stylesheet: div.dayTitle { color:brown; font-weight:bold; font-size:90%; text-transform:uppercase; border-bottom:1px dotted #666;}.entryTitle { font-weight: bold;} Your stylesheet should now contain the line beginning with /*, along with the code you've just entered: Click on the Save button to apply the changes to your stylesheet, and then select the Front Page link to see how the code you entered affects your weblog's visual appearance: If you compare the previous screenshot with the one from step 7, you'll see that the code you entered into the override stylesheet changed the way your weblog displays the day and entry titles. Now click on the Back button of your web browser to return to the stylesheet editing page, and add the following lines of code above the lines you entered in step 8: a { text-decoration: none;}a:link { color: blue; font-weight: medium;}a:visited { color: purple; font-weight: medium;}a:hover { text-decoration: underline overline;}body { font-family:"Lucida Grande", lucida, Geneva, Arial, sans-serif; background:#FFFFCC;} Your stylesheet should now look like this: Click on the Save button and then select the Front Page link to see your weblog's front page: Click on the Back button to return to your stylesheet editing page. What just happened? In the previous exercise, you edited your stylesheet override file (mystylesheet.css) to change your weblog's visual appearance. To understand what these code segments do, let's take a look at the _day template's code: <div class="dayBox"> <div class="dayTitle"> $utils.formatDate($day, "EEEE MMM dd, yyyy") </div> #foreach( $entry in $entries ) <div class="entryBox"> <p class="entryTitle">$entry.title</p> <p class="entryContent"> #if($model.permalink) $entry.displayContent #else $entry.displayContent($url.entry($entry.anchor)) #end </p> <p class="entryInfo"> Posted at <a href="$url.entry($entry.anchor)">$utils.formatDate ($entry.pubTime, "hh:mma MMM dd, yyyy")</a> by $entry.creator.userName in <span class="category">$entry.category.name</span> &nbsp;|&nbsp; #if ($utils.isUserAuthorizedToAuthor($entry.website)) <a href="$url.editEntry($entry.anchor)">Edit</a> &nbsp;|&nbsp; #end #if($entry.commentsStillAllowed || $entry.commentCount > 0) #set($link = "$url.comments($entry.anchor)" ) <a href="$link" class="commentsLink">Comments[$entry.commentCount] </a> #end </p> </div> #end</div> The lines in bold are the ones directly involved with the CSS code you entered in the exercise: <div class="dayTitle"> $utils.formatDate($day, "EEEE MMM dd, yyyy")</div> The div element represents a "division" or a section in a web page. The only code inside this division is $utils.formatDate($day, "EEEE MMM dd, yyyy"). This is a property from the $utils object used to show the date and time of each day containing one or more posts in the weblog, in the format specified by the "EEEE MMM dd, yyyy" string. The class="dayTitle" code segment indicates that this division will use the styles defined in the .dayTitle class from the stylesheet: div.dayTitle { color:brown; font-weight:bold; font-size:90%; text-transform:uppercase; border-bottom:1px dotted #666;} This CSS code indicates that every text element inside this division will be shown in brown color, in bold style, with a smaller size (90%) than the other fonts outside the division, and the text will be converted to uppercase. The last CSS element indicates that there will be a one pixel-wide, dotted grey border at the bottom of each text element (#666 is a hexadecimal color code). All this stuff means that each day in the weblog will be shown like this: Now, the next line in the _day template: <p class="entryTitle">$entry.title</p> The <p> HTML tag indicates a paragraph inside your web page, and $entry.title is the only code inside this paragraph. As we saw before, $entry.title shows the title of an entry in your weblog. The class="entryTitle" element is related to the .entryTitle code block in your stylesheet: .entryTitle { font-weight: bold;} This CSS code indicates that all the text inside the paragraph will be shown in bold. In this case, each entry's title of your weblog will be shown in bold: The rest of the bold lines in the _day template use an <a> element, known as an anchor in HTML. This element is used to display links in web pages, and is related to all the a elements in the stylesheet: a { text-decoration: none;}a:link { color: blue; font-weight: medium;}a:visited { color: purple; font-weight: medium;}a:hover { text-decoration: underline overline;} These elements define how the links in your weblog will be displayed. The first block of code indicates that the links won't have a text decoration (that is, links won't be underlined, as in most web pages), the color of each link will be blue, the font weight will be medium, and the color of visited links will be purple. The last block of code indicates that, if someone positions the mouse cursor over a link, it will be underlined and overlined. The following screenshot shows what happens when you put your mouse cursor over the date and time hyperlink created with the <a href="$url.entry($entry.anchor)">$utils.formatDate($entry.pubTime, "hh:mma MMM dd, yyyy")</a> line in the _day template: You can see the underline and overline effects from the a:hover CSS element, along with the purple color due to the a:visited CSS element. The <a href="$url.editEntry($entry.anchor)">Edit</a>  |  line from the _day template has similar effects: The last block of code we used in the previous exercise is: body { font-family:"Lucida Grande", lucida, Geneva, Arial, sans-serif; background:#FFFFCC;} In this case, the body CSS element defines the font used to display your weblog's data. There are several fonts included, to maximize browser compatibility. You can experiment with different fonts and font families to see how your changes affect your weblog's way of displaying data. Summary In this article we saw how to create a Roller theme from scratch. We also saw how to edit the mystylesheet.css stylesheet override file and how the _day.vm template uses CSS styles and Velocity code to display your weblog's data.
Read more
  • 0
  • 0
  • 1649

article-image-drupal-6-theme-engines-and-sub-themes
Packt
15 Nov 2010
8 min read
Save for later

Drupal 6: Theme Engines and Sub-themes

Packt
15 Nov 2010
8 min read
  Drupal 6 Theming Cookbook Over 100 clear step-by-step recipes to create powerful, great-looking Drupal themes Take control of the look and feel of your Drupal website Tips and tricks to get the most out of Drupal's theming system Learn how to customize existing themes and create unique themes from scratch Part of Packt's Cookbook series: Each recipe is a carefully organized sequence of instructions to complete the task as efficiently as possible         Read more about this book       (For more resources on Drupal, see here.) Introduction One of the more prevalent adages with respect to Drupal development and theming is: Do not hack core! Modules, themes, and other files which come with a stock Drupal installation should never be edited directly. In other words, we really should not need to modify anything outside the sites folder which is designed to contain all our changes and customizations. The reasoning behind this is that most, if not all, aspects of core are accessible and modifiable through a clean and non-invasive process using Drupal's APIs. Therefore, hacking core modules and themes to get things done is almost always unnecessary and ill-advised. Another reason why directly editing core modules and themes, or for that matter, even contributed modules and themes, is that whenever an upgrade of Drupal or said modules and themes takes place, we will very likely be overwriting the changes we have made, or at the very least, make the upgrade a trying exercise. With respect to themes, let us take the example of a core theme such as Garland. As previously mentioned, it is a poor practice to edit the theme directly. The Drupal way is to extend the existing core theme using a sub-theme which, by default, is more or less an identical copy. This sub-theme can then be extended further and customized by overriding elements of the base theme,such as its stylesheets, template files, template variables, and so on. In this article, we will look at the building blocks of a basic theme and then familiarize ourselves with the concept of the sub-theme and the various techniques available to extend, override and modify it according to our requirements. Understanding the anatomy of a theme Drupal themes can consist of a multitude of files each with its own purpose, format, and syntax. This recipe will introduce each of these types with an explanation of what they do. Getting ready It will be useful to navigate to the Garland folder at themes/garland to browse and view the files inside a typical, fully featured theme. Garland also uses the PHPTemplate theming engine which is the most commonly used and recommended engine across Drupal's core and contributed themes. How to do it... The following table outlines the types of files typically found inside a theme's folder and the naming conventions to be followed for some of them. Type Mandatory? Description mytheme.info Yes Configuration file which provides information to Drupal about a theme named mytheme. page.tpl.php Yes A template file which determines the layout of all Drupal pages. node.tpl.php No A template file which determines the layout of a node inside a Drupal page. block.tpl.php No A template file which determines the layout of a block. *.tpl.php No Other template files which allow the customization and styling of themable aspects of Drupal. style.css No CSS stylesheet-if this file exists, it will be automatically included in the theme. script.js No Javascript file-if this file exists, it will be automatically included in the theme. *.js No Other Javascript files which will need to be explicitly included in the .info file. favicon.ico No Shortcut icon-if this file exists, it will be automatically included in the theme unless overridden from within Drupal. logo.png No Site logo-if this file exists, it will be automatically included in the theme unless overridden from within Drupal. screenshot.png No Theme preview image-if this file exists, it will be automatically included in the theme. template.php No PHPTemplate master file where some of the more complicated and powerful tweaks and overrides occur. Perusing the contents of each of the available files will prove very useful as we go along developing our theme. How it works... When a theme is added, Drupal first parses its .info file. This file, as its extension suggests, provides information about the theme such as its name, Drupal version compatibility, regions declared, CSS stylesheets used, JavaScript files included, and so on. In other words, Drupal uses it to find out the configuration and features of a theme. The .info file also specifies the theming engine being used by the theme which, by default, is PHPTemplate. Theme engines allow theme developers to communicate with Drupal using a simpler and more convenient interface commonly via template files. A number of them also introduce their own language formats for use in these template files. Template files in PHPTemplate themes are those that use the .tpl.php extension. Unlike other engines, these files just use PHP and HTML and do not rely on any special markup languages. There's more... Other theme engines besides PHPTemplate are also available. However, only a handful of themes in Drupal's contribution repository rely on them. Other theme engine types The PHPTemplate engine is the most widely prevalent theming engine used in the Drupal ecosystem and is a part of the Drupal core package. Themes using other engines such as Smarty or Xtemplate are rare and will be structured quite differently. A list of engines can be found at http://drupal.org/project/Theme+engines. Engine-less theme The Chameleon theme which is a part of core is a theme which does not use a templating engine and relies on straight PHP to get things done. Creating a sub-theme based on a core theme This recipe details the steps involved in creating a sub-theme of an existing core theme. Getting ready Create a folder named mytheme inside sites/all/themes. This name is usually also the name of the new theme and it is best to keep things uncomplicated by not using spaces and special characters. While mytheme is suitable for the purpose of this recipe, it will be a good idea to give the theme a unique and pertinent name based on its design and use. It is also important to ensure that there are no name-conflicts with other existing core or contributed themes. How to do it... A sub-theme of a core theme can be created through the following procedure: Create a file named mytheme.info inside the mytheme folder. Edit this new file and add the following code inside it: name = Mythemedescription = My new sub-theme (CSS, phptemplate, 3-col)base theme = garlandcore = 6.xengine = phptemplatestylesheets[all][] = mytheme.css It is useful to add an informative description field as it will be visible in the theme administration page. Specifying the key characteristics of the theme can save time and effort as the administrator gets a quick overview of the design. Save the file. Create an empty CSS file named mytheme.css inside the mytheme folder. Next, visit admin/build/themes (Home | Administer | Site building | Themes) to check if our new theme is available. As the preceding screenshot attests, the theme administration page should now include our new theme—Mytheme. Enabling it should confirm that it is more or less identical to Garland and can now be extended further as per our requirements. How it works... Drupal uses the .info file to learn about our new sub-theme. The name and description variables, rather unsurprisingly, represent the name of the theme and a description that customarily includes details about the layout of the theme. The base theme variable denotes the parent theme which our sub-theme is based on. By using this variable, we are informing Drupal that it should use the layout and styling of the base theme—in this case Garland—unless we indicate otherwise. This process is commonly referred to as overriding the base theme. Finally, the core variable denotes the compatibility of our theme with Drupal 6, while engine indicates that the theme uses PHPTemplate as its templating engine. PHPTemplate is the most widely used system. Other engines, which include Smarty, PHPTal, and Xtemplate, are seldom used and themes using them are few and far between. The stylesheets variable declares the CSS stylesheets to be included with the theme. When it comes to sub-themes, the stylesheets of base themes are automatically included unless explicitly overridden. However, due to a quirk in Drupal's theming system, base theme stylesheets are not inherited by the sub-theme unless the latter declares at least one stylesheet of its own. We have worked around this by including an empty stylesheet named mytheme.css. There's more... Drupal core provides an excellent example of a sub-theme based on a core theme. Garland and Minnelli Garland already has a sub-theme named Minnelli which is in a folder titled minnelli inside themes/garland. The difference between the two is that Garland uses a fluid layout while Minnelli is a fixed-width version of the same theme. Chaining Sub-themes can be chained, if necessary. For example, our mytheme could have used Minnelli as the base theme even though it is a sub-theme itself.
Read more
  • 0
  • 0
  • 1360