Еще только десятый день нового года, а мы уже столько всего нового сделали, удивляюсь просто. Сегодня расскажу об обновлении, которого мы и сами уже давно ждали.

Администраторы сайтов, работающих на IWE, знают, что самые тяжелые скрипты ― это те, в которых используется загрузчик изображений, а таковых имеется два: скрипт загрузки фотографий в альбомы и скрипт создания нового желания для wishlist'а. До сегодняшнего (вернее, уже до вчерашнего) дня в этих скриптах использовались функции библиотеки GD, которая, на мой взгляд, не особенно удачно справляется со своими функциями. Так, к примеру, на фотографии должен добавляться полупрозрачный водяной знак, однако файл водяного знака и водяной знак, наложенный на фотографию, ― это два разных изображения. Водяные знаки с альфа-каналом всегда воспринимались загрузчиком достаточно своеобразно: то полупрозрачные точки вообще пропадали при вставке, то превращались в непрозрачные. А кроме этого не всегда успешно создавались файлы предпросмотра для фотографий, приложенных к желаниям wishlist'а. Но самая главная проблема даже не эта. Самая главная проблема старого загрузчика заключалась в том, что обрабатывал он исключительно файлы формата jpeg.

После перехода на imagemagick сразу все проблемы были решены, а кроме этого размер скрипта сократился с 20Кб до пяти. Теперь на изображения будет выставляться любой водяной знак, причем после вставки он будет выглядеть точно также, как и до нее. Больше не нужно конвертировать фотографии при помощи графического редактора перед загрузкой на сайт. К загрузке принимаются абсолютно все типы изображений, которые перед обработкой будут автоматически конвертироваться в jpeg. Мы тестировали скрипт с файлами png, tga, gif, tiff и xcf: все изображения были успешно сконвертированы в jpeg и обрабатывались дальше по типичному сценарию. Сценарий немного изменился только для файлов предпросмотра wishlist'а: вокруг изображений больше не будут прорисовываться рамочки. Ранее они были актуальны, поскольку статус желаний было невозможно изменить и вокруг "важных" желаний прорисовывалась оранжевая рамка, сейчас же статус можно свободно менять, так что рамки целесообразно рисовать средствами CSS. Скоро мы еще немного доработаем скрипт списка желаний и добавим поле «благодарности» для исполненных желаний, чтобы автор мог указывать того, кто осуществил данное желание (конечно же, это не обязательно, однако функция такая будет, на мой взгляд, не лишней).

Кроме всего вышеописанного мы исправили также одну ошибку, на которую получили уже несколько жалоб от клиентов. Дело в том, что скрипт Controls написан таким образом, чтобы администратор пользовался только специализированной панелью доя обслуживания сайта, поэтому в случае, если файл фотографии был удален вручную, из альбома запись о фотографии удалить было невозможно. Дело в том, что в скрипте удаления фотографий предусмотрена проверка, которая завершает процесс удаления фотографии в том случае, если системе не удалось удалить файл фотографии из соответствующей папки. Сделано это на тот случай, если вдруг фотографию не удастся удалить по причине отсутствия соответствующих прав, чтобы не плодить на сервере неиспользуемые файлы. Теперь у администратора сайта на основе IWE появилась возможность пропустить проверку удаления на тот случай, если файлы вдруг были удалены вручную.

Для скрипта блога также имеются кое-какие исправления, правда, ошибки, которые были исправлены, мы обнаружили уже сами. Суть ошибки заключалась в том, что скрипт допускал любое количество слешей, поставленных подряд, в адресной строке. Это неверно, поскольку таким образом одна и та же страница может быть проиндексирована поисковыми системами по десяткам различных адресов. К примеру, предположим, что у нас есть статья с кодом вызова «some-article». Таким образом доступна она должна быть только по двум адресам: «blog.example/some-article» и «blog.example/some-article/», причем последний ― это переадресация 301-ым статусом на первый адрес. В результате ошибки она была доступна также по адресу «blog.example/////some-article» и ему подобным, что совершенно неверно, поскольку в адресной строке согласно стандартам IWE не может стоять более двух слешей подряд, да и те могут располагаться только после http: либо https: для защищенного соединения. В последнем исправлении к скрипту блога мы обновили таблицу фильтров так, чтобы при обнаружении двух и более слешей подряд в строке запроса соединение разрывалось с четырехсотым статусом. Это же исправление, кстати, чуть позже было добавлено во все наши продукты, так как стандарт IWE является общим для всех продуктов, выпускаемых нами.