1 / 48

Library Web Site Content Management Options Using PHP

Learn how Lewis & Clark College manages website content efficiently using a cost-effective system combining commercial and in-house tools for collaboration, structured data, and separation of content from presentation.

mmallory
Download Presentation

Library Web Site Content Management Options Using PHP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Library Web Site Content Management Options Using PHP Mark Dahl Lewis & Clark College Portland, Oregon

  2. Problem of content management • Building and maintaining a web site requires the collaboration of multiple specialists • Designers, writers, editors, programmers, etc. • Even in a small environment (college library with 25 employees) collaboration required

  3. Content management systems • Software packages designed for the construction and maintenance of large web sites • Expensive • In use in some higher ed environments and libraries

  4. Characteristics of content management systems • Separation of content from presentation • Defined document schemas • Access and workflow controls

  5. Our solution • Not a full blown content management system • A mixture of commercial and homegrown tools • Achieves some of the features of full blow system • Separation of content from presentation • Defined document schemas (metadata) • Limited workflow controls

  6. We sought a system that: • Allowed multiple staff members to edit pages on the site with little knowledge of HTML or web editing tools • Separated the content of the site from the presentation as much as possible • Structured data to promote consistency and ease of migration to future platforms • Allowed data used redundantly to be updated in one central location

  7. Two-pronged strategy • All pages on site • Distributed updating • Separation of content from presentation • Only our research resources pages • Structured data • Redundant data in one place

  8. Informational pages • Structured data and redundancy of data not as important as these pages (hours, library mission statement, etc. did not adhere to specific schema.)

  9. Part 1: the template system • Built to support the “interior pages” of our website that all feature a sidebar and banner (including pages edited by our resources editor to be discussed shortly) • These pages are also available in text-only format (that is, with the sidebar and banner removed)

  10. Template page in graphical mode:

  11. Template page in text-mode:

  12. Dreamweaver environment • Template system • Certain regions fixed, unchangeable • Certain regions editable • Template system inadequate • Doesn’t display CSS coding correctly • Won’t let you flip between different versions of template (text and graphical) • Hard to change templates globally across multiple Dreamweaver sites

  13. Solution: Templates + include files and PHP • Use server-side includes for the code to display • Graphical sidebar/banner • Text-only banner • PHP browser-sniffer code checks for compatibility with CSS2 compatible browser

  14. Central links file • The main set of links on the interior sidebar and on homepage are controlled with a central file • PHP code automatically inserts the links from this file • The code creates flyouts as needed

  15. Central links file

  16. Fine-tuning Content Mgmt. • Sometimes, Dreamweaver can be an awkward tool for staff: • It’s easy to check out files and forget to check them in • You must be conscious of remote and local files • There are many options for editing and formatting

  17. Macromedia to the rescue with:Contribute • Allows users to simply browse to a page and click edit to edit page • Checkin/checkout of files handled transparently • Respects Dreamweaver templates, synchronizes to latest version of templates • Can restrict access to certain files • Can restrict types of edits (dynamic pages, fonts, etc.)

  18. Keys to flexibility of our site’s look: • Template system keeps content within certain parts of the pages • Server side includes allow banner/sidebar to be changed centrally • An attached stylesheet allows font and site colors to be changed globally • This fall, we changed the fonts used across the whole site

  19. Part 2: The resources editor • Like most academic libraries, we maintain web pages that direct users to databases, electronic reference works, and “web sites” • These web pages are organized by subject • We built a database driven system to maintain these pages

  20. The resources editor • It meets objectives 3-4 that I mentioned earlier: • Structured data as much as possible to promote consistency and ease of migration to future platforms • Allow redundant data used across the site to be updated in a central location • We designed a database driven system for organizing research resources (including databases, web sites, and links to library catalog records of print resources)

  21. Goals for the resources editor: • Consistent metadata for each resource • Same data presented in multiple places kept in one place • Flexibility in displaying resources (A-Z list, by pathfinder) • Can be used to edit resources by the relatively untrained

  22. The precedent • There are many examples of libraries building database driven systems to organize resources on their web sites • Open source projects available for this: • Scout portal toolkit • MyLibrary • ResearchGuide

  23. Building our own • Existing code base from work at Central Oregon Community College • Linux OS • Apache Web Server • PHP scripting • PostgreSQL relational database

  24. Why build our own? • Special requirements for organization into pathfinders • Complete display flexibility • (fussy librarians) • Laziness • More on this later

  25. Resources database • Each resource represents a research database, web site, or reference to printed library material • Kept in a ‘resources’ SQL table • Fields in table loosely based on Dublin Core metadata standard: publisher, title, description, coverage, etc. • Resource editor: staff interface to allow adding and editing of new resources

  26. Building pathfinders • Each pathfinder would have a unique name corresponding to an L&C discipline: History, Psychology, Sociology & Anthropology, etc. • Resources would be organized into librarian-defined categories (history databases, history metasites, etc.) • Resources would be put in a certain order within those categories

  27. Resources & Pathfinders Resources: Pathfinders: -Academic Search Premier -Anthropological Literature -Historical Abstracts -Internet Movie Database -Lexis-Nexis News Film Anthropology History

  28. Pathfinder SQL table • Contains references to resources • Each row contains: • ID of resource • Name of pathfinder in which resource is found • Name of category in pathfinder • Position within category • Link to resources table to create pathfinders

  29. This shows the basic structure of a pathfinder: category resource

  30. Staff interface to pathfinder • Allows staff to search for resources or pick from drop-down menu • Pick appropriate spot in pathfinder, then add resource • Staff can also add and move categories

  31. Displaying the data • Done by creating a PHP class within an HTML document

  32. Displaying the data • Our librarians can create the PHP class in their web page in order to display resources • Or they can simply send a parameter to an existing page custom built to display pathfinders: http://library.lclark.edu/reference/resourcedisplay.php?subject=History

  33. Display options • Display pathfinder normally (brief description of databases, extended description of websites) • Display 1 category of a pathfinder within a normal web page • Display data about single resource • List all databases A-Z • List all full text databases

  34. Special features • Easy ability to link to print resources in catalog • Staff member updating data has name/time updated recorded • Book reviews field for info about how to find book reviews on a particular item

  35. Future enhancements • Patrons can build their own pathfinders • Patrons can comment on resources • Electronic resources management features • Search

  36. Reflections on doing it on our own. • Kind of like reinventing the wheel • But we do have special features of our system others (MyLibrary, ResearchGuide, Scout Portal Toolkit) don’t: • Resource records can be used across multiple pathfinders (ResearchGuide doesn’t support) • We support categories and unique order within categories • Many display options (brief, combined, alphabetical, full-text only) • Special fields (book review, database/website)

  37. Technical details • SQL databases (resources, subjects (pathfinders), links) • Query class (for querying database and returning result sets) PHP, built for PostgreSQL db • Displayclass extends queryclass, can be called with various parameters to display resources as desired

  38. Technical details • Staff interface (PHP) • Separate from other • Uses queryclass for lookups • Not object oriented • Writes to database without using special class • Written using Nusphere PHPEd (allows FAST PHP debugging and testing)

  39. References: • This presentation: http://www.lclark.edu/~dahl/presentations/ • Web site discussed: http://library.lclark.edu/ • Macromedia: http://www.macromedia.com • Nusphere PHPEd: http://www.nusphere.com • Oss4lib Open Source Systems for Libraries (links to ResearchGuide, MyLibrary, Scout Portal Toolkit): http://oss4lib.sourceforge.net

More Related