- Shopping Bag ( 0 items )
WordPress 24-Hour Trainer, 3rd Edition provides a comprehensive, unique book-and-video package that focuses on the practical, everyday tasks you will face when creating and maintaining WordPress websites. This easy-to-use, friendly guide will show you how to create and edit pages, integrate your site with social media, keep your site secure, make content more search engine friendly ...
WordPress 24-Hour Trainer, 3rd Edition provides a comprehensive, unique book-and-video package that focuses on the practical, everyday tasks you will face when creating and maintaining WordPress websites. This easy-to-use, friendly guide will show you how to create and edit pages, integrate your site with social media, keep your site secure, make content more search engine friendly to help drive website traffic, troubleshoot the most common WordPress issues, and much more.
This updated edition of WordPress 24-Hour Trainer covers the latest features of WordPress 4.0 and 4.1 in an easy-to-use format:
WordPress 24-Hour Trainer, 3rd Edition is your perfect real-world guide to fully leveraging this powerful platform.
WordPress provides you with the tools to organize your website content, but those tools function in specific ways, just as one type of word processing software has its specific buttons for creating, say, lists. But there's a difference between knowing which button to press to create a list and thinking about ways you can use lists in your documents. That's what this lesson is about: learning to think like WordPress so that you can organize your content in an efficient and flexible manner right from the start, and be able to use it in new and useful ways later.
DYNAMIC VS. STATIC WEBSITES
When you open a website in your browser, you see a single page filled with text and media (graphics, photos, video, and so on), as a page in a magazine or newspaper is a single entity made up of text and images. But what you see in a browser window is created from a series of instructions: the HTML code. So ultimately, the HTML is the single entity behind what you see onscreen: the equivalent of the printed page.
However, there's an important difference between an HTML page and a printed page. The HTML that's fed to your browser may be a single entity when it arrives at the browser, but it may or may not be a single entity sitting on the server waiting for browsers to retrieve it, like a magazine on a newsstand waiting to be purchased. The HTML may be made up of chunks of code that get assembled into a whole in that split second when the browser pulls it off the shelf.
That's the difference between dynamic and static web pages. Static pages are complete sets of HTML waiting to be retrieved, whereas dynamic pages are chunks of HTML that are assembled at the moment of retrieval into a single entity that's displayed in your browser (some systems store the most recent static version of a dynamically created page to keep the server from being overworked, but ultimately, the browser pages were created dynamically).
What I want you to take away from this lesson in particular, but the book in general, is to reject static thinking in favor of dynamic. You might have a vision right now for the content of a particular page on your website, but if you learn to view the content in chunks, there may be ways to use part of that content on another page as well. Dynamic thinking means you want to keep that chunk of content separate and reusable, not welded to the other content.
CONTENT MANAGEMENT SYSTEMS
Creating HTML pages dynamically is one half of what a content management system (CMS) does: it takes chunks of code (your content) and pieces them together into a single HTML page. The other function of a CMS is to provide an easy way for you, the user, to manage all those chunks of content.
Managing content does not just mean allowing you to enter text or upload images; it also means making it easy for you to determine the relationships between chunks of content. Selecting a category for the article you're working on, for example, tells the CMS to assemble that chunk in a particular way when someone on the Internet requests a page on your website.
Everybody understands the role of a CMS when it comes to managing content: it saves having to know HTML coding. But why not just have the CMS manage the content of individual HTML pages? All this assembling business seems like a lot of extra work. If you had a five-page website that never changed, that might be true. But suppose, even on a five-page website, that you decided you didn't like the top section or header that appears on all the pages of your site. Although a CMS for static pages would make it easy to change, you'd still need to change the graphics on all five pages separately, because they're all individual, physical pieces of coding. Now imagine that task on a site with 500 pages or 5,000! Even with search-and-replace capabilities, you would need to upload all 5,000 pages back onto the server to replace the old version, then do it all again for the next change. Ouch!
By separating the content of individual HTML pages into chunks, a CMS offers tremendous flexibility. Say you wanted 3,000 of your pages to have a different kind of header than the other 2,000. Easy, with a CMS! What if your business partner decides that your line of 500 different wuzzbuzzes should be categorized under buzz instead of wuzz? Easy, with a CMS!
We're always being told to embrace change, and one of the advantages of a website over print is that it allows you to change things as much as you want, as often as you want. The advantage of using a CMS instead of manually creating static or dynamic web pages is that the managing of change is much easier and more flexible, which is exactly what WordPress does.
WordPress as a CMS
In the first edition of this book, I explained that, although WordPress was developed as blogging software, it could be manipulated to be used as a CMS for any type of site. With the latest versions of WordPress, it has become a full-fledged CMS. But the question still remains: why use WordPress for your website? Lots of other content management systems are out there—good ones—that are also open source. I think the answer is twofold:
* The simplicity and flexibility of WordPress's design make it easy to learn, easy to expand, and easy to customize.
* The WordPress community is so large and so vibrant that you have excellent support, and will have for years to come.
The fact is, every CMS requires creative thinking, sometimes add-on software, and sometimes customization of the coding, because every site owner will have specific needs. No one CMS can fulfill everyone's requirements right out of the box.
All websites have a lot of common elements that may have different names and different functions, but from the standpoint of HTML coding, they operate in basically the same way. For instance, I need a page full of testimonials whereas you need a page of all your current specials. If a testimonial and a special are the chunks of content, all we need the CMS to do is assemble our chunks into whole pages. Your header and footer may be very different in look and content from mine, but we both need a header and a footer. A good CMS couldn't care less which is which—it just assembles and manages, easily and efficiently. As WordPress does.
HOW WORDPRESS ASSEMBLES PAGES
Three basic structures in WordPress interact to create HTML pages: the core, the theme, and the database (where content is stored). The core is the set of files that you download from WordPress.org and that perform the tasks of storing, retrieving, and assembling content. The database is where the content is stored and the theme is made up of template files that provide instructions to the core about what to retrieve and how to assemble it, as I've tried to illustrate in Figure 1-1.
Why Separate Is Good
You saw earlier why it's important that a CMS keep form (design and structure) and content (text and media files) separate, and now you're seeing the particular power of the way WordPress achieves this. Remember that earlier example of wanting 3,000 pages to have one header and 2,000 pages a different header? Depending on exactly how WordPress generates those pages, you might have to add only one template file to your theme to accomplish the change.
If you want to see a dramatic example of how the separation of form and content works on the Web, visit a site called CSS Zen Garden (www.csszengarden.com). You can instantly switch between dozens of incredibly different looks, all presenting exactly the same content.
But separating form and content isn't the only useful kind of separation that WordPress employs. It also separates the form from the core—the set of files that do the actual assembling and managing. That core is completely separate from the theme and the content, which is a good thing from a number of standpoints, the most important of which is the ability to easily update the core.
Software of any kind is constantly being given new features, strengthened for security, made more efficient, and so on. If you had to completely redo your theme every time the core needed an update, it would be very inefficient, just as having to redo your website content because of a new structure or look would be inefficient. As I said earlier, WordPress at its heart is a set of three separate structures—the core, the theme, and the content (in a database)—each of which can be tweaked, updated, or completely replaced, all independently.
There's a fourth separate structure to WordPress that is entirely optional: plugins. These are bits of extra code that you literally plug into the WordPress system and they provide additional functionality, from letting people rate the content on your site to automatically creating tweets on Twitter.
Sometimes, people ask why they don't just incorporate the plugins into the core, but that would be defeating the whole purpose of this elegant and flexible system. To begin with, plugins are meant to address specific needs. Why clutter the core with features that not everyone uses? Sometimes, a plugin is so useful to everyone that it is eventually incorporated into the core, but most plugins aren't like that. Also, the more complex the core, the better the chance things will break down. Keep the core simple and add on extras as you need them. I have some WordPress sites with only two plugins, and others have dozens.
Another reason for keeping extra features as plugins is that there can be many variations of a plugin, each one serving the needs of a group of users. A good example would be plugins for photos—some are very simple, some are very complex, some work better than others. Having a choice of those plugins, rather than being stuck with only one, is another important advantage.
HOW WORDPRESS MANAGES CONTENT
Very easily, thank you. Like any CMS, WordPress stores the chunks of content it uses to assemble HTML pages in a database. Getting that content into the database, letting you edit that content, and then storing instructions about how that content relates to other content is really what managing the content means. All databases work pretty much the same way, and though part of WordPress's simplicity and flexibility stems from the way its creators built the database and the files to run it, what ultimately matters to users is the interface that's used to do the managing. It's this administrative interface (a sample screen is shown in Figure 1-2) that my clients and hundreds of thousands of users around the world find so easy to use—for them, it is WordPress.
Every CMS has its particular way of dealing with content and though WordPress is extremely easy to use, you still need to understand how it refers to content and the methods it uses to organize content. Take posts, for example. In the world of blogging, people refer to the act of creating a new blog entry as posting. So it's not surprising that the primary kind of content chunk in WordPress is called a post, but that doesn't mean we have to use WordPress posts exclusively for a blog. A post is just a block of text and some instructions stored in a database. They could just as well have called them chunks. We don't want to get tied to how we use posts simply because they were originally intended for and named after an element within blogs.
WordPress has another type of content chunk called a page, but not the HTML pages you see in your browser. Like posts, WordPress pages are essentially blocks of text and accompanying instructions stored in a database. They're different from posts, though, in several ways. For a start, you can put only one WordPress page at a time into the final assembled HTML page. On the other hand, you can have dozens or even hundreds of posts displayed on a single assembled HTML page.
Suppose you set up WordPress so that each press release for your company is entered as an individual post. Then, you tell WordPress to show the five most recent press release posts. Whenever you add a new press release, it goes to the top of the list. On the other hand, the content describing your company's mission statement doesn't change that often—it's static in comparison to press releases—so you set up a WordPress page for that content. That's how you'll hear people describe the difference between posts and pages: one is for dynamic content and the other is for static content. The main thing is not to confuse a WordPress page with the final HTML page that gets generated and viewed by the public. WordPress pages and posts are both chunks of content that just get utilized in different ways.
There's another important difference between posts and pages: posts can be categorized whereas pages cannot. Pages can be a sub-page of another page, but it's a very limited relationship. There's a lot you can do with categories, as you will see later, but I'll mention one here: a post can be placed in multiple categories at the same time. That has enormous consequences for how you use posts. It makes it very simple for the content of a post to appear in several or even dozens of places on a website.
Excerpted from WordPress 24-Hour Trainer by George Plumley Copyright © 2011 by John Wiley & Sons, Ltd. Excerpted by permission of John Wiley & Sons. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
SECTION I: BEFORE YOU START.
LESSON 1: THINKING LIKE WORDPRESS 3
LESSON 2: PLANNING YOUR SITE FOR WORDPRESS 11
SECTION II: FIRING UP WORDPRESS.
LESSON 3: INSTALLING WORDPRESS 21
LESSON 4: ADMIN AREA OVERVIEW 31
LESSON 5: BASIC ADMIN SETTINGS 39
SECTION III: WORKING WITH WRITTEN CONTENT.
LESSON 6: ADDING A NEW POST — OVERVIEW 49
LESSON 7: WORKING WITH THE TEXT EDITOR 61
LESSON 8: LAYING OUT TEXT 73
LESSON 9: ADVANCED POST OPTIONS 81
LESSON 10: ADDING A NEW PAGE 91
SECTION IV: WORKING WITH MEDIA CONTENT.
LESSON 11: THE BASICS OF HANDLING MEDIA FILES 97
LESSON 12: THE UPLOAD/INSERT WINDOW TABS 105
LESSON 13: IMAGE OPTIONS IN DETAIL 113
LESSON 14: EDITING AND LAYING OUT IMAGES 121
LESSON 15: WORKING WITH IMAGE GALLERIES 137
LESSON 16: ADDING VIDEO AND AUDIO 147
LESSON 17: ADDING DOCUMENTS 153
SECTION V: MANAGING YOUR CONTENT.
LESSON 18: MANAGING POSTS AND PAGES 161
LESSON 19: MANAGING MEDIA FILES 173
LESSON 20: MANAGING POST CATEGORIES AND TAGS 179
LESSON 21: MANAGING WIDGETS AND MENUS 187
SECTION VI: MAKING YOUR SITE SOCIAL.
LESSON 22: THE LINKS MANAGER 201
LESSON 23: MANAGING COMMENTS 207
LESSON 24: BRINGING IN CONTENT FROM OTHER SITES 215
LESSON 25: HELPING OTHERS CONNECT TO YOUR SITE 223
LESSON 26: HAVING MULTIPLE SITE USERS 233
SECTION VII: CHOOSING AND CUSTOMIZING THEMES.
LESSON 27: OVERVIEW OF WORDPRESS THEMES 241
LESSON 28: CREATING A CHILD THEME 247
LESSON 29: BASIC CUSTOMIZATION OF YOUR DESIGN 255
SECTION VIII: BECOMING SEARCH ENGINE–FRIENDLY.
LESSON 30: OPTIMIZING YOUR CONTENT 267
LESSON 31: OPTIMIZING YOUR SITE AS A WHOLE 275
SECTION IX: HOUSEKEEPING CHORES.
LESSON 32: HOW IS YOUR SITE DOING? 285
LESSON 33: KEEPING UP TO DATE 291
LESSON 34: BACKING UP YOUR SITE 299
SECTION X: ADDING FUNCTIONALITY USING PLUGINS.
LESSON 35: INSTALLING AND ACTIVATING PLUGINS 307
LESSON 36: TWO EXAMPLE PLUGINS 315
LESSON 37: OTHER COMMON USES FOR PLUGINS 323
SECTION XI: TAKING WORDPRESS EVEN FURTHER.
LESSON 38: RUNNING MULTIPLE SITES WITH WORDPRESS 335
LESSON 39: CUSTOMIZING WORDPRESS 341
APPENDIX A: TROUBLESHOOTING WORDPRESS 347
APPENDIX B: GLOSSARY 351
APPENDIX C: WHAT’S ON THE DVD? 357