[title sub="Written by Chris Graham"]Composr Tutorial: Composr site structure[/title]

Composr has a number of interacting systems, that together form the structure and navigation paradigm of your website. This tutorial will provide advanced detail to these systems, and show how they fit together. Users who just want to get content won't need to understand the full details of the Composr structure, but users needing complex navigations will.

To view the structural contents of your website, head over to the Admin Zone > Structure > Sitemap Editor. The Sitemap Editor is a very powerful tool for viewing the zones, pages, and categories within your website, and will help you build up a mental picture of how everything relates.

[contents]decimal,lower-alpha[/contents]

[title="2"]Zones (sub-sites)[/title]

{!zones:DOC_ZONES}

The default zones in Composr are for the following purposes:
 - [b]Welcome Zone[/b] (root directory): this zone gives users the chance to join or login. It could be modified to act more like a 'splash screen' if you desire that
 - [b]Site[/b]: this is your main website; it includes primary content viewing, and permission based submission, editing, and deleting features. The contents of this zone may automatically be merged into the Welcome Zone via the 'Single public zone' option, which will simplify things for you
 - [b]Admin Zone[/b]: this is a section for site staff to manage the site
 - [b]Content Management[/b]: this is where content is added, edited and deleted
And if you are using Conversr, the following additional zones are usable:
 - [b]Forum[/b]: this is where the forum resides

Some further information about zones is covered in the [page="_SEARCH:tut_subcom"]Tools for subsites and subcommunities[/page] tutorial.

[title="2"]Pages[/title]

[media width="150" description="This is a detailed annotated diagram that explains Composr site structure" float="right"]data_custom/images/docs/tut_structure/structure_main.png[/media]
There are a few different types of Composr 'page':
 - [b]Comcode pages[/b] -- these are textual pages, written in Comcode (described in [page="_SEARCH:tut_comcode_pages"]Adding standalone pages of content (via Comcode)[/page])
 - [b]Modules[/b] -- these are formal code-based pages
 - [b]HTML pages[/b] -- these are full static pages written in HTML, and rarely used except for caching purposes (generally we should use Comcode pages with the Comcode [tt]html[/tt] tag instead)
 - [b]Mini-modules[/b] -- these are like modules, except much easier to write; the developers do not use them for core Composr code, as they do not have the same 'API' around them that we need to maintain our clean architecture. But most novice Composr developers may wish to start off using mini-modules as they can simply echo or return out what to show on the page.

A page/zone combination is accessed by URL and it is invisible to the user, and most elements of Composr itself, what kind of pages are being used for any given URL.

The actual page loaded is based on searching the disk's zone directory for files matching the page name (higher on the list = higher precedence):
 - customised module
 - module
 - customised Comcode page (user's language)
 - Comcode page (user's language)
 - customised HTML page (user's language)
 - HTML page (user's language)
 - customised mini-module
 - mini-module
 - customised Comcode page (site default language)
 - Comcode page (site default language)
 - customised HTML page (site default language)
 - HTML page (site default language)
 - (Page is marked as missing and an option is giving to add a Comcode page)
 - Comcode pages should therefore be named not to conflict with the names of modules.

[box="HTML pages"]
HTML pages can be placed in a [tt]pages/html_custom[/tt] directory. It is preferable if URLs in the file are specified in full, rather than using relative URLs; this allows the page to be moved between zones without modification. If you do use relative URLs, they will be placed relative to the Composr zone URL, not the directory the HTML file is in.

Composr will work some magic on the HTML contents (assuming they are enclosed in an [tt]html[/tt] HTML tag like a full HTML page):
 - scans links and tries to find them in the same zone, in [tt]uploads/website_specific[/tt], in the [tt]pages/html_custom[/tt] directory itself, or in the Composr root directory; the link is then rewritten according to where the asset was found
 - extracts scripts, styles, and link elements from the head section of the page (if defined) and feeds them into Composr's screen headers
 - extracts key meta information from the page, if defined, and updates them accordingly on the page in Composr
 - sends the HTML body into [tt]sources_custom/hooks/systems/site_html_pages[/tt] hooks for additional custom parsing and processing
[/box]

If you investigate the Composr directory structure, you will find subdirectories for these page types under a [tt]pages[/tt] directory in each zone. Some of the subdirectories are internally organised according to language, while others distinguish languages within the pages themselves.

[box="[tt]_custom[/tt] directories"]
[media float="right" framed="0" thumb="0"]data_custom/images/docs/tip.png[/media]
You will also notice that all the page type subdirectories have an equivalent [tt]_custom[/tt] suffixed version.

Composr has a convention that any page not supplied in, or edited from, the official zone source, should be placed in a [tt]_custom[/tt] directory: these take precedence over the normal directories, forming an override system.

This system is extremely powerful, allowing you to edit any page in Composr, including modules, but keep track of exactly what you have edited so that problems do not occur during upgrades. Composr even comes with a code editor that will automatically promote files to override directories upon edit.
[/box]

[title="3"]Modules[/title]

Composr comes with dozens of modules as standard. Most Composr pages are actually modules, and most of the Composr database tables and site privileges are created by module self-installation code. Modules also dictate how data is to be upgraded between versions of Composr.

[i]Information for programmers only...[/i]

Modules/blocks that are not locked may be uninstalled and reinstalled from a module management page that is buried underneath the addon management page. We do not recommended working on a module level but if you are a programmer it is sometimes useful to be able to uninstall/reinstall your own modules during testing.

[box="Note" width="25em" float="right"]
Reinstalling or uninstalling a module will generally delete all data associated with it, including uploads and entries.
[/box]
If a module has been upgraded (i.e. The on-disk file has been replaced with a newer version), you may upgrade it (to upgrade/create on-disk and on-database data) in 3 ways:
1) Simply use the module, and it will upgrade itself
2) Run the [tt]http://yourbaseurl/upgrader.php[/tt] script (specifically database upgrade), which will upgrade all modules on your site that need it, as well as clearing caches
3) Use the module management screen to upgrade the module
There is also a concept of a 'hacked' module (a module modified as a part of a non-bundled addon): the process of performing any upgrades an on-disk file needs for this is the same as for a conventional module upgrade.

[title="3"]Entry points / Page-links[/title]

There is a simple standard in Composr for identifying a page accessed by URL, in a way that is not tied down to installation domain and directory, like a URL is. This standard is sometimes called an 'entry point' and sometimes called a 'page-link'; generally, an 'entry point' is a predictable 'page-link' that will work on any Composr installation with the same set/configuration of zones and pages. A 'page-link' on the other hand, might depend on the actual content of the site.

Page-links are commonly seen in their most simple form in the Comcode page editor's list of pages. In this, a page is simply [tt]<zone-name>:<page-name>[/tt]. This is the simplest case, as a Comcode page will never need any parameters (although they could take them, and use them if they contain blocks that do, to the parameter relates to Composr rather than the page itself). Note that the Welcome Zone is given with a blank, and hence just [tt]:<page-name>[/tt] is written for a page in the Welcome Zone.

A more complex case is used in the menu editor, which has the ability to insert any Composr 'entry point' as an item on the menu. An example of an entry point is [tt]site:downloads:type=browse[/tt]. This points to the [tt]downloads[/tt] module in the site zone, and specifies a [tt]type[/tt] parameter to be of value [tt]browse[/tt]; the URL will turn out to be like [tt]http://yourbaseurl/site/index.php?page=downloads&type=browse[/tt] (or something else such as [tt]http://yourbaseurl/site/pg/downloads/browse[/tt] if short-urls are enabled). Note that [tt]type[/tt] is a standard parameter name in Composr, used by almost all modules to segregate internal command (for instance, [tt]browse[/tt] in this case specifies category listing functionality, as opposed to viewing an actual download); the page-link syntax does not handle it any different, but the URL Scheme syntax does.

A more complex case is for a full blown 'page-link' that can not be referred to as merely a standard 'entry point' (as explained above, page-links may depend on the state of content while entry points cannot). An example of this might be [tt]site:downloads:type=browse:id=10[/tt], which is a link to view the download category of ID#10.

It is also worth understanding that page-links have a long-form and a short form syntax. For simplicity I have used the long-form syntax above. The short form syntax allows you to remove [tt]type=[/tt] and [tt]id=[/tt], so long as the parameters match the expected order. You can remove [tt]type=[/tt] from the third component, and [tt]id=[/tt] from the fourth component. So [tt]site:downloads:type=browse:id=10[/tt] will shorten to [tt]site:downloads:browse:10[/tt].

If you do not want to hard-code what zone to use, you may specify either [tt]_SEARCH[/tt] or [tt]_SELF[/tt] as the zone name in the page-link. [tt]_SEARCH[/tt] will cause Composr to dynamically find the module involved, while [tt]_SELF[/tt] will use the same zone as the page-link is dynamically being interpreted in (e.g. If it is used on a menu in the site zone, [tt]_SELF[/tt] will be equivalent to [tt]site[/tt]).

If you have a URL Scheme enabled it can be hard to find out what the URL parameters to a screen are. If you go to [tt]http://yourbaseurl/index.php?keep_url_scheme=0[/tt] then all URLs shown will reveal the raw parameter values (this just happens for you, via the [tt]keep_url_scheme=0[/tt] you temporarily set in your address bar).

For more information on how page-links are turned into URLs, see the [page="_SEARCH:tut_url_schemes"]URL Schemes in Composr[/page] tutorial. This tutorial also contains an example on how to link to the current logged in user's member profile (a common request), as a worked example of how page-links and URL Schemes work.

[title="3"]Panels (and blocks)[/title]

Panel pages rest around your main page. They are nothing more than pages given special names in the same zone as the pages that they surround.

Panels are typically Comcode pages and are used to arrange blocks. Blocks inject dynamic functionality (such as a menu, a login box, a search box, etc): Composr has a large selection to choose from. Blocks are documented in the [page="_SEARCH:tut_adv_comcode_pages"]Using blocks tutorial[/page].

[title="4"]Display rules[/title]

Panel pages won't show if:
1) they don't exist
2) they are empty
3) they are left/right and [tt]&keep_wide=1[/tt]/[tt]&wide=1[/tt] is attached to the URL (i.e. these URL parameters disable panels)
4) [tt]&keep_wide_high=1[/tt]/[tt]&wide_high=1[/tt] is attached to the URL (in this case the header and footer won't show either)

Site owners often want panels disabled on certain pages only. This can be done by surrounding the panel contents with Tempcode like...
[code="Tempcode"]
{+START,IF,{$NEQ,{$PAGE},example_page_1,example_page_2,example_page_3}}
...
{+END}
[/code]
In this case the panel won't show for any of those 3 example pages.

[title="4"]The default theme's panel support[/title]

The special names identifying the panels supported by the default theme are:
 - [tt]panel_left[/tt]
 - [tt]panel_right[/tt]
 - [tt]panel_top[/tt]
 - [tt]panel_bottom[/tt]

The [tt]GLOBAL_HTML_WRAP.tpl[/tt] template defines how these panels fit together along with the main page, i.e. glues them in. Templates are described in the next section.

[title="4"]Default panels[/title]

A default Composr install contains the following panel pages:
 - [tt]:panel_left[/tt]
 - [tt]:panel_right[/tt]
 - [tt]:panel_top[/tt]
 - [tt]:panel_bottom[/tt]
 - [tt]site:panel_left[/tt]; only applicable if the "Single public zone" configuration option (Admin Zone > Setup > Configuration > Site options > Structure) is off
 - [tt]site:panel_right[/tt]; only applicable if the "Single public zone" configuration option (Admin Zone > Setup > Configuration > Site options > Structure) is off
 - [tt]forum:panel_right[/tt]

All zones are set up to share [tt]:panel_top[/tt] and [tt]:panel_bottom[/tt], due to some default transparent redirects set up under Admin Zone > Structure > Redirects.

[tt]:panel_top[/tt] is actually blank by default. The top menu and so on actually comes in directly via blocks referenced in the [tt]GLOBAL_HTML_WRAP.tpl[/tt] template because we wanted tightly-defined layout for the default top blocks.

[tt]:panel_bottom[/tt] places a bottom bar, but only on certain pages (the logic for this is coded up within the panel, so is customisable).

[title="4"]Supreme flexibility[/title]

I want to reiterate that the use of panels is fully configurable. Composr simply searches for the pages, respecting any configured redirects also.

You may add panels not bundled, such as [tt]forum:panel_left[/tt] just by adding such a Comcode page to the system.

You may add totally new panels by editing [tt]GLOBAL_HTML_WRAP.tpl[/tt] to reference them.

If you are a programmer, note that they don't even need to be Comcode pages: you could write a PHP module if you wished.

[title="4"]Boxes[/title]

[media width="150" description="A box (created with Comcode in this case, but you can't tell)" float="right"]data_custom/images/docs/tut_structure/box.png[/media]
Most of the default block templates put a box around the block to make things appear clear/regular. Most designers don't like the "boxy" look, however.

If you'd like to make things more subtle, with headers and dividers, wrapping this Comcode around the block(s) automatically activates some overriding styling:
[code="Comcode"]
[surround="boxless-space"]
...
[/surround]
[/code]

The box and de-boxed styles are not Composr "features" per-se, it's just a part of our default theme's CSS/templates, and a convention baked in there. Ultimately the web designer has full control with Composr by editing CSS/templates.

[title="4"]The Zone Editor[/title]

[surround]
[media width="150" description="The Zone Editor" float="right"]data_custom/images/docs/tut_structure/structure_zone_editor.png[/media]
{!zones:DOC_ZONE_EDITOR}

The Zone Editor can be reached from:
Admin Zone > Structure > Block/panel layout (Zone Editor).
[/surround]

The Zone Editor is used for coordinating layout of blocks across the panels in a zone, but not for general-purpose content editing. If you want a better editor to put detailed content into a panel you should edit it individually as a Comcode page.

[title="3"]Templates[/title]

[media width="150" description="This is a detailed annotated diagram that explains basic Composr template structure" float="right"]data_custom/images/docs/tut_structure/structure_templates.png[/media]
So far we have established that the website consists of zones, that contain pages (which may be of various types); and that some pages are panels, surrounding other pages, and that panels usually are made of blocks. This together, defines one view of the structure of a Composr-driven website.
This might seem bewildering, but after you get used to it, it will make perfect sense.

Another view of the structure of a Composr-driven website is that of the composition of templates. Templates are sections of HTML that are used (basically) to structure the visual output of your site. Blocks, modules and the Composr layout system that binds menus, use templates directly, to structure the data they wish to output; for example, the login block needs to give the username of the currently logged in user: this, along with a lot of other data, is passed into various templates. Templates are attached together, such that one template may follow on from another, or actually be embedded in one another. Comcode pages also use templates in a sense, but Composr itself decides what templates to use to display the Comcode involved. And, Composr uses templates throughout its own internal code, for countless situations, such as displaying an error message, or generating a screen title.

As mentioned previously, the two common ways templates are joined are:
1) attaching/appending one to another: this is called attaching
2) embedding one (or various, attached together) into another: this is called wrapping
Both are used: although if we wished, we could have avoided embedded, having a combination of both techniques produces the most attractive solution.

A simplified view of the part of the Composr template tree that is common across all pages is:
 - GLOBAL_HTML_WRAP
  - PANEL_TOP (optional)
   - ...
  - PANEL_LEFT (optional)
   - ...
  - (main page)
   - SCREEN_TITLE
   - (main pages wrapping template, and a lot more)
   - PANEL_RIGHT (optional)
    - ...
   - PANEL_BOTTOM (optional)
    - ...
When something appears beneath, on the same level, it has been attached. When one of more things appear a level deeper, they have been wrapped. As a tree structure, it is built up from the most deep parts of the tree, and wrapped/attached all the way back until the final composition exists: and then it is output.

[title="4"]Wrapping[/title]

A good example of a 'wrapping' template is [tt]GLOBAL_HTML_WRAP.tpl[/tt]; it embeds the full menu and central pages, along with the common header/footer, in a certain way, to make them lay out appropriately.

If we look into the [tt]GLOBAL_HTML_WRAP.tpl[/tt] template we can see it contains:
[code="Tempcode"]
{MIDDLE}
[/code]

'MIDDLE' is a template parameter (it contains the main page contents). By referencing the parameter the template had essentially ended up wrapping it. This has the effect of putting the header/footer/etc around the main page contents.

[title="4"]Attaching[/title]

A good example of a template designed to be attached is the situation where one template is repeated many times: a template that shows a single item in a list of things is likely to be used like this.

Attaching is almost always done in the PHP code, so I won't show an example of this in action.

[title="4"]HTML[/title]

A third view of the structure of a Composr-driven website, is that of the HTML itself. HTML forms its own tree structure, which is actually similar to how the final Composr template tree looks before it is output.

[title="2]The Sitemap and overall website structure[/title]

The Sitemap binds all the different screens within a Composr site together into a single tree structure. Composr never saves the Sitemap -- it generates it dynamically by pulling together the various parts of the Composr system in a pre-determined way.

Composr uses the Sitemap:
 - to generate the drop-down menus: the main website one (by default) and the one used in the Admin and CMS zones
 - to generate the Sitemap shown to users on the sitemap page
 - to generate some content selection lists
 - to generate the XML Sitemap provided to search engines
 - to display the structure to you in the Sitemap editor and Permissions tree editor

The Sitemap generally reflects the actual structure of your website, and works roughly on these levels:
(Root)
 - Zone
  - Page group
   - Page
    - Entry-point
     - Category
      - ...
       - Entry

Zones are the first level and operate as different top-level security contexts, and potentially have different panels, a different theme, and different navigations.

Page groups are hard-coded with what we consider a sensible way to organisation for the different pages on the site. We do expect advanced users will not use the Sitemap directly in menus, so the hard-coding should not be a problem, just a tidy structure to start from. When you want to take full control of menus you can choose to copy the defaults into a new editable menu, and start manipulating it.

Composr supports 'redirects' which let you have pages within multiple zones. This will reflect on the Sitemap.

[title="3"]Sitemap philosophy[/title]

As a module-based CMS, the Sitemap isn't fully configurable, but rather mirrors the structure of your website's functionality. A module-based CMS has a number of advantages, particularly that it is able to organise a lot of rich functionality for you automatically, without forcing you to create a complex structure that is hard to understand or manage.

The disadvantage of a module-based CMS is that it does impose a structure on you that may not match what you ideally want. This is why you can:
1) choose to define your website navigation and breadcrumbs separately from the Sitemap, including in parts of the Sitemap into your own structure as required
2) use virtualisation features to make content appear in places other than the primary Sitemap position (transparent redirects, and virtual roots)

You therefore get the benefits of rich, automatically-organised, functionality -- with the benefits of full structural control in the cases where you need it.

[title="3"]Other kinds of website structure[/title]

Not everything in Composr comes from the Sitemap, although in most cases the data used to generate the Sitemap is also used for generating these alternate kinds of website structure.

It is a good idea to have some awareness of the different kinds of structure Composr will make use of.

[title="4"]Breadcrumbs (advanced)[/title]

[surround]
[media width="150" description="Editing the breadcrumbs XML" float="right"]data_custom/images/docs/tut_structure/breadcrumbs_edit.png[/media]
[media width="150" description="Sample breadcrumbs" float="right"]data_custom/images/docs/tut_structure/breadcrumbs.png[/media]
Breadcrumbs are a kind of navigation mechanism used in websites to go to the upper levels (basically backwards) while navigating through a site. Composr supports breadcrumbs across the whole system.

Composr has a fully customisable breadcrumbs navigation system. This is done using the breadcrumbs editor, which involves editing an XML file. Webmasters can edit the XML file from:
Admin Zone > Structure > Breadcrumb overrides

It allows you to extend/amend breadcrumb chains for a screen by adding a new entry to the XML file, with powerful wildcard matching (PHP regular expressions). It is, however, advanced functionality and requires a rudimentary understanding of XML and a strong understanding of Composr page-links.

For example...

If you add a new gallery named [tt]example_distorted_gallery[/tt], there will be a default breadcrumbs to that particular gallery. We can change the parent links by adding the following code to the XML file:
[code="XML"]
 <substitution label="Distorted gallery" match_key="site:galleries:browse:example_distorted_gallery">
     <link label="Our page">site:page_for_distorted_gallery</link>
 </substitution>
[/code]
[/surround]

[surround]
[media width="150" description="Breadcrumbs after change" float="right"]data_custom/images/docs/tut_structure/breadcrumb_after.png[/media]
[media width="150" description="Breadcrumbs before change" float="right"]data_custom/images/docs/tut_structure/breadcrumb_before.png[/media]
What the XML means:
 - The [tt]match_key[/tt] attribute represents the page-link to match against. This is where we're targeting our new set of parent links to, replacing the old set of parent links.
 - The [tt]label[/tt] attribute in the "substitution" tag represents the label to give the matched page in the breadcrumbs ([tt]substitution[/tt] tag) or the inserted link ([tt]link[/tt] tag).
 - The [tt]skip_if_single_public_zone[/tt] attribute in the "substitution" tag makes the rule only apply if the single public zone option is off, if set to "true". Defaults to "false".
 - The [tt]include_self[/tt] attribute in the "substitution" tag makes the rule include the node being substituted, if set to "true". Defaults to "true".
 - The [tt]final[/tt] attribute in the "substitution" tag makes the rule the last rule that will apply, if set to "true". Defaults to "false".
 - The [tt]link[/tt] tag is used to specify all the different links which will show above the matched page (the parent links). The webmaster can give as many links as they need but we've just given one here.

After saving customising the breadcrumbs, the updated breadcrumbs will be applied. See the screenshots for the before/after.
[/surround]

[title="5"]Implementation details (more advanced)[/title]

The Sitemap system is not actually used for breadcrumbs, but the data is sourced from the same places in most cases. It may vary due to:
 - breadcrumb customisations
 - added process depth (for example, when running a wizard, the breadcrumbs may reflect your depth within that wizard)

We don't use the Sitemap for the breadcrumb generation because it is generated by going backwards, rather than branching forward.

[title="4"]URLs[/title]

URLs form another kind of website structure.

URLs are are covered in these tutorials:
 - [page="_SEARCH:sup_how_internet_works"]How the Internet actually works[/page] (web technology in general)
 - [page="_SEARCH:tut_seo"]Improving your search engine ranking[/page] (monikers)
 - [page="_SEARCH:tut_url_schemes"]URL Schemes in Composr[/page] (short URLs)

URLs to most content are customisable (via editing of monikers), so while they do tend to reflect the zone and page the content is in, it may be altered.

There are a number of different schemes for generating URL structures.

[title="4"]The Repository[/title]

The Repository has its own structure. The repository is a directory/file view of a Composr website. It is a kind of mix of the Sitemap structure, and a Unix directory structure.

See [page="_SEARCH:tut_repository"]The Composr Enterprise Repository[/page] for more information.

[title="4"]Disk structure, and the database[/title]

There is also the structure of your files on disk. The structure of the pages is described under "Pages" above, and you may wish to consult the [page="_SEARCH:codebook"]Code Book, contents and introduction[/page] for more information on Composr's structure. There is no on-disk representation for most Composr content, as it is stored in the database, using a relational database schema (the actual tree structure is generated out from this flat database structure).

[title="3]The Sitemap editor[/title]

{!zones:DOC_SITEMAP_EDITOR}

The Sitemap editor can be reached from:
Admin Zone > Structure > Sitemap editor


[title="2"]Navigation mechanism overview[/title]

Composr includes a rich collection of navigation mechanisms to help you and your visitors quickly move around your website.
The main forms of navigation are:
 - Menus; these are the main menus that are either controlled by the menu editor or automatically generated from the sitemap. Menus are the main way for navigating around a site.
 - Assorted links; links are placed all over the system to allow navigation between areas and often provide far more detailed navigation than menus could provide (for example, clicking on a username hyperlink would normally take to that you to that member's member profile). The assorted links used can be much more ad hoc and unstructured than the main menu navigation.
 - Control actions; many 'view' style pages provide 'Control Actions' boxes that include links associated with the management of the entry or category you are viewing -- for example, the screen for viewing a download would include a link to edit it in the control actions box
 - Do-next menus; these are the menus in the Admin and CMS zones that provide icons, shown if you don't go direct to somewhere via digging through multiple-levels of the drop-down menu, or after performing an action
 - The breadcrumbs; these are the links that allow you to navigate backwards along modules or site sections that support tree structures -- for example, if you were deep within the download system then breadcrumbs would be displayed allowing you to quickly go back to any of the categories underneath the category you are currently at, all the way back to the root category
 - Footer buttons and links; various buttons and links are placed into the footer, via the code in the [tt]GLOBAL_HTML_WRAP.tpl[/tt] template. These usually perform site-wide "utility" functions, a convention on many websites.

[title="2"]Redirects and virtual roots[/title]

Information about redirects and virtual roots is covered in the [page="_SEARCH:tut_subcom"]Tools for subsites and subcommunities[/page] tutorial. These features are also relevant to structural management of your website.

[concepts
 1_key="Page-link"      1_value="A special syntax that is like 'a Composr URL' that is written in a simplified form, local, and not tied to PHP/Composr URL reality (so if Composr URLs start to look different, Page-links still work)"
 2_key="Zone"           2_value="A sub-directory of Composr that stores pages and has separate configuration (including permissions)"
 3_key="Page"           3_value="A Composr site consists of pages, and some pages (mainly modules) consist of multiple screens"
 4_key="Screen"         4_value="An actual screen that could be roughly categorised distinctly from all other screens (e.g. the backup system has a screen to start a backup, and a screen to view the results)"
 5_key="Module"         5_value="A Composr page that is written in PHP to a very strict structure"
 6_key="Mini-module"    6_value="A module that is easier to write, but less powerful (it has no installation support, for example); it has full access to Composr's API but not having to follow any particular structure (to output just [tt]echo[/tt] or [tt]return[/tt]); the block equivalent of a mini-module is a mini-block"
 7_key="Zone editor"    7_value="A unified zone and panel editor"
 8_key="Sitemap editor" 8_value="A frontend for viewing and manipulating all content on the website"
]Concepts[/concepts]

[title="2"]See also[/title]

 - [page="_SEARCH:tut_subcom"]Tools for subsites and subcommunities[/page]
 - [page="_SEARCH:tut_menus"]Customising what's on the menus[/page]
 - [page="_SEARCH:tut_comcode"]Comcode and the attachment system[/page]
 - [page="_SEARCH:tut_adv_comcode"]Advanced Comcode[/page]
 - [page="_SEARCH:tut_comcode_pages"]Adding standalone pages of content (via Comcode)[/page]
 - [page="_SEARCH:tut_adv_comcode_pages"]Using blocks[/page]
 - [page="_SEARCH:tut_repository"]The Composr Enterprise Repository[/page]
 - [page="_SEARCH:tut_url_schemes"]URL Schemes in Composr[/page]
 - [page="_SEARCH:tut_adv_structure"]Advanced site structure and flow[/page]

{$SET,tutorial_tags,page_management,core_zone_editor,breadcrumbs,Structure and navigation,regular}{$SET,tutorial_add_date,Aug 2008}{$SET,tutorial_summary,An explanation of the Composr systems that together form the structure and navigation for Composr-powered websites.}[block]main_tutorial_rating[/block]
