Urvin

На 99% у Вас нет там ничего такого, что можно было бы продать или невозможно было бы написать заново за ту же цену.
Кроме контактов клиентов, которые лежат в базе данных, и доступ к которой Вы ограничиваете.

Есть такая штука, как цветовые профили оборудования. Типография может Вам их предоставить.

Ваша задача сведется к:
- калибровке своего монитора калибратором
- вставке цветового профиля в Photoshop/Illustrartor/CorelDRAW/чем Вы рисуете

Тогда цвет на мониторе и изделии будет +- совпадать.

Например, можно скрываться за nginx http secure link. Тогда копирование ссылки становится довольно бессмысленным занятием.

Похоже, придется поколдовать c наследником DefaultValueBinder и назначением его ячейкам.
Посмотрите - на 63 строке оного прямо отрезается начальный "+", как бы Вы не химичили с типами ячеек.

Сам спросил - сам ответил. Я нашел решение, но мне оно совсем не нравится, может, у %username% найдется чего поинтереснее.

Проблема заключается в том, что для простейшего решения нужно иметь возможность хранить состояние, чего PostgreSql прямо не позволяет. Кажется, лучшим решением было бы написание собственной оконной функции, имеющей возможность смотреть на соседние строки, вроде lead, но интернет не изобилует примерами написания оных.

Однако, обнаружилось, что postgres все же может позволить хранить какие-то данные, причем даже не вылезая за пределы транзакции. "Статичные переменные" можно реализовать с помощью функций current_setting / set_config. Невероятный костыль, конечно, но что есть.

Итак, с помощью "статики" создаем функцию, которая по понятной логике щелкает страницы сортированного списка по изменению строкового ключа:

CREATE OR REPLACE FUNCTION grouped_pagination_page(current_key VARCHAR, per_page INT4) RETURNS INT4 AS $$
  DECLARE
    last_key VARCHAR;
    last_row_count INT4;
    last_page INT4;
  BEGIN
    SELECT COALESCE(current_setting('GPP.last_key', TRUE), '') INTO last_key;
    SELECT CAST(COALESCE(NULLIF(current_setting('GPP.last_row_count', TRUE),''),'0') AS INT) INTO last_row_count;
    SELECT CAST(COALESCE(NULLIF(current_setting('GPP.last_page', TRUE),''),'1') AS INT) INTO last_page;

    IF current_key <> last_key THEN
      PERFORM set_config('GPP.last_key', current_key, TRUE);
      IF last_row_count >= per_page THEN
        last_page = last_page + 1;
        last_row_count = 0;

        PERFORM set_config('GPP.last_page', last_page::VARCHAR, TRUE);
      END IF;
    END IF;

    last_row_count = last_row_count + 1;
    PERFORM set_config('GPP.last_row_count', last_row_count::VARCHAR, TRUE);

    RETURN last_page;
  END;
$$ LANGUAGE 'plpgsql';

И вот, собственно, использование ее в запросе (у меня ключ группы - вендор-модель-кузов):

SELECT *,
  MIN(price) OVER win_vendor min_price_vendor,
  MIN(price) OVER win_model min_price_model,
  MIN(price) OVER win_body min_price_body,
  grouped_pagination_page((vendor_name || model_name || body_type)::VARCHAR, 10) page_number
FROM
  car
WINDOW
  win_vendor AS (PARTITION BY vendor_name),
  win_model AS (PARTITION BY vendor_name, model_name),
  win_body AS (PARTITION BY vendor_name, model_name, body_type)
ORDER BY min_price_vendor,
  min_price_model,
  min_price_body,
  price,
  specifications_name

ll применяется совместно с spn и эти параметры совсем не нужны в Вашем запросе.
Пример обратного геокодирования лежит прямо на главной в разделе «Как это работает».

1. Вроде ничего криминального нет, чтобы вытягивать только одно-единственное изображение. Сделайте var_dump($result) после curl_close($ch), что там?
2. Steam API позволяет вытаскивать информацию о пользователях пачками до 100 штук.
Сначала выберите все steam_id в массив, а затем запросите у steam аватарки пачками — много сэкономите на запросах.

$steamids = [ .... ];
$uuser = "http://api.steampowered.com/ISteamUser/GetPlayerSummaries/v0002/?key=".$steamauth['apikey']."&steamids=" . join(',', $steamids);

И не используйте mysql расширение!

Перенаправления в NGINX задаются в конфигурационном файле. Часто под один домен выделяют один конфигурационный файл и валяется это дело в /etc/nginx/sites-available/*.
В вашем случае фрагмент для перенаправления в таком конфигурационном файле может быть таким:

server
{
  ...
  location / {
    try_files $uri $uri/ /index.php?_url=$uri&$args;
  }
  ...
}

SELECT
  f1.name,
  t1.name,
  f2.name,
  t2.name,
  battle.date
FROM battle
  JOIN fighters f1 ON fighter_1 = f1.id
  JOIN fighters f2 ON fighter_2 = f2.id
  JOIN teams t1 ON f1.team = t1.id
  JOIN teams t2 ON t2.team = t2.id
WHERE
  battle_id = 1

И правильная ли такая организация БД?

Почти. Я бы не стал хранить поля fighter_1 и fighter_2, а перенес бы связь бойцов с матчами в промежуточную таблицу battle_fighters(id, battle, fighter), классически реализовав связь «многие ко многим».

SessionStorage - сессия на фронтенде и она не пересекается с сессией PHP на бэкенде: Unlike cookies, the storage limit is far larger (at least 5MB) and information is never transferred to the server.
Используйте, например, AJAX для обмена информацией между фронтом и бэкендом.