Piwigo 2.8 was modified (mainly Smarty update + class constructors) to be compatible with PHP 7. It does not mean that you can use new features of PHP 7, because Piwigo 2.8 is still compatible with PHP 5.2.

The main problem you may encounter is the class constructor must not have the same name as the class, but use __construct syntax, like:

class BlockManager
{
  /** @var string */
  protected $id;
 
  /**
   * @param string $id
   */
  public function __construct($id)
  {
    $this->id = $id;
  }
}

Piwigo 2.8 introduces an unified set of methods to log message from your PHP code (be it in the core or in plugins). See the announcement by mistic100 http://piwigo.org/forum/viewtopic.php?id=25428

// 5 levels  (there are two more but I don't think we need this granularity)
$logger->info('message');
$logger->debug('message');
$logger->warning('message');
$logger->error('message');
$logger->critical('message');
 
// each method can take a array of info
$logger->info('message', array(
  'page' => $page,
  'user' => $user,
));
 
// each method can also take a "module" name (to separate core components, plugins, etc)
$logger->info('message', 'i.php');
 
$logger->info('message', 'i.php', array(
  'page' => $page,
  'user' => $user,
));

Piwigo 2.7 introduced the “any file type upload”. Piwigo 2.8 introduces the “handle any file type”. Very useful to create the pwg_representative for a RAW file (that's just an example…). You can find an example in Piwigo core, file admin/include/functions_upload.inc.php :

  // handle the uploaded file type by potentially making a
  // pwg_representative file.
  $representative_ext = trigger_change('upload_file', null, $file_path);
 
[...]
 
add_event_handler('upload_file', 'upload_file_pdf');
function upload_file_pdf($representative_ext, $file_path)
{
  global $logger, $conf;
 
  $logger->info(__FUNCTION__.', $file_path = '.$file_path.', $representative_ext = '.$representative_ext);
 
  if (isset($representative_ext))
  {
    return $representative_ext;
  }
 
  if (pwg_image::get_library() != 'ext_imagick')
  {
    return $representative_ext;
  }
 
  if (!in_array(strtolower(get_extension($file_path)), array('pdf')))
  {
    return $representative_ext;
  }
 
  $ext = conf_get_param('pdf_representative_ext', 'jpg');
  $jpg_quality = conf_get_param('pdf_jpg_quality', 90);
 
  // move the uploaded file to pwg_representative sub-directory
  $representative_file_path = original_to_representative($file_path, $ext);
  prepare_directory(dirname($representative_file_path));
 
  $exec = $conf['ext_imagick_dir'].'convert';
  if ('jpg' == $ext)
  {
    $exec.= ' -quality '.$jpg_quality;
  }
  $exec.= ' "'.realpath($file_path).'"[0]';
  $exec.= ' "'.$representative_file_path.'"';
  $exec.= ' 2>&1';
  @exec($exec, $returnarray);
 
  // Return the extension (if successful) or false (if failed)
  if (file_exists($representative_file_path))
  {
    $representative_ext = $ext;
  }
 
  return $representative_ext;
}

Here you have an example on how to handle PDF files. Any plugin can extend this feature to “any” file type to “prepare” what needs to be prepared (don't think you can only create a pwg_representative). If the default handler doesn't suit you, you can also give a higher priority to your handler.

New function to get a configuration parameter. The main advantage is that you no longer need to make $conf global. Here is how to use it:

$ext = conf_get_param('pdf_representative_ext', 'jpg');

In the search.tpl template, after the list of fields[], insert:

{if isset($TAGS)}
   <label><input type="checkbox" name="search_in_tags" value="tags"> {'Tags'|translate}</label>
{/if}