Coppermine Photo Gallery v1.5.x: Documentation and Manual

Table of Contents
No translation available

Editing the documentation

Target audience

This part of the documentation is not meant for end users of Coppermine, but only for developers. There is no support for this section, it comes as-is.

Edit existing documents

To edit existing documents, simply use your favorite plan text editor - it is all plain HTML plus the JavaScript navigation

Add new documents

To add new documents, follow the steps below:

Moving content from one document to the other

When moving content from an existing document to the other (or into a new one), you have to make sure that the links that point to it get moved as well. To do so, search the entire documentation and the coppermine core code for the anchor name and change them to reflect your changes in the documentation.

Hidden features

To display the content of a particular page of the documentation without the page header, logo, table of contents, search form and footer, add the URL parameter hide_nav=1 to the URL. This is meant to allow displaying content within an iframe or similar. Currently, this feature is being used in the installer only.

Database structure

The documentation file dev_database.htm contains documentation about Coppermine's database structure. It's important to keep that piece of the documentation in sync with the actual database changes, i.e. if a dev changes something at database level by editing sql/basic.sql, sql/schema.sql or sql/update.sql that has an impact on the database schema, the documentation has to be updated as well, preferably with the same commit.

Header & footer blocks

Each "regular" file in the documentation needs to contain the header and footer blocks that will be replaced using JavaScript with additional chrome. If you're interessted how this is done, please review ./docs/en/script.js. The only important thing to keep in mind is that the section
<h1 id="docheader">Coppermine Photo Gallery v1.5.x: Documentation and Manual</h1>
<div id="toc">
<a href="toc.htm">Table of Contents</a>
</div>
needs to be preserved right after the <body>-tag.
In a similar manner, the footer section
<div id="doc_footer">
	<div class="doc_info_wrapper">
		<span id="doc_last_changed">$LastChangedDate: 2009-05-27 20:18:54 +0200 (Mi, 27 Mai 2009) $</span>
		<span id="doc_revision">$Revision: 6003 $</span>
	</div>
</div>
right in front of the closing </body>-tag mustn't be edited nor removed.

Documentation internationalization

To help translators come up with valid translations of the docs some extra JavaScript goodies have been added: if a file in a non-english branch of the docs (e.g. "de" -> German) get's added initially in English as a preparation for the translation, the translator or maintainer is encoraged to edit that file (e.g. ./docs/de/example.htm) and add <div id="doc_en_only">No translation available</div> into the body right after the div blocks that compose the header and menu. This block will be replaced using JavaScript/jquery with a more advanced text that explains the document's temporary stage and that translations are welcome. That text can be edited per language in ./docs/yourlanguage/script.js in the function definition for cpgDocTranslationWarning. The maintainer of that language is welcome to add a link to a corresponding thread on the support board.

To mark such documents in the localized, non-English menu, you can use the class en, e.g. like this:

<li><a href="example.htm" class="en">Foo bar</a></li>
will result in

To enable translators to come up with the navigation structure in advance, you can use the CSS class nolink to make a link go "blind", i.e. make it do nothing when clicked, as in this example:

<li><a href="example.htm" class="nolink">Foo bar</a></li>
will result in
Go ahead and click the link to see what happens then: nothing. Keep in mind that this will only work if JavaScript is enabled. If it is disabled, the link will of course lead to it's target no matter what.

If particular anchor targets haven't been finished yet, you can use the CSS class cancel to display a cancel icon like this:

<li><a href="example.htm" class="cancel">Foo bar</a></li>
will result in

To make sure that temporary content doesn't ruin the google page rank or clutters the search result, you should instruct the robots not to index temporary pages - this is done by adding the corresponding meta tag to the file's HTM header:

<meta name="robots" content="noindex" />

Subsequently, if a temporary document get's permanent, the meta tag should be removed.

Expandable/collapsible "detail"-blocks

As the documentation is using the jquery framwork and some little plugins for ease of use, it's possible to come up with expandable/collapsible blocks that the end user can click on to read details. This can help to maintain a clear document structure.

The used technology falls back nicely if JavaScript is disabled: the block are expanded out of the box and get collapsed on page load by JavaScript - if JavaScript is disabled, the blocks stay expanded no matter what.

To create such a block, you need to come up with two container elements that need to be one after the other (no tags between them):

<span class="detail_head_collapsed">Details</span>
<div class="detail_body border1">
	Content that is collapsed on page load and will get expanded if the visitor clicks on the "details" container above.
</div>

You can have several of those blocks on a page. To obtain a control that can manipulate all of them, you can use

<button type="button" class="button detail_expand_all" name="expandalltop" id="expandalltop" onclick="return false">
<img src="../../images/tree/plus.gif" width="9" height="9" border="0" alt="" title="Expand All" />Expand all details
</button>
<button type="button" class="button detail_collapse_all" name="collapsealltop" id="collapsealltop" style="display:none;" onclick="return false">
<img src="../../images/tree/minus.gif" width="9" height="9" border="0" alt="" title="Collapse all" />Collapse all details
</button>

You need to pay attention to anchors that you might want to use within blocks that are collapsed on page load. Let's assume you have this content on a page named example.htm:

<span class="detail_head_collapsed">Details</span>
<div class="detail_body border1">
	Some content that can be accessed using an anchor.
</div>

Such a construct will not work if accessed using a link like this: <a href="example.htm#foo">. That's why a GET parameter named "expand_all" has been added that will expand all collapsed blocks on a page if set to 1. Subsequently, the example link would have to be <a href="example.htm?expand_all=1#foo">

Help

Obviously, the content of the docs folder within coppermine is the place where the documentation is being kept. But apart from that, the docs serve as core for the help system that resides in Coppermine itself (help for the actual application, embedded into the actual application). This being said, here's how the help system currently works: from any PHP-driven file within Coppermine, the help is being populated using the function cpg_display_help that is being defined in include/functions.inc.php. This function creates the needed output and determines wether the gallery admin has enabled help or not.

The minimum code to display help would be
$my_help =  cpg_display_help('f=empty.htm&h=' .
            urlencode('Hello world') . '&t=' .
            urlencode('This is the detailed text of the help window'),
            200, 100);
echo <<< EOT
Foo bar {$my_help}
EOT;
In case the amount of of characters might get bigger we should disguise the URL a little, using this code
$my_help =  cpg_display_help('f=empty.htm&base=64&h=' .
            urlencode(base64_encode(serialize('Hello world'))) . '&t=' .
            urlencode(base64_encode(serialize('This is the detailed text of the help window'))),
            200, 100);
echo <<< EOT
Foo bar {$my_help}
EOT;
should do the trick.
This is of course not a real life example, as there mustn't be hard-coded text in the code, so the result would look like this:
$my_help =  cpg_display_help('f=empty.htm&base=64&h=' .
            urlencode(base64_encode(serialize($lang_example['hello_world']))) . '&t=' .
            urlencode(base64_encode(serialize($lang_example['hello_world_details']))),
            200, 100);
echo <<< EOT
{$lang_example['bla']} {$my_help}
EOT;
With this coding, the help text would come from the language file, so this option only applies for very short help section.
The second (and recommended) way to display help is by refering to the documentation - the function cpg_display_help and the subsequent file help.php are designed for exactly that purpose. All you have to do in your function call is refering to the file name of the documentation section that you want to refer to and the anchor tags that you refer to:
$help = ' ' . cpg_display_help('f=your_file.htm&as=foo_start&ae=foo_end&top=1', '600', '300');
Would refer to the file ./docs/en/your_file.htm and inside that file to the section between
<a name="foo_start"></a>
and
<a name="foo_end"></a>
You don't have to take care of i18n in this case - if the end user's language preference is French and there is a file ./docs/fr/your_file.htm, the end user will see the content taken from that file. The english version of the docs is the default that the help function fallbacks to if there is no help available in the user's prefered language.

Start and end anchors needed

From what has been said so far it should be obvious that every section of the documentation that could be used as help section from within the Coppermine interface needs to be wrapped into a start and end anchor tag. It's not advisable to rely on the order of sections on a documentation page to be preserved - chapters might be added or removed.

Examples

Good example:
docs/en/your_file.htm <a name="food"></a>
<h1>Food</h1>
<p>Here's a list of things that you can eat.</p>
<a name="food_fruit"></a>
<h2>Fruit</h2>
<p>Apples, bananas and cherries are all fruit.</p>
<a name="food_fruit_end"></a>
<a name="food_veggies"></a>
<h2>Vegetables</h2>
<p>Cucumber, carrots and peas are vegetables.</p>
<a name="food_veggies_end"></a>
<a name="food_end"></a>

example.php $help = cpg_display_help('f=your_file.htm&amp;as=food_fruit&amp;ae=food_fruit_end&amp;top=1', '600', '300');
Bad example:
docs/en/your_file.htm <a name="food"></a> <h1>Food</h1> <p>Here's a list of things that you can eat.</p> <a name="food_fruit"></a> <h2>Fruit</h2> <p>Apples, bananas and cherries are all fruit.</p> <a name="food_veggies"></a> <h2>Vegetables</h2> <p>Cucumber, carrots and peas are vegetables.</p>

example.php $help = cpg_display_help('f=your_file.htm&amp;as=food_fruit&amp;ae=food_veggies&amp;top=1', '600', '300');

Adding anchors to headings

In the documentation for cpg1.5.x, nearly every heading (from <h1> to <h6>) should contain a leading anchor tag and a trailing link to that section. This way, supporters can easily spot the anchor that they need to refer to - just click on the trailing link icon in a heading and then copy the URL from the address bar and paste it into the support posting.

That's why it's advisable to add anchors to all sub-sections of the documentation that could serve as online help or that a supporter might want to refer to.

<a name="anchor"></a>
<h2>
    Heading text
    <a href="#anchor" title="Link to this section">
        <img src="images/anchor.gif" width="15" height="9" border="0" alt="" />
    </a>
</h2>
or (for space saving and easier search/replace actions) rolled into one line:
<a name="anchor"></a><h2>Heading text<a href="#anchor" title="Link to this section"><img src="images/anchor.gif" width="15" height="9" border="0" alt="" /></a></h2>

Code

There are several ways to display code snippets inside the docs:

Combining HTML tags and CSS classes

The CSS classes and HTML tags that make sense (e.g. <textarea> and smallcode) can and should of course be combined.
Example:

No syntax highlighting

For the sake of easier i18n, you should not use syntax highlighting, as that causes too much extra work for translators!