warning @ m_rsc:634 until all pages have Page path, including a Person!

[Amiramix]

Zotonic continuously throws this message:

warning @ m_rsc:634  Failed to get page url path. Is the `page' dispatch rule missing?

Unless exactly ALL pages have their Page path set to something, including Main menu (of category Page menu) and Site Administrator (of category Person). I've set them to /menu and /administrator correspondingly but does it make any sense?

[Marc Worrell]

Aha, that is why your urls are not working.
You need some dispatch rules, which were moving around for the 0.9

Use this (adapted from mod_base_site/dispatch)


%% -*- mode: erlang -*-
[
%% The home page, just shows the "home.tpl" template.
{home, [], controller_template, [ {template, "home.tpl"} ]},

%% Normal page to show a resource.
{page, ["page", id], controller_page, [ {template, {cat, "page.tpl"}} ]},
{page, ["page", id, slug], controller_page, [ {template, {cat, "page.tpl"}} ]},

%% Pages when part of a menu
{page, ["page", id, "in-menu", in_menu], controller_page, [ {template, {cat, "page.tpl"}} ]},
{page, ["page", id, "in-menu", in_menu, slug], controller_page, [ {template, {cat, "page.tpl"}} ]},

%% Pages when part of a collection
{page, ["page", id, "in-collection", in_collection], controller_page, [ {template, {cat, "page.tpl"}} ]},
{page, ["page", id, "in-collection", in_collection, slug], controller_page, [ {template, {cat, "page.tpl"}} ]},

%% Redirect controller for resource of type 'website'
{website, ["redirect", id, slug], controller_website_redirect, []}

].

[Andreas Stenius]

Yay!

My warning striked home again! ;-D

Perhaps we could introduce error id's, which we can then have documented.

Example::

warning @ m_rsc:634 Failed to get page url path. Is the `page'

dispatch rule missing? [http://zotonic,com/doc/errors/id/4/1#25]

So browsing the provided link gives more details to the message,
probable causes, trouble shooting and other info to help resolve the
issue.

//Andreas

2012/9/20 Marc Worrell <mwor...@me.com>:

[Marc Worrell]

That link sounds excellent!

So we have to number our errors, maybe introduce a file with all errors?
Then we can also translate them… (in due time).

- M

[Andreas Stenius]

I thought that we could classify them (hence the directory nesting and
finally the hash to direct to the proper place).

That way, each part of the system can have its own numberspace (or
namespace, either would work), and then simply allocating from that.

Hey, why not simply use the file and line number info?... ah, right,
the line number will move around... too bad.
But filename plus arbitrary identifier. Then we only need to keep
track of the id's on a per file basis.

Ah, needs some brainstorming, but something along those lines...

2012/9/20 Marc Worrell <mwor...@me.com>:

[Marc Worrell]

Error numbers are always fun.

Maybe we an name them instead?
With a well-defined atom?

'error_xxx'

- M

[Andreas Stenius]

... and pull down the docs from the console with:

z_err:describe(error_218).

:)

2012/9/20 Marc Worrell <mwor...@me.com>:

[Amiramix]

Thank you Marc. Now it works quite nice! Sorry, I can't help you with the discussion about error handling. I think the dispatch rules in modules with higher priority could overwrite dispatch rules in modules with lower priority, in which case the default rule could be defined in mod_base and then eventually overwritten site per site basis.

[Andreas Stenius]

2012/9/20 Amiramix <li...@gjunka.com>

... I think the dispatch rules in modules with higher priority could overwrite dispatch rules in modules with lower priority, in which case the default rule could be defined in mod_base and then eventually overwritten site per site basis.

It does work like this. The issue here is that the dispatch rules in question are being re-organized...

[Amiramix]

Ah OK, this is then why they were missing in my site.

[Marc Worrell]

It is also a discussion if we _always_ want to have /page/id urls or not.

If we always want them then we can add them to mod_base.

No they are in mod_base_site, which is a bit of overkill for some sites.

What are the opinions on this?

- Marc

[Amiramix]

They should be in mod_admin since mod_admin requires them when editing pages. It's the same story as with base.tpl, which the default logon template require but which wasn't included in a site created from empty skeleton. Everything that a module require to work properly should be included in that module. That's my opinion. Then it may be overridden in other modules depending on priority.

If someone overrides them in the mod_base_site to use in their own site, will it break mod_admin? I think in that case mod_admin could have a higher priority than the site to avoid breaking something in the admin section. It is far less likely someone would actually like to temper with the admin section when changing the site, rather someone may break something by accident without realizing until one tries to login to the admin section. But then it may be too late.

So again, my opinion would be to include those in the admin section components, make admin section higher priority than the actual site, and include them in only selected site templates, e.g. blog, but not empty.

[Andreas Stenius]

I think it's OK to have them in mod_base_site. Perhaps have a dependency from mod_admin on mod_base_site, if that is needed.

(In cases that don't want /page/id url's, do they still use the /admin?)

2012/9/20 Amiramix <li...@gjunka.com>

[Marc Worrell]

We can also collect those almost-for-every-site-needed dispatch rules in a separate module.

Together maybe with some templates that most sites will need but always forget to add (think e-mail stuff etc)

Then mod_base_site can depend on that module.

And we can enable it by default.

mod_admin doesn't need it, it just needs a dispatch rule to show a resource.

That dispatch rule is used by m_rsc, when requesting the page_url property.

(We need a chapter in the docs about all resource properties…)

- M

[Andreas Stenius]

2012/9/20 Marc Worrell <mwor...@me.com>

(We need a chapter in the docs about all resource properties…)

Add a stub, so we don't forget about it. Can always fill it in later :)