Pages URL Flexibility & SEO + Usability Questions

[opentype]

If I can "place a database output" on a Page then why am I limited to 1 database per Page?

Because all the URLs for forms, filters, pages, categories … are based on that one page and multiple databases per page would be conflicting. 

You can however output content from as many databases as you want on one page using blocks. 

My desire is to know as follows -- can I or can I not have URLs that don't rely on the category structure as they do now?

Using the stock software without modification, I think you can’t. A way around it would be to not use “categories” so much. For example, I could have created sub-categories like “Windows” and “Mac” for my App category, but instead I use fields which can be filtered. That give me short URLs and greater flexibility for future changes. 

[Matt]

I think you need to keep in mind that the Pages app is part of the suite. We have to be careful with namespaces and so on.

Briefly, a "Page" is a container for content. This can be manual HTML, WYSIWYG or a page builder.
You can embed a database into a page. This means you can add data around the database if you want to.

In terms of URL, if you have a database inside a page, you'll have:

page_name/ (Database category index)
page_name/category_name (List of records)
page_name/category_name/record_name-r1 (Record, you can manually change the FURL to what ever you want, so you can just have record_name)

I can't really see how it could be any better?

If you have sub categories, then they are shown:
page_name/category/sub/record_title

The reason the "-r1" is on the end is because that's how we can tell its a record. Remember you might have:

folder/folder/folder/page/category/category

Or you might have

page/category/category/

So Pages just looks for a URL that ends with "-r1" and says "Ok, that's a record" and works backwards form that.

[esquire]

I think you need to keep in mind that the Pages app is part of the suite. We have to be careful with namespaces and so on.

Briefly, a "Page" is a container for content. This can be manual HTML, WYSIWYG or a page builder.
You can embed a database into a page. This means you can add data around the database if you want to.

In terms of URL, if you have a database inside a page, you'll have:

page_name/ (Database category index)
page_name/category_name (List of records)
page_name/category_name/record_name-r1 (Record, you can manually change the FURL to what ever you want, so you can just have record_name)

I can't really see how it could be any better?

If you have sub categories, then they are shown:
page_name/category/sub/record_title

The reason the "-r1" is on the end is because that's how we can tell its a record. Remember you might have:

folder/folder/folder/page/category/category

Or you might have

page/category/category/

So Pages just looks for a URL that ends with "-r1" and says "Ok, that's a record" and works backwards form that.

​Matt - Thanks for the explanation. I will apologize for the length of this post -- skip the middle and go to the end if you want to see the end result for a question I have regarding this system. In this example, I was able to create two pages that, IMHO, should not bring up different results. It is also why I believe that the decision to display or not display cats/subcats/ could easily be generated by defining how you want it to appear by Page/Database.

-------------

I understand the need to have a (i) Database identifier, and (ii) Record identifier -- that's all you need to identify any unique "record" which to simplify for those following, call it an Article. What categories and subcategories it belongs to is irrelevant to pull up that Article as it is, e.g. record 4324 in the Articles database. Same as topic/record 4324 in the Forums database.

Page - It is supposed to refer to a location, e.g. mysite.com/articles/ -- it's actually articles/index.php or some default that is hidden to mean the same thing. So the articles/index.php is the page you want to be the "home" for your Articles database. Same thing like /forums/index.php - a page is created for you there. It's not really a "container" like a folder -- better to call it a page that you can customize by filling it with widgets.

 So, how do we set up the /articles/index.php "Page." You must define a single / default Database IF you want to use the /articles/ directory as an identifier for your records/articles the same way that /forums/ is an identifier for the forums database to find forum names ( /forums/123-forum-name ) and forum topics uses /topics/123-topic-name . Hence the slug "articles" will be used with the database of my choosing, which I'll call "ArticlesDB, ID 3". So  /articles/123-article-title-here/ I should be able to pull up the article by its number, article ID 123 in database 3 which is the ArticlesDB.

----------------

Here's where it gets sticky. Since forums uses the URL "forums" and "topic" to identify that it is a record from the Forums database. These are namespace issues and why if I try to create a "folder" called "forums" I get:

This folder name cannot be used as it causes a URL collision with another installed application.

So what is the purpose of a "folder" exactly? This seems to be the creation of a directory that doesn't exist. Why you'd want to create folder/folder/folder/filename.html ? Don't know why in most circumstances and perhaps you can suggest reasons why I'd want to do that. If I want to build URL structure into a file then I select "use category names in the URL" as an option and it will show all cats and subcats to get there. After all, filename is nothing more than a record in a database, e.g. /articles/folder/folder/folder/123-article-name or musicfile/123-music-file-name.

So.... I created a Page called "Articles" and defined it has having a page "articles" so the final URL is

mysite.com/articles/

That generates a list of articles from the Article DB that I connected it too, all is cool. http://fixxer.com/articles/

I just created a folder called "articles" -- yet Pages allowed me to do that. So now a directory can be created which is the equivalent of Pages. There is no conflict? So here is what I did:

http://fixxer.com/articles/index.html

Note that this page is different than the one I created above. I would have thought that once you create a path for a database, that becomes part of the "reserved namespaces" that the system would be used. Thank you for your patience.

[esquire]

One note - I cannot edit any more as there is bug. Matt... this is a really ambitious system!!! It's very impressive and please don't let any of my comments in any way diminish how much respect I have for Pages and the potential power of this system. My feeling is that in giving us this incredible precision, it introduces so much complexity to accomplish simple tasks at hand such as just setting up and displaying different text databases, e.g. tutorials, mag, how to or a rich media database like video, music, etc. 

It also creates management questions. I created this one too: http://fixxer.com/articles/index.php/ -- yes, you can have variations of every type you want with .php, .html, .htm but I don't know what the consequences are using IPS like I would if I was running this on Apache.

So my request - I don't know if at all possible, is to have the option to keep things simple exactly like forums and without the cats/subcats/

/dbidentifier/123-record-number-title-here

 

[esquire]

And the related question (damn edit bug) -- whether subdomains will ever be a part of the Pages system so that store.mysite.com will be a page to display an App or music.mysite.com will provide a page that will access  a database.

[opentype]

 

/dbidentifier/123-record-number-title-here

​Considering how important SEO seems to be to you, it’s surprising that you are so eager to remove the categories from the URL. Because that’s like one of the most simple and effective SEO measures. In my directory database my “book category” has the URL slug “books”. So when someone is searching “[book name] book” my IPS site creates a better match than a WordPress site would, for example. The advantage of the the WordPress implementation is that the record can be part of different categories, but the IPS implementation actually delivers a more SEO-friendly URL for single records. 

 

[esquire]

​Considering how important SEO seems to be to you, it’s surprising that you are so eager to remove the categories from the URL. Because that’s like one of the most simple and effective SEO measures. In my directory database my “book category” has the URL slug “books”. So when someone is searching “[book name] book” my IPS site creates a better match than a WordPress site would, for example. The advantage of the the WordPress implementation is that the record can be part of different categories, but the IPS implementation actually delivers a more SEO-friendly URL for single records. 

Thanks for the SEO lesson. This is the way I would create a directory database of books as probably would many others, with a laundry list of reasons. 

books.mysite.com

 

[esquire]

Regarding Wordpress.... With a plugin that has been available for many years I can create one Wordpress installation that allows the creation of a database for directories OR subdirectories. With another plugin also available for many years, I can choose to use a primary category if I wished. And without any plugin I can choose none at all or every category and subcategory.

So using one Wordpress installation, I can actually accomplish all of the bottom examples and manage it in one location, in one database and one control panel. Nonbelievers who wish to have this done on their sites can forward a consulting fee.  This is the reason why I'm frustrated here. Yes, what is assumed here IS surprising!

(1) books database

books.mysite.com OR
books.mysite.com/category/

(2) News journal
www.mysite.com/news/ OR
www.mysite.com/news/category/

(3) Typographers database
typographers.mysite.com OR
typographers.mysite.com/category/subcategory
 

(4) Personal/site blog

myblog.mysite.com OR
myblog.mysite.com/category/ OR
myblog.mysite.com/category/subcategory/ OR
myblog.mysite.com/datehere/post-title/

 

 

[opentype]

 This is the reason why I'm frustrated here.

​You are frustrated because the stock IPS installation can’t do, what a stock WordPress installation also can’t do – as you have just admitted. ;-)

[esquire]

​You are frustrated because the stock IPS can’t do, what a stock WordPress installation also can’t do – as you have just admitted. ;-)

Wordpress does what it is designed to do extremely well, especially with plugins. It costs $0. For the purpose of publishing and allowing users to submit articles, IPS Pages is not even in the distance.

What frustrates me is that a simple CMS would handle the publishing needs of probably the overwhelming majority of forum customers. If you took the very basics of Wordpress, included some of the basic URL options and the ability to toggle fields on/off to use or show on the front end, it would be done. Page Builder? Simple. All most need is the ability to create a landing page for the home page of every content database. And if you need category pages, just have a drop down menu that allows you to define which category page you want to have a custom layout. Did anyone compile a list of basic items that one would expect? Nobody noticed that the meta description field isn't working at all in its output to source and isn't shown on the front end to create articles?

What I have is an ultra powerful file manager that doesn't accomplish a short laundry list of essentials but gives me incredibly complex management and tools to do lots of other really cool things. What really frustrates me? That I'm still leaning toward a forum software that is mature and best of breed and a Wordpress bridge because at least it gets the job done. And it's free.

 

Well, I'm tired of doing QA and finding issues I'm surprised still exist. I'm tired of trying to defend what any respectable webmaster/SEO would consider basic SEO or site setup options they might expect. All I wanted to know was (1) whether the same forum URL structure could be used for Pages; and (2) whether I could use the software to put Apps or Page Databases on subdomains. I'll await an answer - if it comes. I'm done wasting time here.

[ZakRhyno]

I think you need to keep in mind that the Pages app is part of the suite. We have to be careful with namespaces and so on.

Briefly, a "Page" is a container for content. This can be manual HTML, WYSIWYG or a page builder.
You can embed a database into a page. This means you can add data around the database if you want to.

In terms of URL, if you have a database inside a page, you'll have:

page_name/ (Database category index)
page_name/category_name (List of records)
page_name/category_name/record_name-r1 (Record, you can manually change the FURL to what ever you want, so you can just have record_name)

I can't really see how it could be any better?

If you have sub categories, then they are shown:
page_name/category/sub/record_title

The reason the "-r1" is on the end is because that's how we can tell its a record. Remember you might have:

folder/folder/folder/page/category/category

Or you might have

page/category/category/

So Pages just looks for a URL that ends with "-r1" and says "Ok, that's a record" and works backwards form that.

@Matt @Charles

​Now, I don't know much about SEO but I have seen many people say that long URL's like give examples from the OP's examples. With long URLs won't this effect SEO from search engines and all? How is this problem address if it does in IP.Content 5?

[esquire]

@Matt @Charles

​Now, I don't know much about SEO but I have seen many people say that long URL's like give examples from the OP's examples. With long URLs won't this effect SEO from search engines and all? How is this problem address if it does in IP.Content 5?

EDIT: Pages works fine as designed if you just want to put content on a page with many other cool things. My concerns are my own and you can choose whether or not to care. Unfortunately I don't have time to explain all my cocnerns. Hypothetically, the URL length doesn't matter much in some search engines - but nobody knows for sure whether it may matter to even a small degree or whether it may matter more later. Some thoughts:

-  There is also the time and processing needed 147 vs. 70 characters -- which do you think will go more quickly? Multiply that many times on active sites. Less is more. Let's move on.

- There is also the human factor. If you see a naked URL of  "mysite.com/seo-ips4-best-tips....." would you be more inclined to click than "mysite.com/page/category/subcategory/subcategory/1234565-s...." ?

- And then there is the likelihood your URLs may change. If they do after publishing, things happen you may not realize and which some are downplaying the effect. It also introduces additional potential fail when completely unnecessary. As per the above, let's say you create an IPC database with 10 categories and each have 5 subcategories. If you find that any of your 10 categories or your 50 subcategories change in any way (modify a name, delete a cat/subcat, move subcategories to a different category, make a category into a subcategory, etc) then you will have caused all your URLs related to any category or subcategory to be 301 redirected (or fail if this doesn't work properly). I have no time to explain why this isn't just "no concern at all as it all shows up correctly." 

Now if you're using IPS for a WIKI - what is the likelihood that the structure will change over the course of time? How about new sites which will need to adapt over time? Another thought - Imagine how many redirections you need to keep if this happens often? PPS - and you can't assign an article to appear in multiple categories, e.g. a "breaking news" and "sports" categories.

Regarding the rest of Pages, there is a set list of "must have" items that I put against every CMS I use. This isn't rocket science, just part of the front page of any truly competent SEO or Webmaster. If I don't have the ability to place header tags into the text, it's suboptimal. Meta description must be able to be provided. Excerpt text is highly recommended but not as absolutely essential. That's what is needed. I couldn't care less about powerful features if the most important function doesn't nail all the basics.

Pages will work fine, as is, to put content on a page to be displayed to users. Some may care about my concerns, others may not. I personally care about (a) all the essential items I have identified be available to admin and contributors (b) URL generation by Identifier and Record Number in Pages and (c) about whether I can place any App/Page on a subdomain. So, either it can/will or cannot/will not be done.

 

[esquire]

So... I did a little thinking. I'm going to use "tags" instead of categories and I can generate what I want. Unfortunately it's a total end run around the actual article creation system but hypothetically I'm capable. 

http://fixxer.com/direct/just-stuff-in-database-direct-r1/

Boom! There ya go. Now I can appreciate all the stuff going on before about things being connected, etc. but it all seems unnecessary. This works and it's /magazine/article-name-here-r12345.

1) Is there any way to get rid of the "r" that appears in the record number because, obviously, it's a record in the "direct" database just like a topic number is a record in the "topic" database? Notice that Forums and other modules don't require a letter identifier. This setup would allow me to import articles from other content management systems without major damage IF we can remove the "r" from the URL.

I realize that this suggestion is late but I didn't have an opportunity to provide input until this date. So... why not have categories set up to be attributed to record numbers just as this is? Perhaps I can construct a Page with a category name to create a "category page" and that will suffice but not optimal. So:

2) Can you list tags used in a database like you can when one creates a new Article?

3) Can you limit the tags used in any way so a user can select from a list of tags the same way you can a forum Topic prefix?

 

Notes:

- If you used a database for a page, there is no way to know what page it is being used on (especially since the tab disappears.) Imagine having 20 pages and no idea which page a database is connected.

- I can't tell you the number of times I keep hitting "uploaded images" by mistake and adding them to posts...

[Storyteller]

Notes:

- If you used a database for a page, there is no way to know what page it is being used on (especially since the tab disappears.) Imagine having 20 pages and no idea which page a database is connected.

​In the database overview:

[esquire]

​In the database overview:

Thanks. ​In other words, better stated as "connected to" since you can "use" several databases on one page. OK. But the reverse is not true though. If you're browsing the Pages table you can't see which Page is connected to a database at a glance. You have to choose the page, see the name of the page, enter it into the URL of the browser, then choose "Page Builder" and launch that, then see the database that is connected to the page. And as a result, I've had front/home pages for databases that appear to work but, when you click on articles, the go nowhere. There will be a lot of questions about this for users. OK... thanks for the explanation. I hope we can figure out the other question.

[opentype]

OK. But the reverse is not true though. If you're browsing the Pages table you can't see which Page is connected to a database at a glance.

The page is just a page—a container. Just as a menu item is just a link. I don’t expect the pages overview to show all the possible things I have put on every page.

And regarding the databases I usually don’t need it anyway, because the page name will usually be chosen according to the main database used on that page. I might have a “books database” been put on a page named “books” linked in the menu as “Books”. Not much confusion there regarding what might be on that page. 

​

[esquire]

The page is just a page—a container. Just as a menu item is just a link. I don’t expect the pages overview to show all the possible things I have put on every page.

And regarding the databases I usually don’t need it anyway, because the page name will usually be chosen according to the main database used on that page. I might have a “books database” been put on a page named “books” linked in the menu as “Books”. Not much confusion there regarding what might be on that page. 

​

​I appreciate what you're saying. I'm just going to assume that people can create pages/databases like you describe although when you add more data and also planning, it gets cluttered. But you are assuming that the Books Database is assigned or connected to the Page, even though both may be created. If you use a "latest records" widget on the home page, clicks to the articles shown there go nowhere because you didn't "add the database" to the page. I don't know why there wouldn't be an indicator on the front page that shows that a Page has been assigned to a Database and vice versa so an admin can easily spot misconfiguration. Make sense?

http://fixxer.com/articles/

I've just created this example to show how easy it is to fail. This page actually works and shows the latest articles/records in the "Articles" database. However, if you try to click on articles it doesn't work. That's because the Database isn't assigned to the page. Viewing pages to see whether or not they are assigned to a database is especially helpful if you're going to be creating a complicated tree structure. This is a very powerful system and that's impressive, although I think this unnecessary power adds a ton of complexity and probability for error.

[opentype]

If you use a "latest records" widget on the home page, clicks to the articles shown there go nowhere because you didn't "add the database" to the page. 

That’s why the page creation is now part of the database setup. To avoid such misconfigurations. ​If you actively choose to skip that step, you should know what you are doing. 

[esquire]

That’s why the page creation is now part of the database setup. To avoid such misconfigurations. ​If you actively choose to skip that step, you should know what you are doing. 

​That assumes a user doesn't hit "save" any time before actually getting to the last tab since Page creation is not required, nor should it be. And if you hit save before you assign a page, the "Page" tab disappears - not sure why. Bottom line is that with a decent, well organized, consistent UI, these problems are usually solved. This may be better than it was before but there still is much room for improvement. This doesn't matter nearly as much as the URL generation issue above but I mention it because it should be fixable and fixed. The URL issue means some site moves will require a massive number of 301 redirects using popular software.

[esquire]

Now I remember how I discovered all these issues - my Articles database is orphaned and unable to be connected to any Page. Somehow it was disconnected from the Articles Page and the widget that allows you to connect a database to a page is missing. And with the tab disappearing from the Articles Page area, this means the database and all therein cannot be displayed. And when that happens you don't get a 404, you get the following. I'll report it as a bug and I'm surprised this hasn't happened to others yet, perhaps because those using it may be experienced and not playing around in the admin panel as will happen:

http://fixxer.com/articles/seo/google/another-article-that-now-has-stuff-in-it-r5/

Fatal error: Maximum execution time of 30 seconds exceeded in /home/fixmeup/public_html/system/Data/Store.php on line 0

[opentype]

The database view and the category view are working – so it doesn’t look like your database is orphaned. You seem to have broken your record view somehow. 

[esquire]

The database view and the category view are working – so it doesn’t look like your database is orphaned. You seem to have broken your record view somehow. 

​The Articles Database has no reflection that it is connected to a page.

And Page Builder shows no widget either.

 

For those following, outstanding questions here:

1) Can/will apps ever be able to be assigned to subdomains and not just a page in a subdirectory?

2) Can/will pages ever be assigned to subdomains?

3) ) Is there any way to get rid of the "r" that appears in the record number because, obviously, it's a record in the "direct" database just like a topic number is a record in the "topic" database? /topic/12345-topic-name so articles/pages should be /articles/article-title-12345 and not -r12345 

Work arounds:

4) Can you (a) create a list of predefined tags and (b) can these be presented to the user when creating an article to use instead of the category tree?

[opentype]

 

4) Can you (a) create a list of predefined tags and (b) can these be presented to the user when creating an article to use instead of the category tree?

​That is a suite posting feature, but currently not a database-level feature I believe. 

 

When you want users to select topics for articles, I would check out the possibility to use a Select Box field for that. 

[Matt]

I guess we can go around in circles here, but I personally consider hierarchical URLs to be the correct thing to do.

For example, if you had a database on a page named "books" and a category called "reviews" and you submitted an article called "Jack Reacher - One Shot" with a manual slug of "jack-reacher-one-shot" then you'd have:

books/reviews/jack-reacher-one-shot

So one googling "book reviews jack reacher one shot" would get to your site in a fair world.

Without adding the hierarchy, then you'd need to make the slug "book-review-jack-reacher-one-shot" to have the same affect which is more of a mouthful and looks less natural than the hierarchical link.

But you have the ability to not use categories. So if you were happy for everything to go into one area then you can do that.

Also keep in mind that you can build pages that do not have a database, and that is the purpose of folders.

Ultimately, though, I think you're approach Pages by trying to emulate Wordpress and getting frustrated. It might be better to toss out what worked with Wordpress and build Pages using its strengths. Or just use Wordpress anyway.

[esquire]

I guess we can go around in circles here, but I personally consider hierarchical URLs to be the correct thing to do.

For example, if you had a database on a page named "books" and a category called "reviews" and you submitted an article called "Jack Reacher - One Shot" with a manual slug of "jack-reacher-one-shot" then you'd have:

books/reviews/jack-reacher-one-shot

So one googling "book reviews jack reacher one shot" would get to your site in a fair world.

Without adding the hierarchy, then you'd need to make the slug "book-review-jack-reacher-one-shot" to have the same affect which is more of a mouthful and looks less natural than the hierarchical link.

​Matt - thank you for the explanation. Let's take the assumption above that hierarchical URLs with categories is good for SEO, regardless of prior discussion. If so, then why wasn't this optimal formula to generate URLs applied consistently across the entire suite? Blogs are just a user-controlled area to publish articles like Pages. But that's totally different. And so are Forums, which provides yet another structure, neither of which use hierarchical URLs with category keywords.

Text Based Content URLs - 4 different structures

• pagesarticle/category/subcategory/title-goes-here-r12345
• topic/12345-title-goes-here
• blogs/entry/12345-title-goes-here
• pagesdb/title-goes-here-r12345

Other Apps URLs

• gallery/image/12345-title-goes-here
• store/product/12345-title-goes-here
• calendar/event/12345-title-goes-here

Forgetting the SEO assumption made, there are still two issues: (1) ability to organize the display of your content without breaking URLs; and (2) consistent treatment across the suite. Hierarchical URLs requires numerous 301 redirects any time you move articles or wiki entries from one category to another. And that's what a good category system with breadcrumbs is made to accomplish (which users will use) which long URLs with every cat and subcat do not (and users will generally not use).

But you have the ability to not use categories. So if you were happy for everything to go into one area then you can do that.

Also keep in mind that you can build pages that do not have a database, and that is the purpose of folders.

Ultimately, though, I think you're approach Pages by trying to emulate Wordpress and getting frustrated. It might be better to toss out what worked with Wordpress and build Pages using its strengths. Or just use Wordpress anyway.

​Wordpress, Joomla, Drupal, etc. all allow users the option to organize content continuously without breaking their URLs. And what confuses me is the inconsistent approach to content organization across the Suite. Why would there be categories for organizing Gallery images but user Blogs gets dumped into one huge pile nobody can easily browse? And what about subdomains? How many sites have structures like these that make much more sense for a variety of reasons:

• store.mysite.com
• directory.mysite.com
• forums.mysite.com
• files.mysite.com

I understand the concept of folders but that is front end presentation, not organization of the actual data - which I would think should include URLs for apps made to replace standalone software. I honestly don't know why anyone would want to have a huge database of stuff that cannot be easily managed and organized on back and front end. A very complicated way of handling low hanging fruit and common tasks. I guess it doesn't pay to debate this at this late date for a discussion that actually began in 2012. For the sake of just getting the answers to these elusive questions, I'll get right back to the questions: I'll assume that all of the following will not be capable in IPS 4:

1. The ability to put apps or Pages in subdomains
2. The ability to remove the "r" from URLs generated by the Pages app
3. The ability to apply categories to database items