#General Feedback
##Large Methods
Some of the class methods are really large - e.g. `ChessGame ::get_legal_moves_list()` which consumes ~150 lines. There is a lot of redundancy - especially in the code to assign `$directions_list`. That code should be moved out to a separate method. Generally whenever a method goes beyone ~10-15 lines you should consider refactoring it. In addition to readability it will also help with testing.

In that method, there are 4 calls to `ChessGame::add_slide_and_slidecapture_moves_to_moves_list()` and those could all likely be simplified to a single call whenever the piece type is `bishop`, `rook`, `queen` or `king`. 

    //the array below could be stored in a constant - e.g. CAPTURABLE_PIECE_TYPES
    else if ( in_array($piece->type, array('bishop', 'rook', 'queen', 'king')) {
        //getDirectionsListForPiece is a method that could accept the piece object, or it may be simpler to pass $piece->type
        $directions_list = $this->getDirectionsListForPiece($piece); 
        $moves = $this->add_slide_and_slidecapture_moves_to_moves_list($directions_list, 7, $moves, $piece, $color_to_move, $board);
    }

Because `$directions_list` doesn't appear to be used later in that method, perhaps it could be removed from the list of arguments for all methods that accept it, and those methods could fetch it when necessary.

###Redundancies
Looking at those methods like  `ChessGame::get_squares_in_these_directions()`, `ChessGame::add_capture_moves_to_moves_list()`, `ChessGame::add_slide_and_slidecapture_moves_to_moves_list()` we see the array `$xy` declared - sometimes even in a `foreach` loop!:

    $xy = array(
        'north' => array(0,1),
        'south' => array(0,-1),
        'east' => array(1,0),
        'west' => array(-1,0),
        'northeast' => array(1,1),
        'northwest' => array(-1,1),
        'southeast' => array(1,-1),
        'southwest' => array(-1,-1)
    );

This goes against the **D**on't **R**epeat **Y**ourself principle (i.e. **D.R.Y**). It would be wise to put that initial value in a constant - maybe even store the value after it is flipped (via `ChessGame::convert_from_xy_to_rankfile()`) in a static property...

Also in `ChessGame::try_to_make_square_using_rank_and_file_num()` there is an assignment of `$valid_squares` that is never modified and appears to be identical to `ChessSquare::VALID_SQUARES`. It would be wise to re-use that constant in `ChessGame::try_to_make_square_using_rank_and_file_num()`

I see other redundancies, like whenever a `Dictionary()` object is created, it is typically passed an array like below:

    $file_letters = new Dictionary(array(
        1 => 'a',
        2 => 'b',
        3 => 'c',
        4 => 'd',
        5 => 'e',
        6 => 'f',
        7 => 'g',
        8 => 'h'
    ));

I see three occurrences where such an object is assigned to `$file_letters`- one in `ChessGame::try_to_make_square_using_rank_and_file_num()`, one in `ChessBoard::get_graphical_board()` and `ChessSquare::__construct()`, plus that array is used in `ChessBoard::number_to_file()`. It would be wise to store that array in a constant somewhere, and perhaps make one dictionary to be used in multiple places. There are multiple ways to handle that - e.g. a static property could be made on the game class and referenced wherever necessary, or a static method could be made on the game class that would utilize that static property. Though maybe you should evaluate if it is worth having a separate Dictionary class with a single method - maybe it would be simpler just to have a (static) method somewhere that would handle that functionality...

For more tips on cleaning up code, check out [this video of a presentation Rafael Dohms talk about cleaning up code](https://www.youtube.com/watch?v=GtB5DAfOWMQ&t=2910s) (or [see the slides here](https://www.slideshare.net/rdohms/bettercode-phpbenelux212alternate/18-public_function_createPostrequest_entity_new)).

##Exception Handling
Exceptions are thrown but never caught. Currently if an exception is thrown, that is displayed to the user, like the one I see when I change the URL of a move: 

> **Fatal error**: Uncaught exception 'Exception' with message 'ChessBoard Class - Invalid FEN' in /home/clania/clania.net/admiraladama/chess_v2/ChessBoard.php:54 Stack trace: #0 /home/clania/clania.net/admiraladama/chess_v2/index.php(23): ChessBoard->set_fen('rnbqkbnr/pppp1p...') #1 {main} thrown in **/home/clania/clania.net/admiraladama/chess_v2/ChessBoard.php** on line **54**

Ideally those would be handled - perhaps in Index.php with a `try`/`catch` that may set the value of an error variable and the view would display that error message instead of the board. 

###PHP mixed within HTML
Generally it is best to separate the business logic (PHP) from the view (HTML). Using a template engine could help for this aspect - e.g. [Smarty](https://www.smarty.net/), [Twig](https://twig.symfony.com/), etc. For more information on this topic, prefer to [this article](http://thisinterestsme.com/mixing-php-html/).

###Form submission method
Did you consider using `post` for the [form method](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/form#attr-method)? If the form was submitted as POST requests, then the form variables would not be in the query string, and the user might be less apt to modify them. The effect would be that on the server side [`$_POST`](http://php.net/manual/en/reserved.variables.post.php) would need to be used instead of `$_GET`.


#More Specific points
##PHP
###Declaring Instance/Member variables
The class definitions appear to use the PHP 4 style declarations for instance variables (i.e. `var`). Note that while support of this syntax isn't currently deprecated, it may be in the future:

> **Note**: The PHP 4 method of declaring a variable with the `var` keyword is still supported for compatibility reasons (as a synonym for the public keyword). In PHP 5 before 5.1.3, its usage would generate an **`E_STRICT`** warning.<sup>[1](http://php.net/manual/en/language.oop5.visibility.php#language.oop5.basic.class.class.name)</sup>


###Getting the timestamp with microseconds
Index.php starts with the following lines:

>     $time = microtime();
    $time = explode(' ', $time);
    $time = $time[1] + $time[0];
	$start = $time;
	
Some would argue that readability suffers here because on the first line, `$time` is a string, then on the second line it is an array and then on the third line it is a string again.	
	
This appears to function identically to the [Example 1: Example #1 Timing script execution with microtime()](http://php.net/manual/en/function.microtime.php#example-2812)	on the PHP Documentation for [`microtime()`](http://php.net/manual/en/function.microtime.php). Notice that the function in that example contains the comment:

>     /**
     * Simple function to replicate PHP 5 behaviour
     */
	 
And notice [the next example](http://php.net/manual/en/function.microtime.php#example-2813) is titled **Example #2 Timing script execution in PHP 5**, where it simply calls `microtime()` with `true` for the parameter [`get_as_float`](http://php.net/manual/en/function.microtime.php#refsect1-function.microtime-parameters). So instead of using those first three lines of Index.php could simply be replaced with the call to `microtime(true)` for the same functionality.

    $start = microtime(true);

The same applies to the identical code within View.php.
	
###Error Reporting
Index.php also contains the following line:	
	
	error_reporting(-1);
	
According to the code in [**Example #1 error_reporting() examples**](http://php.net/manual/en/function.error-reporting.php#example-494) in the documentation for [`error_reporting()`](http://php.net/manual/en/function.error-reporting.php#example-494), [`E_ALL`](http://php.net/manual/en/errorfunc.constants.php#errorfunc.constants.errorlevels.e-all) can also be used for that (presuming the PHP version is 5.4 or greater - otherwise [`E_STRICT`](http://php.net/manual/en/errorfunc.constants.php#errorfunc.constants.errorlevels.e-strict) won't be included in that):

>     // Report all PHP errors (see changelog)
    error_reporting(E_ALL);

>     // Report all PHP errors
    error_reporting(-1);	
	
Using the constant like that (i.e. `error_reporting(E_ALL);`) is more readable for anyone who doesn't remember what `-1` signifies when passed to that  

##JS
I like how the drag and drop code is effective and concise - typically such code ends up being overly-complex. And I often recommend DOM references (e.g. ` $('#make_move')` be stored in a variable (or [`const`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/const) if [tag:ecmascript-6] is used) but there are so few of them and most of the moves require a page-load that it likely wouldn't be worth it.



###DOM ready function
[the documentation for `.ready()`](http://api.jquery.com/ready/) states:

>jQuery offers several ways to attach a function that will run when the DOM is ready. All of the following syntaxes are equivalent:

>- `$( handler )`
- `$( document ).ready( handler )`
- `$( "document" ).ready( handler )`
- `$( "img" ).ready( handler )`
- `$().ready( handler )`

>As of jQuery 3.0, only the first syntax is recommended; the other syntaxes still work but are deprecated.<sup>[2](http://api.jquery.com/ready/)</sup>

So the first line of the JavaScript file:

>     $(document).ready(function(){

Can be simplified to:

    $(function(){


##CSS
###Simplification of `padding` for status box
The four padding styles can be simplified from:

>     padding-top: 2px;
    padding-bottom: 2px;
    padding-left: 4px;
    padding-right: 4px;
	
To the following:

    padding: 2px 4px;
	
Because:

>   When two values are specified, the first padding applies to the **top and bottom**, the second to the **left and right**.	<sup>[3](https://developer.mozilla.org/en-US/docs/Web/CSS/padding#Syntax)</sup>

<sup>1</sup><sub>http://php.net/manual/en/language.oop5.visibility.php#language.oop5.basic.class.class.name</sub>
<sup>2</sup><sub>http://api.jquery.com/ready/</sup>

<sup>3</sup><sub>https://developer.mozilla.org/en-US/docs/Web/CSS/padding#Syntax</sub>