Many sites are generated from structured data, which is often stored in databases. When this data is formatted into HTML, it becomes very difficult to recover the original structured data. Many applications, especially search engines, can benefit greatly from direct access to this structured data. On-page markup enables search engines to understand the information on web pages and provide richer search results in order to make it easier for users to find relevant information on the web. Markup can also enable new tools and applications that make use of the structure.

$INFO['show_x_page_link'] = 9;

into your conf_global.php file to tailor how many pagination links are shown so you can find the best balance for your needs.


These changes will help reduce crawl errors and strengthen your ranking. It's the little additions like these that really add up over time.

• Make it easier for IP.Content users to set up a good website, without needing to code
• Make it possible for those who can code to share interesting block interfaces either directly or through the IPS Marketplace
  

• Packages
  
• Filter by stock quantity
• Filter by "show on registration" setting
• Filter by "show in store" setting
• Filter by "is physical item" setting
• Filter by "is subscription" setting
• Filter by "allows upgrading" setting
• Filter by "allows downgrading" setting
• Filter by price (minimum and maximum)
• Filter by "is renewable" setting
• Sort by name, in stock, upgrade charge, downgrade refund, price, renewal price, ACP-specified position, featured status, or random



• Filter by product
• Filter by member (e.g. to show the viewing user purchases they have made, or purchases their friends have made)
• Filter by active status
• Filter by cancelled status
• Filter by purchase date
• Filter by expiration date
• Sort by name, active status, cancelled status, start date, expiration date, renewal price, package name or random



• Filter by department
• Filter by status
• Filter by severity
• Filter by member
• Filter by replies (minimum and maximum)
• Filter by open date
• Filter by last reply date
• Sort by title, start date, last reply date, last new reply date, last staff reply date, number of replies or random



• Filter by status
• Filter by creation date
• Filter by paid date
• Filter by total (minimum and maximum)
• Sort by title, amount, date, date paid or random



• Filter by status
• Filter by date
• Filter by method
• Filter by member
• Filter by amount total (minimum and maximum)
• Sort by amount, date or random



• Filter by status
• Filter by order date
• Filter by ship date
• Filter by ship method
• Sort by date, ship date or random

• Change the tab 'title' (the text that shows when you mouse over the tab)
• Change the application's public title (be aware that third party language packs can override this)
• Toggle whether the tab is hidden or not
• Change the tab permissions (who has access to see the tab)
• Add custom attributes to the anchor tag that is drawn. This is a feature unique to IP.Content, allowing you to add custom onclick handlers, rel attributes, and other similar attributes to your tabs if you have a need.
  

• Your moderators and your users can now edit comments on the front end, where permitted. A new per-moderator permission option has been added to let you determine which moderators are allowed to edit comments.
• Your users can now report comments in IP.Content (as well as database records and articles!)
• The commenting engine now allows the AJAX-powered "quote" option, the same as you see with the comments below this blog entry
• Multi-moderation has now been implemented, allowing you to check off the comments you wish to moderator and act on them all in one go.
• Keeping in line with the moderation changes coming in IP.Board 3.3, an unapproved comment can be either "approved" or "deleted". An approved comment can either be "hidden" or "deleted". A hidden comment can now be "unhidden" or "deleted".
• Commenting is fully AJAX-powered (when available). This means quoting, adding, editing and other actions all get processed by an AJAX request, rather than traditional page refreshes, creating a smoother user experience for your users
  

• Index page: Database name - Page name - Website name (or board name, if no website name)
• Category page: Category name - Database name - Page name - Website name (or board name, if no website name)
• Record page: Record name - Category name (if available) - Database name - Page name - Website name (or board name, if no website name)
  

* define( 'CCS_PAGE_TITLE_CAT', '' ); * define( 'CCS_PAGE_TITLE_RECORD', '' ); * // Following variables will be replaced: * // {page_name} = Page name * // {database_name} = Databae name * // {category_name} = Category name (only available for CCS_PAGE_TITLE_CAT and CCS_PAGE_TITLE_RECORD) * // {record_name} = Record name (only available for CCS_PAGE_TITLE_RECORD) * // {website_name} = Website name as configured in ACP * // {board_name} = Board name as configured in ACP

	 * define( 'CCS_PAGE_TITLE_HOME', '' );

You could thus specify "(Website Name): Record Name - Category Name" for records, or you could have "Record Name - Page Name (And some custom text here)". Ultimately, if you wish to redefine your page titles, you can now do so with relative ease, and without having to worry about future updates reverting your tweaks.


But wait, there's more! We didn't want to make a few minor changes to the format of the page title and call it a day. Many users have explained that while they want to name a page something simple (i.e. "News"), because that name is used in many places across the software, they may want their page title to say something different (i.e. "News - everything you need to know about my website subject matter"). How can we accommodate this as well?

We have added a new option to the page form that allows you to optionally specify a page title that is different from the page name. To be clear - the page name will continue to be used throughout IP.Content, while the page title you specify will ONLY be used in the <title></title> tags, allowing you to completely control it. It should be noted, as well, that this new field is optional, so you aren't required to fill in the same name twice for all of your pages, or edit each of your pages upon upgrade to give it a separate title.



When you uncheck the box, you can now specify a separate page title




We have implemented this same new functionality for categories as well, so you can now define a category page title separate from the category name, should you wish to do so.


In the process of making these changes, we noticed that the breadcrumbs within databases would use the page name on the database home page, however once you navigated within the database, the database name was used in the breadcrumbs instead. We have changed the breadcrumb navigation to always use the page name, and not the database name, to improve consistency and maintain hierarchy definition of the site.


Redirecting Duplicate Page Requests

While working through the system we found that page requests that are different, but load the same page, do not redirect to the correct form of the URL. For instance, if I have IP.Content at "www.site.com" and my default index page is "index.html" (and I have not enabled the option to remove the page name from the URL for this page), then I can access the same page via the URL "www.site.com" or via "www.site.com/index.html". The same page is loaded from two different URLs. As a general rule for SEO, this is bad, and all URLs that point to a page should redirect to the correct form of the URL for that page. We have enhanced IP.Content to detect this scenario and it will now 301 redirect these duplicate requests to the correct form of the URL.


Pages Tab

The "Pages" tab in IP.Board, if you have not hidden it, links to "index.php?app=ccs" by default. The system is designed to load your default page (with a fresh install, this would be "index.html" in the root of your Page Manager), and while we have already implemented a feature to redirect duplicate URLs to the correct form of the URL as described above, we took this one step further for the Pages tab. A new hook will be included with IP.Content 2.3 that rewrites the "index.php?app=ccs" URL used for the Pages tab by default so that it links to the correct form of the URL for your default page. This will reduce the number of duplicate URL requests that have to be redirected and help ensure only one URL is used to refer to any one given page (especially your index page, likely the most important and trafficked page of your IP.Content installation).


Memory System

IP.Content gives you a lot of flexibility and control, allowing you to fully define the URLs of your pages. You can define the full folder and page name structure for your pages; you can define the FURL string to use for your database categories; you can even define static FURL strings for your articles and other database records. This allows you to remove any ids from all of your URLs, but the tradeoff is that if you ever change your mind and rename a page, or a category FURL string, or an article FURL string, the system has no way to know where an old URL should point.

For example, say you gave a database category a FURL string of "information". Your URL to this category is "site.com/articles/_/information/". A year down the road, you want to change this information page to an FAQ, and you want to update the FURL string to reflect this. The URL to this category becomes "site.com/articles/_/faq/". After a year, search engine spiders have surely indexed the previous URL, and visitors may click it in a search engine listing to reach your site. The problem is, that old URL no longer exists, and because it was a static piece of information without an ID, IP.Content has no way of knowing where the request should be pointed to now.

We have eliminated this problem with a URL memory system, automatically available for pages, categories and records/articles with a static FURL string (if you do not explicitly define a static FURL string for articles a dynamic one is used with an ID, so this problem does not exist in this scenario).

If you rename a category/page/article in IP.Content 2.3, it will remember the old URL behind the scenes. If a request is received and cannot be processed, IP.Content checks it's memory system to determine if the URL previously was valid, and if so, where it pointed to. IP.Content will then 301 redirect the request to the new URL, eliminating problems with broken links when you change your pages after they have been indexed. This was a highly requested feature, and we hope it makes managing your URLs easier, and more forgiving when you change your mind later on.


Wrap Up

We are continuously monitoring feedback we receive from clients, and we understand that SEO is important to you. We wanted to take the time to implement useful functionality changes in the software that will help your site grow. At the same time, we want to focus on proven areas that have a real measurable effect, and that will benefit all of our customers. We believe the changes discussed in this blog entry will improve both the user experience, as well as the experience search engine spiders have while indexing your website. It should be noted, as well, that every single one of these ideas stemmed from feedback suggestions in our IP.Content feedback forum, where we encourage you to share your thoughts with us! We welcome your comments on these changes below!