Contents |
[edit] IBEST Website
This page is dedicated to the development and maintenance of the IBEST Website. A traveler, if you will, for any future developers of the site. During development, I have been using other pages to keep my development notes, but it only makes sense to make a page that users and the core of IBEST can interact with.
The IBEST Website was started by Rob Lyon (and others to my understanding), and is maintained by members of the technical staff of IBEST. Currently, myself (Colby) and others are working to improve the site.
The latest addition around mid March this year was a face lift and additional content. This was Phase 1 in what will probably be infinite steps, but there will be important steps following.
Phase 2 was developing a dynamic content management system (DCMS or CMS) in the style that wiki users are already used to. The best way to define a DCMS to non-savvy users is by using current examples, like IBEST Wiki, Wikipedia of course, WordPress, Drupal (a much more closely related idea to the new IBEST website), and others. What many of these have in common with the IBEST website is that they are PHP frontends, with extensions into a MySQL database backend. PHP and MySQL are a effecient matchup, proven to be one of the most resource efficient ways to implement website databases.
Although not as visually appealing and WYSIWYG as some DCMS's like Square Space, the system has a balance of usability for non-savvy users, and scalability for technically inclined folks. It allows custom web designs using templating, so that it can take the shape of a normal HTML website without a lot of additional effort. Once the visual aspect of the site is taken care of by a web designer, the content itself can be updated by people who don't know html. That is pretty much the main point of making the whole system.
[edit] Acquiring a Distribution
Currently, I supply a distribution on my own private development server. Once the software reaches an acceptable point, the source will probably be moved to source forge. The distribution target is at http://76.178.163.24:90/IBEST_DCMS_DIST.tar.
You are completely on our own using this software. If you have problems and work for IBEST, I can answer questions and correct bugs. I need beta testers, so I am completely open to people using the software. Hopefully, this wiki page will provide any answers to problems that may develop.
[edit] Installing
First, implement your security by placing htaccess protection in the passwd and home/tool directories.
Edit your home/db_config-default.php file to use your mysql server settings. Change the file name to db_config.php . Preferably, use a user account for the mysql server that only has the 'select' permission.
Edit your home/tools/db_admin.config-default.php similarly. Use a mysql user account that has admin privileges: 'select', 'insert', 'delete', 'create', and 'update'. Save the file as db_admin.config.php .
Make sure your MySQL server already has the database you specified in both files. This is the $db variable you have set in the files.
Navigate to the home/tools/install.php . No errors should display.
Navigate to home/tools. You should be redirected to home/tools/select.php. From here, the install should be complete, and you should be able to start setting up your site with content!
[edit] Technical Documentation
The latest and greatest version uses html arguments listed after index.php to identify which page the browser would like. index.php has 3 main function:
display_header() display_content() display_footer()
That is actually exactly how the index.php file looks (well, leaving out a few include statements). This is also how the diagram looks when the page is displayed. These three sections are determined by how the current visual template for the site handles them. Libraries of functions in the distribution help visual template designers access the functionality of the system. Users of the DCMS then specify which visual template to use, and then write content in wiki syntax for different pages.
Other features include an event tool, a project tool, an upload image tool, a templating tool (for creating HTML templates in the content itself, in case the included libraries are insufficient), and moduling.
The event and project tools are just ways for users to insert each into the database, so that they can be repeated on the website and not in the actual content.
The upload image tool allows users to keep web images to display on the website on the server. This makes linking images into the content quicker and more intuitive.
[edit] Templating
The template tool allows savvy users to write in html on the webpage. It also allows them to setup variables within the template that can change when written in the actual page content. For example, if you wanted to write:
<table bgcolor=blue>
<tr>
<td>People Names</td>
<td>People Positions</td>
</tr>
</table>
~and
<table bgcolor=blue>
<tr>
<td>Animal Names</td>
<td>Species</td>
</tr>
</table>
-instead of writing that twice on two different pages, with no blue option, as:
{||
People Names
|
People Positions
||}
-you could make a template called table blue as:
<table bgcolor=blue>
<tr>
<td>{{{variable 1}}}</td>
<td>{{{variable 2}}}</td>
</tr>
</table>
-and then write the content on the webpage as:
{{blue
~
Table Label1
~
Table Label2
~
}}
-changing the table labels on each page. This saves writing the html in full, and repetition.
This is very similar to what wikiMedia does, with some changes in the syntax a little (using the ~ character instead of whatever they use).
[edit] Moduling
Modules allow tech savvy users to include their own libraries of tags, and own tag functions for how to display them on the website. Identical to just using templating, except one can include their own PHP code as well. Modules will also allow developers to specify their own tools for the website (like the events tool), without having to update the main source that could get reset during an upgrade. This last feature almost completed for the next site revision.
This level of involvement requires respect of the operation of the DCMS's parsing grammar, and knowledge / proficiency with implementing PHP on a live website. Developers can get themselves in trouble here, so there are things to consider:
Parsing Grammar - these rules are something I am guilty of violating in a few instances, but should be adhered to nonetheless. Your tags should be placed in a file called tagConfig.php, in a folder named after your module's name. Create handler functions in a file called functions.php . Place that folder in the modules folder in the website's main directory. Your module will then be included automatically. While making a tag for wiki syntax, there are some things here specifically to consider. Don't make a tag that already exists in the main tagConfig.php file. The data structure is a PHP array of arrays, and identical keys are not allowed. Don't make a tag that has an existing tag within it. This should be handled correctly and the longest tag in the library should be selected, but hasn't been the case in some instances. And is probably bad grammar to be avoided. Don't use characters that are commonly used in regular human language; creating a tag for the single quote symbol would cause confusion. The same probably goes for all single characters; someone is bound to use them accidentally.
One should also note the syntax of the regular expression analysis in the parser. There are several different types of tags. They are considered to be symmetrical tags (the opening and closing tag are the same tag), except for the ones defined as asymmetrical:
- nested
- asymmetrical
- unary
- inline
When creating tags, try to find a definition type that exists that is similar in the main, and emulate it. Then create the handler functions.
Nested - the default type. Means it can be interpreted within an asymmetrical tag expression. Although all other tags can be as well, so this is more of a moot type. In the definition, define a start handler and end handler function, and the type.
Asymmetrical - as the name implies, tags that are not the same as opening and closing tags. Define two tags (the start and end tags). For the start tag, call your type \<start tag\>asym_open . So for the new tag ~%, the type would be ~%asym_open . Set your start handler to your start function you've made, and set the end handler to 0. For the closing tag, call the type \<end tag\>asym_close . Set the start and end handlers to 0.
Unary - means no end tag will be looked for, so it doesn't actually modify text on the page usually (like the break tag in html). Define the type as unary, and the start handler to the start function.
Inline - this tag is like an asymmetrical tag, but its end tag is a newline. This allows the newline character to actually be two tags, the break tag and the end tag for inline tags. Call the type inline, set the start handler to your start function, and end handler to 0.