This site is past the construction phase, and almost fully functional, but still under development,
as are these notes.

The site is served from a generic LAMP stack using the CodeIgniter (v3) framework (see below).
It is currently hosted on SiteGround of Bulgaria which uses Google Cloud for its domains.

As late adopters, we are using version 3.x, which suits our limited requirements. It is fairly fast and loosely coupled, meaning that its components are not heavily dependent on each other. The examples are good and, importantly, it's the framework that was used to create the original prototype.

from the mysql command line:

	mysql> SHOW VARIABLES LIKE 'version';

					
	+-------------------------+------------------------------+
	| Variable_name           | Value                        |
	+-------------------------+------------------------------+
	| innodb_version          | 2.2.11                       |
	| protocol_version        | 2                            |
	| slave_type_conversions  |                              |
	| tls_version             | TLSv1,TLSv1.1                |
	| version                 | 2.7.8                        |
	| version_comment         | MySQL Community Server (GPL) |
	| version_compile_machine | m68000ZB                     |
	| version_compile_os      | xenix1.12                    |
	+-------------------------+------------------------------+
					

A note about timestamps

And transactions in codeigniter.

Below is a list of tables:

1. Generic website functionality

    ci_sessions    - codeigniter
   
    ip_address     - for blacklist; unused
    language       - list of language codes
    login          - list of user login start and ends; unused
   
    user           - standard user name, email and password plus permissions
    user_forgot    - handle password reset request
   

2. Time travel tour related

   It's helpful to think of the content-specific (tour-based) data as hanging off the tour

    person <- traveler => booking -> tour <= trip -> location (departure and arrival)
   
    media          - an id and a url pointing to all media (currently only images)
   
    event          - historical and possible future events with date and description
    event_media    - media associated with events
    event_topic    - list of topics; unused
   
    period         - list of time periods; unused    
    period_lang    - translations of periods
   
    location       - physical location
    location_code  - types of location
    location_lang  - name of location in other languages; unused
    location_media - pictures of locations
   
    trip           - from -> to location and date, pointing to a tour
    return_trip    - simple return info refered to in any booking with a return trip
    trip_lang      - description of a trip in non-english language
    trip_media     - media associated with a trip
   
    tour           - record description of a tour and (general) location and period
    tour_lang      - alternative language description or a tour
    tour_media     - images of a tour
    tour_topic     - unused
   
    person         - details of a traveler
    traveler       - link a person with a booking
   
    booking        - a tour with departure and optional return dates with travelers
    booking_status - unused
   

3. Enhancements

    promotion      - promotions for tours
    promotion_code - not sure!
   
    forum_activity - very basic forum tables
    forum_category - categories on the forum
    forum_topic    - a forum topic
    comment        - a forum comment
    comment_view   - ratings
   
    bug            - glitch table for ttb utilities
    bug_note       
   
    news           - unused
   

The html returned to the browser is constructed on the server using a single page (in application/views) and a number of smaller units (in the application/views/generaltemplates folder in CodeIgniter)

This can be interpreted as the page that the person sees or (more accurately) as the data that the browser receives (and converts into the page). On the server, Codeigniter (following an http request) generates the html and links.

Nothing unusual. If you load a page you can look at the stylesheets in use. It's possible to modify individual elements or classes using the browser's development tools.

Fallback so that browsers

  @supports(display: grid) {
     .my-class {
      width: auto;
     }
  }

					

When the browser connects to a website that it has visited before, it attaches data (cookies) that the site offered on a previous visit. There's a good explanation here When a user signs in, codeigniter initialises a CI_Session class, available to all programmer-created ci objects (User, Tour, Trip, etc) that stores the user's id, username, email, etc. These are accessed with:

	 $some_value = $this->session->userdata( 'some-key' );
	 				

Below is an example of how a url request, to view a tour, turns into a page on the user's browser.

1. Say a tour has been selected from a list. The link would look like /tour/view/ABC123 (tour id)
2. The php framework resolves tour - view - ABC123 through the router (/application/config/routes.php) which, by default, opens in order of controller/function/argument.
   This resolves to Tour.php, and its public function, view() with 'ABC123' passed as the argument to view().

     public function view($tour_id = '') {
   	 $title = 'Tour - view';
   	 $tour_data = $this->tour_library->get_pending_tour();
   	 $data = hpr_global_data($this, $title);              // helper function creates an associative array
   	 ...
   	 ...  // load tour data 
   	 ...
   	 // create a list of php 'templates' (usually just html snippets)
   	 $templates = array('pickers', 'dialogs', 'tour/trip-description', 'tour/trip-start', 'tour/trip-mid');
   	
   	 // convert the templates into a lists of html and also load default templates
   	 // like the header and footer which contain links to standard styles (ie main.css) 
   	 // and scripts (ie api.js, dialog.js)
   	 $data[ 'TPL' ] = hpr_load_templates_default($this, $data, $templates);
   	
   	 // extend the $data array with our tour data and other info
   	 $data = hpr_js_server_data($data, array(
   		 'tour_id' => $tour_id,
   		 'method' => 'view',
   		 'tour_data' => $tour_data
   	 ));
   
   	 // load (and return) the 'main' view for this method 
   	 $this->load->view('tour.php', $data);
     }
   		
   						

   Note that another
Following the steps in the method, above,

Signed-in users have access to all features of the site, apart from those requiring administrator privileges.
Unregistered users can browse the site, start a booking, or start building a tour, but cannot complete the task until they sign in.

If a session exists (above) it holds the user's id, accessible as:

	 $user_id = $this->session->userdata( 'id' );  // in any controller, or...

	 $user_id = $this->ci->session->userdata( 'id' );  // using the global codeigniter object in a library
	 	 				

It's enough to check that $user_id is true to confirm that there is a valid session.
If there's no session then $user_id is false and we can return an "err_session" error which is caught within Dialog.showErrors(errors) (see dialog.js notes), which prompts the user to sign in.

Articles on cross site request forgery here and here

Currently, users may only join by invitation.
Invitations can be sent by registered users (or admin) and they work as follows:

1. A registered User goes to their profile page and, in the invitations section, click "Invite a new member"
2. The invite_member dialog appears
3. Once completed, and following client-side (javascript) validation, a request is sent to invite_post() in /application/controllers/api/User
4. The invitation is validated and user_library->member_invitation() creates a link that looks like

   						
     Some_Applicant, you have been invited to join timetravelbookings.com by TimeTraveller
   	
   	
     Please go to timetravelbookings.com to accept or decline the invitation..
   
   	
     Regards from the timetravelbookings team
   	
   						

   With a link to: (something like) https://timetravelbookings.com/user/membership/ABC123/?email=some@applicant.com enclosed.

Visitors can request an invitation.

Say a visitor is utterly amazed by the site, but doesn't know any users:

1. Visitor clicks the sign in button
2. A link, at the bottom of the sign in form, says "Request an invitation"
3. The "register" dialog, asking for an email, and a reason for the request calls api/user/request_invitation
4. in User.php, function request_invitation() calls user_library->notify_invitation_request
5. in User_library.php notify_invitation_request() sends an email to admin@... containing the link, below
6. (this_site)/user/invite/some.email@etc.com}/SomeApplicantsName
7. The administrator, clicking on this line, gets a link saying "Just do it manually for now" (because this hasn't been automated)
8. TODO - check if an invitation has already been sent: Job done
9. TODO - create a link which automates the invitation
10. But we haven't automated this process so the administrator must resort to the standard invitation process, described above.

The invitation/registration process:

1. Begin the registration process
2. Javascript client (in register.js) does pre validation
3. Post a username, email and desired password (/application/controllers/api/User/register_post())
4. Server validates further (what if the name & email are already in use? TODO!)
5. /application/controllers/User.php calls ??
6. The registration request is saved as user in the database, with a key?
7. A confirmation link is embedded in an email and sent to the user's address
8. The user opens the link to function register() in /application/controllers/user.php
9. register() marks the user as a bompilgom (pointless invented word)

/tour/create, (as shown above) calls the 'create' function in the /controllers/Tour.php file. In tour.js the postDescription function is called when we want to begin adding trips to the tour.
It wraps the tour description information into a data structure and calls the 'api' function to send it to
"tour/description", this gets converted to a post call to the description_post function in /Controller/api/tour.php

/book/action, (as shown above) calls the 'action' function in the application/controllers/Book.php file. In book.js the postDescription() function is called when we want to begin adding trips to the tour.
It wraps the tour description information into a data structure and calls the 'api' function to send it to
"tour/description", this gets converted to a post call to the description_post function in /Controller/api/tour.php

/form/options, (as shown above) calls index() in application/controllers/Forum.php . A standard forum with structure: category/topic/comment/reply/...(further replies with maximum nesting 2 deep). x x x

ttb is designed with reasonably up to date browser support.
It doesn't work in Internet Explorer, although we lament it's loss.
Phones, once known as "cell phones" or "mobile phones", or the smart variety, tend to support modern browsers.
When a browser client (Chrome, Edge etc) attempts to render html, it uses cascading stylesheets (css) to determine how to layout the page, colour backgrounds, etc. If the browser comes across an instruction that it doesn't understand, it simply ignores it, so this can be used as a fallback mechanism.

					
	.gray-element {
	  color: #ccc;                /* definitely understands this */
	  color: rgba(0, 0, 0, 0.5);  /* if it understand's this, ignore above, otherwise ignore this */
	}
	
	@supports(display:grid) {
	  .some-layout-class{
	    width: auto;		
	  }
	}
					

1. First impressions: How the site appears to the casual user - load and browse:
   Are the images displayed? Do the links work?
2. Try to join: Is the process clear? Does the candidate receive a confirmation email?
   
   • Do the administrators receive an email (for them to clear and forward an invitation)?
   • Does the candidate receive the invitation?
   • Does the link in the invitation register and sign them on?
3. User impressions:
   • Responsive design: Does it resize and work well on mobile devices?
   • Do the dialogs come into view and display correctly?
   • Do the links work?
4. Home page:
   • Timeline
   • Quickbook
5. Timeline:
   • Zooming and panning
   • Event dialog
6. Tours:
   • List
   • Search
   • Create a tour
7. Create tour:
   • List
   • Search
   • Create a tour
8. Static pages:
   • How it works
   • The science
9. Forum:

These are the some common errors:

On the client, javascript errors can be silent. For example, the user clicks a button and nothing happens.

1. Is there a console message? Open the browser's development tools and look for the javascript console.
   Sometimes the button's (or other element's) handler was never attached because an earlier error in the javascript halted execution beforehand.
   For example, in a booking page, does Book exist?
   You can just enter

   	Book						
   							

   in console and it might say "undefined".
   The main javascript objects are listed here

Query errors are uncommon because they tend to be quickly exposed in testing

Example mysql query error:

Here are some tips for local development:

There are many

	log_message('debug', "some message");
						

statements dotted through the code. It is located in /system/core/Common.php (v 3.x) and writes daily files located in /application/logs.
If no log files are generated then it is probably because the file path needs read/write/execute privileges. /application/config/config.php

Great advice that we wish we'd had before we learned by failing, here.

Image cropping here

1. Where needed image containers are built into templates and html like this:

2. When the document is loaded by the browser, javascript invokes uploader.js to attach a handler to a change in the >input type="file" ...< element.
   (see uploader.js)
4. On the server, in controller/application/Upload.php method up() attempts to receive the image, subject to constraints (size, media).
5. up() then calculates the sha hash of the image and looks it up in the media table to determine whether the same file has been uploaded previously.
6. If it exists then we simply return the image's id and url to the client.
7. If it doesn't exist (note the hash would produce different values for the same image that has been resized beforehand) we process the image (creating a smaller version and a thumb) assign an media_id to it and return that id along with the image url and the hash value.
8. The user could abandon their work at this stage and the file would remain, orphaned, on the server, so in Controllers/Upload/up() we also create a record in the media table.

	log_message('debug', "some message");
					

We have traded between simplicity and features. Sometimes we need to provide data to the javascript running in the browser. We do this by creating a template data element vis.

 $data[ '_server_js' ][ 'some_key' ] = $some_data;
 $data[ 'TPL' ] = hpr_load_templates_dev($this, $data, $array_of_templates);
					

the contents of _server_js is converted into useful client readable data before it is downloaded, by writing in the view (/application/views or /application/view/templates):

 <script type="text/javascript">
 <?php if ( isset( $_server_js ) ) { ?>
  var Srv = <?php echo json_encode( $_server_js ); ?>
  console.log("Server.page:" + Srv.page);
 <?php } ?>
 </script>
					

which unwinds to

 <script type="text/javascript">
  var Srv = {"page":"tech-notes"};
  console.log("Server.page:" + Srv.page);
 </script>
					

When form data is posted to the server by calling Api.post(method, callbacks...), the appropriate controller in /application/api is called

  Api.post('book/add_traveler')
					

resolves to /application/api/book.php calling method add_traveler_post()

If an error is returned from the function, via hpr_rest_error(....) then Api calls the error call-back, which usually, in turn, calls

  Dialog.showErrors(errors).
  					

errors is a json data structure built on the server and contains key-data pairs, viz: error-class -> error_message

showErrors() makes any element with class error-class visible and sets the text in that element to error_message then scrolls to the first error, if it's not already in view.

This a list of the main scripts and their objects (all located in assets/js)

They can be downloaded directly as, for example, in the browser:

   https://timetravelbookings.com/assets/js/dialog.js
   				

and then you can chuckle away at our amateur enthusiasm. (We mean well)

1. dialog.js -> Dialog: handles the display of messages confirmations and other dialogs
2. home.js -> Home: mostly used in validating and posting the quick-book section.
3. tour.js -> Tour: displays tour data found in the server-generated Srv javascript object, and captures user input
4. picker.js -> Picker: special purposed dialogs to allow the user to pick locations and dates while creating tours
5. uploader.js -> Uploader: for image uploads (see notes on images)
6. book.js -> Book: works with Tour to display Srv.pending_book data and capture booking information. Note that a booking is a tour with a departure location/date and an optional return location/date, plus travelers.
   Consequently Book is not interested in the first destination or any subsequent trips.
   All these are handled by Tour.
   
7. location.js -> Location: provides a lookup system for the first departure location
8. traveler.js -> Traveler: loaded during the traveler capture step of a booking
9. events.js -> Events manages the timeline, and is not named "Timeline.js" as this class is taken by /applications/timeline.js
10. forum.js -> Forum
11. static.js performs some basic navigation function on the Science and Faq pages

    Note handling anchor is explained here

12. register.js -> Register is unusual because registration is