Hi Lars,

In a custom feature I recommend don't do the paging in the module control on the CMS page itself, link to a supporting page where the paging will happen so that they will have unique urls for each page and in your custom supporting page you can either leave out a canonical url or add your own according to your own logic.

Look at the blog on this site for example at the bottom is a pager, but as soon as you click a pager link you are no longer on the cms page blog.aspx but on a supporting page. You must also pass the pageid and mid (moduleid) to your supporting page along with your custom param.

Module controls that live on a CMS page (ie a virtual page in the menu) should not use extra query string params because it should be able to live on a page with other modules and no module should interfere with another.

Hope it helps,

Joe

Hi Lars,

For pages in the menu aka CMS pages, yes, canonical url is set in code behind of Default.aspx.cs like this:

if ((Page.Header != null)&& (CurrentPage.UseUrl) && (CurrentPage.Url.Length > 0))
            {
                string urlToUse = SiteRoot + CurrentPage.Url.Replace("~/", "/");
                if (CurrentPage.CanonicalOverride.Length > 0)
                {
                    urlToUse = CurrentPage.CanonicalOverride;
                }
                Literal link = new Literal();
                link.ID = "pageurl";
                link.Text = "\n<link rel='canonical' href='"
                    + urlToUse
                    + "' />";

                Page.Header.Controls.Add(link);

            }

for supporting pages it is up to each developer to add canonical url using their own code, so yes you would need to add your own logic similar to above in your custom code.

The purpose of passing the pageid and module id is both to keep the menu highlighted for the current page, to be able to link back to the current page, and to be able to enforce page and module view/edit permissions in your supporting page. There are helper methods in mojoBasePage you can call to check permissions with the module and page id

if you maintain pageid and moduleid some other way it still will not highlight the menu correctly if pageid is no in the url. When you are on a cms page with a friendly url, the friendly url is already really mapping to a real url /Default.aspx?pageid=x but you don't see this because of url re-writing. But once you navigate to a non cms page the pageid must be passed in order to have the menu highlighted and also to have a CurrentPage object that is correct. Also if search engines don't have the pageid or moduleid in the url then if a user clicks the search result there will be nothing already in sessions so there will be no way to determine the page or module. 

The other alternative is to implement friendly urls in your custom feature that link to a detail page, similar to what we have in the blog or webstore. For example in WebStore we have links to product detail page using friendly urls like /productname.aspx, but it maps to a real url /WebStore/ProductDetail.aspx?pageid=x&mid=y&product=z but because we use friendly urls with url rewriting the user does not see the paramters they see the friendly url /productname.aspx

You could study existing features like blog and webstore to learn how to implement friendly urls in your own feature. Friendly urls are even better for SEO because they can have key words in them as compared to some number identifier in a parameter. So if I have a product url like /panasonic-bluray-dvd-player.aspx that will be a better url than /productdetail.aspx?item=x in terms of SEO because the url indicates and re-enforces what the content on the page is.

Hope it helps,

Joe

You don't have to touch the re-writer, you can use the FriendlyUrl class to create friendly urls that map to real urls and to check for existing urls or suggest friendly urls from text strings like blog post titles or product names. But on your custom object then you must also store the friendly url internal to your object so that when you retireve a list of the objects you can link to the friendly urls. Once the friendly url record is created in the db by the FriendlyUrl class, then the url re-writer will see any request for the friendly url and will re-write it to the real url.

It will become clearer if you study the save methods in WebStore/AdminProductEdit.aspx.cs or in mojoPortal.Features.UI/Blog/EditPost.aspx.cs, you will see the code where we create friendly urls and you will see we also save the friendly url on the product object and on the blog object for use in creating internal links to the friendly urls.

If you delete one of your object items then you should also delete the url. If your custom object has a guid identifier, you should set the PageGuid on the FriendlyUrl to that guid so that if you want to delete the url you candelete it by the PageGuid assigned to the friendly url. So for blog urls we use BlogItemGuid for the FriendlyUrl.PageGuid and for Products we use ProductGuid, and for cms pages we use PageGuid of the cms page, so when we delete a page we also make sure to delete the friendly urls by page guid.

If you do use friendly urls then you would want to use the friendly url also in the canonical url.

Hope that helps,

Joe

Hi Lars,

Assuming your page is using mojoBasePage and our master page from your skin, inside your .aspx your skeleton code should be like this to support Artisteer:

<asp:Content ContentPlaceHolderID="leftContent" ID="MPLeftPane" runat="server" />
<asp:Content ContentPlaceHolderID="mainContent" ID="MPContent" runat="server">
<portal:mojoPanel ID="mp1" runat="server" ArtisteerCssClass="art-Post" RenderArtisteerBlockContentDivs="true">
<mp:CornerRounderTop id="ctop1" runat="server" />
<asp:Panel id="pnl1" runat="server" CssClass="panelwrapper ">
<h2 class="moduletitle">Your Title</h2>
    <portal:mojoPanel ID="MojoPanel1" runat="server" ArtisteerCssClass="art-PostContent">
<div class="modulecontent">

Your custom markup goes here.

</div>
</portal:mojoPanel>
 <div class="cleared"></div>
</asp:Panel>
<mp:CornerRounderBottom id="cbottom1" runat="server" />
</portal:mojoPanel>
</asp:Content>
<asp:Content ContentPlaceHolderID="rightContent" ID="MPRightPane" runat="server" />
<asp:Content ContentPlaceHolderID="pageEditContent" ID="MPPageEdit" runat="server" /> 

If you want to show side panel content in your supporting page call this method on the base page:

LoadSideContent(true, true);

It is ok to remove the SuppressPageMenu();

If you remove the this.allowSkinOverride = true; then your page will not support page level skins or user skins it will only use the site default skin.

You should not include your module or any other using ModuleWrapper in my opinion, this page is for supporting your module not hosting your module, you should put whatever  code you need there to support your feature.

Hope it helps,

Joe