А сегодня некоторые JavaScriptы на сайтах перестали работать потому что подгружались скрипты с сайта trendtext.eu и меня это окончательно вывело из себя и я решил найти причину данного беспорядка.

Еще вчера я начал искать причину появления промежуточного ресурса lnkr.us, путем поиска в Google, а также поиском вирусов на своем компьютере, однако единственное что мне удалось обнаружить — это жалобы на расширение Chrome Currency Converter, которым я естественно не пользуюсь.

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

Это значит что у вас могут украсть пароли или любые другие данные, что, согласитесь, не очень приятно. И я решил искоренить этот вирус с моей машины. Ниже на скриншотах вы можете видеть пример того, как вредоносная программа внедрила кусок кода на страницы сайта.

Вспомнив, что на многих ресурсах жаловались на расширения Google Chrome, я решил опытным путем, методом отключения плагинов/расширений вычислить вредоносное расширение, которое внедряло этот код в тело страницы. И этим расширением оказался Responsive Web Design Tester. Если поискать данное расширение в интернете, то вы увидите что из магазина Chrome оно уже удалено.

В принципе такого рода плагины абсолютно бесполезны. Во-первых, в браузерах уже есть встроенная функция проверки адаптивного дизайна и достаточно нажать Ctrl+Shifl+J и нажать на иконку мобильного телефона, после чего перейти во вкладку Elements (Элементы/Дерево и т.п.). Во-вторых, можно проверить адаптивный дизайн и путем уменьшения окна браузера.

Ели вы столкнулись с данной проблемой — попробуйте также отключать расширения в вашем браузере и обновлять страницу — расширение, после отключения которого дефект пропадет — и есть вредоносным. Надеюсь данная статья была полезна. Следите за вашей безопасностью и не устанавливайте расширений от неизвестных и непроверенных авторов!

В данной статье мы разберемся как работает система событий в Opencart 2.x, и как ее использовать при написании своих модулей.

Данная система позволяет писать код, который будет выполняться при определенных событиях, происходящих в OpenCart. Такими событиями могут быть:

• создание учетной записи (регистрация);
• оформление заказа;
• редактирование адресов пользователя;

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

Как работают события Opencart 2.x

Для использования системы событий достаточно выполнить два действия:

1. регистрация обработчика событий;
2. реализация обработчика событий;

Обработчики событий — просто методы, определенные в файлах контроллера. Вы можете использовать один файл для всех ваших методов или вы можете создать отдельный контроллер для ваших обработчиков событий.

Для регистрации обработчики событий необходимо использовать модель extension/event (для OpenCart 2.0.1+) или модель tool/event (для OpenCart 2.0.0.0).

В модели extension/event есть 2 метода:

1. addEvent($code, $trigger, $action);
2. deleteEvent($code).

Не сложно догадаться, что функция addEvent() используется для регистрации обработчиков событий, а deleteEvent() используется для отмены регистрации. Это позволяет зарегистрировать свои обработчики событий в методе install() контроллера вашего модуля в admin разделе, а также удалить их, когда ваш модуль удаляется, для чего используется метод uninstall() этого же файла контроллера.

Аргумент $code — используется для группы обработчиков событий. Здесь вы указываете название вашего модуля.

Аргумент $trigger  -название события, на которые вы хотели бы установить обработчик. Список всех доступных триггеров, можно найти здесь: https://github.com/opencart/opencart/wiki/Events-(script-notifications).

Аргумент $action путь к вашей функции обработчика. Указывается в виде стандартного адреса к контроллеру. Например: module/mymodule/on_install.

Пример событий Opencart 2.x

В данном примере предполагается, что мы работаем с OpenCart 2.0.1+. Теперь давайте предположим, что мы создаем модуль под названием «My Module». Файл-контроллер администратора для модуля будет admin/controller/module/mymodule.php. Файл-контроллер каталога для модуля будет catalog/controller/module/mymodule.php.

Модуль будет реализовывать 2 простые функции:

1. отправку сообщения электронной почты администратору, когда удаляется магазин (мультимагазин);
2. отправку сообщения электронной почты администратору при регистрации клиента.

Триггеры, которые мы будем использовать в pre.admin.store.delete и post.customer.add.

Для начала, мы зарегистрируем наши обработчики событий в методе install() нашего модуля:

public function install() {
    $this->load->model('extension/event');
    $this->model_extension_event->addEvent('mymodule', 'pre.admin.store.delete', 'module/mymodule/on_store_delete');
    $this->model_extension_event->addEvent('mymodule', 'post.customer.add', 'module/mymodule/on_customer_add');
}

Мы также должны позаботиться о процессе удаления, и удалить обработчики событий в случае удаления модуля:

public function uninstall() {
    $this->load->model('extension/event');
    $this->model_extension_event->deleteEvent('mymodule');
}

Далее, мы должны реализовать обработчики событий. События, название которых начинается с pre, вызываются перед выполнением действия, а события, название которых начинаются с post — после завершения действия.

Если нам необходимо включить домен магазина в наше сообщение, выбираем событие «pre» вместо «post», т.к. при использовании post.admin.store.delete мы не сможем получить домен магазина.

Событие pre.admin.store.delete генерируется в админке, так что его обработчик должен быть реализован в файле контроллера администратора для нашего модуля. Мы хотим, чтобы наш обработчик событий уведомлял администратора об удалении магазина, и наш обработчик будет выглядеть примерно так:

public function on_store_delete($store_id) {
    $this->load->model('setting/store');
    $store_info = $this->model_setting_store->getStore($store_id);
    $admin_mail = $this->config->get('config_email');
    mail($admin_mail, "A store has been deleted", "The store " . $store_info['url'] . " was deleted.");
}

Все, что осталось сделать, это реализовать обработчик для события post.customer.add. Мы будем делать это в каталоге контроллера нашего модуля. Метод будет уведомлять администратора, когда регистрируется новый клиент и будет выглядеть примерно так:

public function on_customer_add($customer_id) {
    $this->load->model('account/customer');
    $customer_info = $this->model_account_customer->getCustomer($customer_id);
    $admin_mail = $this->config->get('config_email');
    mail($admin_mail, "New Customer", "A new customer has just registered with the following e-mail: " . $customer_info['email']);
}

Внимание: в примере используется функция mail() для отправки электронной почты для простоты. В реальной ситуации для этого необходимо использовать класс OpenCart.

Окончательные версии наших файлов выглядит следующим образом:
admin/controller/module/mymodule.php

<?php class ControllerModuleMyModule extends Controller { public function install() { $this->load->model('extension/event');
        $this->model_extension_event->addEvent('mymodule', 'pre.admin.store.delete', 'module/mymodule/on_store_delete');
        $this->model_extension_event->addEvent('mymodule', 'post.customer.add', 'module/mymodule/on_customer_add');
    }
    
    public function uninstall() {
        $this->load->model('extension/event');
        $this->model_extension_event->deleteEvent('mymodule');
    }
    
    public function on_store_delete($store_id) {
        $this->load->model('setting/store');
        $store_info = $this->model_setting_store->getStore($store_id);
        $admin_mail = $this->config->get('config_email');
        mail($admin_mail, "A store has been deleted", "The store " . $store_info['url'] . " was deleted.");
    }
}

catalog/controller/module/mymodule.php

<?php class ControllerModuleMyModule extends Controller { public function on_customer_add($customer_id) { $this->load->model('account/customer');
        $customer_info = $this->model_account_customer->getCustomer($customer_id);
        $admin_mail = $this->config->get('config_email');
        mail($admin_mail, "New Customer", "A new customer has just registered with the following e-mail: " . $customer_info['email']);
    }
}

Дополнительно

Помимо стандартного использования, система событий может быть использована для создания кросс-модульной интеграции. Используя объект Event ($this->event), вы можете вызвать любое событие в любой точке, а также чтобы вызвать свои собственные события.

Представьте себе, что вы разрабатываете модуль для комментариев. Вы создаете событие на действие по отправке комментария, например, что позволит другим разработчикам модулей создать методы-обработчики событий для ваших и выполнить код без необходимости vQmod или OCMOD. Это будет гарантировать, лучшую стабильность системы и лучший потребительский опыт. Вы также можете использовать систему для регистрации и запуска собственных событий во время выполнения.

Класс событий определяется в файле system/engine/event.php, так что вы можете взглянуть на нее для дальнейшего использования.

Заключение

Освоение системы событий в OpenCart выгодно во многих отношениях! И я рекомендую использовать события вместо системы модификации vQmod или OCMOD везде, где это возможно. Это позволит сократить количество глюков и несовместимостей модулей и дополнений других разработчиков с вашими. Также это позволяет создавать и использовать межмодульные связи, так что вы можете сделать несколько модулей, работающих вместе красиво и элегантно.

Однако насколько сложно удалить водяной знак с картинки, как защитить свои изображения так, чтобы нельзя было ими пользоваться на других сайтах и в то же время не скрыть самого главного?

Чтобы понять, как создать сложный водяной знак необходимо понять насколько легко удалить водяной знак с изображения. Для этого нам потребуется редактор изображений (Adobe Photoshop, например) и несколько изображений примеров.

Как удалить водяной знак с изображения

Удаление водяного знака с изображения может быть реализовано несколькими способами:

• обрезка изображения;
• с помощью инструментов «Восстанавливающая кисть» (Healing Brush/J) или «Штамп» (Stamp/S);
• с помощью заливки и инструмента «Волшебная палочка» (Magic Wand/W).

Первый способ избавления от водяного знака самый простой и быстрый. Во втором случае злоумышленник вручную обрабатывает каждый пиксель изображения, на который был наложен водяной знак, что достаточно трудоемко и долго, однако вполне реализуемо.

Третий же вариант позволяет стереть водяной знак полностью, или хотя бы большую его часть буквально за считанные секунды (нажмите для просмотра):

Инструкция по удалению простых водяных знаков

Данная инструкция представлена исключительно в ознакомительных целях и для проверки личных водяных знаков! Не воруйте чужие изображения!

1. Открыть изображение.
2. Выбрать инструмент «Волшебная палочка», установить значение опции «Допуск» в ~50, снять галочку с опции «Смежные пиксели».
3. Если выделяется очень много лишних областей, то поставить галочку на опции «Смежные пиксели», поиграться с опцией «Допуск» (уменьшить значение) и выделять области с зажатой клавишей «Shift».
4. После выделения необходимо увеличить размер выделенной области на 1 пиксель. Для этого необходимо перейти в пункт меню «Выделение» -> «Модификация» -> «Расширить».
5. Установить значение в 1 или более пикселей, в зависимости от желаемого результата.
6. Выполнить заливку выделенной области. Для этого перейти в пункт «Редактирование» -> «Выполнить заливку» или нажать на клавиатуре Shift+F5.
7. Выбрать в открывшемся окне для опции «Использовать» значение «С учетом содержимого» и нажать «Ок».
8. Убрать выделение.

Как подобрать водяной знак на изображение

Чтобы ваше изображение нельзя было так просто украсть, необходимо использовать более сложные водяные знаки, и располагать их таким образом чтобы покрывалась максимальная площадь изображения, однако при этом необходимо помнить что пользователи все-таки должны понять смысл самого изображения. Чтобы в погоне за безопасностью не потерять смысл картинки.

Вот некоторые из рекомендаций по созданию водяного знака:

• размер и положение:
  • покрывает все изображение;
  • изображение замощено водяным знаком;
  • водяной знак расположен в центре изображения;
• водяной знак содержит:
  • сложные элементы (завитушки, пропись);
  • линии через все изображение;
• оформление:
  • используйте разный цвет;
  • разный размер шрифта;
• не скрывает сути картинки.

Также можно посмотреть примеры хороших водяных знаков на фотобанках, где дизайнеры и фотографы продают свои труды. Вот пример хорошего водяного знака:

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

Но, к сожалению, даже самые сложные водяные знаки не защитят ваше изображение от очень настойчивых и кропотливых воров. Надеюсь данная статья поможет вам уберечь картинки и подобрать правильный водяной знак для их защиты. Не забывайте ставить лайк, подписываться и делиться записью в социальных сетях. Спасибо.

Данный плагин очень удобный и имеет достаточно настроек, но к сожалению, в нем отсутствует опция блокирования всего контента страницы/статьи, о чем и пойдет речь.

OnePress Social Locker — это один из популярных бесплатных (если не единственный бесплатный) социальных локеров контента для WordPress. Он позволяет блокировать определенный контент на странице при помощи shortcode (шорткодов/тегов, см. изображение). Вы можете создать несколько типов блокировки (текст, оформление блокирующего блока) и использовать для разных кусков контента. Например:

1. Чтобы скачать с сайта — создадим блокировщик с текстом «Ссылка скрыта, подпишитесь на группу чтобы скачать» и ссылка на группу;
2. Чтобы просмотреть отдельную часть статьи — создадим блокировщик с текстом «Контент защищен, поставьте лайк чтобы увидеть» и кнопочки для лайков;

Также, плагин позволяет автоматически закрыть нужный контент в уже существующих записях: вы можете закрыть весь контент или только часть статьи, используя следующие правила:

• количество абзацев после которых дальнейший контент будет заблокирован;
• скрывать контент после тега «Далее» (<!— more —>);

и еще множество других. Но! Если мы скроем контент таким образом, то при необходимости убрать блокировку необходимо будет перелопатить потом вручную все записи, удаляя шорткод. Чтобы не прибегать к такому неудобному способу, было разработано следующее решение: заменить в файле single.php стандартный вывод контента на следующий код:

	 	 
$content = get_the_content();
$content = apply_filters('the_content', $content);
echo do_shortcode('[sociallocker]'.$content.'[/sociallocker]');

Таким образом весь контент нашей статьи будет обернут в shortcode блокировщика и его можно будет, спустя некоторое время, безболезненно и быстро убрать, при этом не редактируя все записи на вашем сайте.

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

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

Прошу обратить внимание: данная статья является в большей степени дискуссионной, и хотелось бы узнать ваше мнение относительно данного вида «принуждения к действию» посетителя (возможно вы даже знакомы с некой статистикой), и как бы повели себя вы, встретившись с таким явлением.

Социальные сети с каждым днем все глубже интегрируются в нашу жизнь, мы проводим в них все больше и больше времени, и это не может не сказаться на самой концепции Интернета и его развитии в целом. Практически каждый ресурс имеет свои аккаунты, официальные группы и публичные страницы в социальных сетях, а сайт оснащен большим количеством кнопок для оценки (далее «лайков») отдельных страниц или всего сайта.

Основной задачей такой «социализации» проекта является постоянная связь с аудиторией: добавление новостей в социальные сети побуждает пользователя заходить на ваш ресурс, покупать товары, пользоваться вашими услугами, или хотя бы напоминает о вашем сайте. Однако это не единственное для чего используют социализацию: бытует мнение что количество «лайков» влияет на ранжирование сайтов в поисковой выдаче (другими словами — чем больше «лайков» — тем больше посетителей), а также способствует увеличению аудитории методом увеличения количества подписчиков на страницах в социальных сетях.

Однако, зачастую посетители ленятся пренебрегают или забывают поставить заветный «лайк», что собственно достаточно обидно для автора статьи, или же для владельца того или иного сайта. Однако, ситуацию может спасти блокировщик контента, который спрячет контент от посетителя сайта до тех пор пока он, например, не подпишется на вашу группу/публичную станицу или не поделится ссылкой в одной из социальных сетей.

И тут появляется вопрос о логичности применения данной системы ограничений, ведь посетитель еще не ознакомился с контентом и не может понять насколько полезен был данный ресурс или страница. Более того, на мой взгляд, может иметь место отпугивание посетителей использование такой схемы «отжимания лайков», что скажется на проценте отказа, что также не хорошо для сайта.

Вторым нюансом, при использовании данной системы, является простота ее реализации, ведь на самом деле весь контент уже находится на странице сайта и достаточно лишь открыть исходный код, сделать блок видимым или отключить overlay (наложенный на контент слой) и получить заветную информацию. Как это сделать видно на следующем анимационном изображении (нажмите для просмотра анимации):

Таким образом:

• часть людей сможет повторить нехитрые манипуляции со страницей и открыть скрытый контент без требуемого действия, как показано выше;
• часть людей откажется от просмотра статьи и уйдет к конкуренту;
• часть людей поставит вожделенную оценку.

Если предположить что все данные группы аудитории равны между собой, то мы получим отдачу в 33,3(3)% от объема аудитории сайта. Казалось бы неплохой процент, однако, помимо положительного результата будет еще и отрицательный:

• мы теряем аудиторию в 33,3(3)% на группе которая откажется от просмотра и уйдет к конкуренту, а сформированное отношение к ресурсу неблагоприятно повлияет на дальнейшие визиты данного посетителя;
• есть вероятность того, что на посетителей из первой группы (умельцев) также неблагоприятно повлияет наличие такого блокировщика.

Еще одним интересным фактором является количество установок бесплатного плагина для WordPress «OnePress Social Locker», которое составляет всего 10 000, несмотря на то что плагин достаточно давно был опубликован и имеет очень много версий, соответственно видимо он не сильно полезен и востребован.

Основываясь на данных рассуждениях, лично я, пока что, не вижу смысла в использовании социальных блокировщиков контента, однако сама идея очень интересная. В моем понимании, социальная система должна работать следующим образом:

• посетитель открыл сайт;
• ознакомился с контентом, скачал;
• перед закрытием вкладки обязательно напомнить человеку что он забыл подписаться (например не давать закрыть окно пока не подпишется с помощью стандартного диалога/алерта).

На мой взгляд, именно такая конструкция является правильной, однако, возможно у вас есть иное мнение, или же у вас есть опыт работы с такими плагинами и вы можете поделиться реальной статистикой и высказать свое мнение — не стесняйтесь, пишите комментарии, и не забывайте подписываться на группы в социальных сетях и ставить «лайки»!

Такая популярность данного направления приводит к бешеной конкуренции на рынке предоставления IT-услуг, и это ведет не только к негативным последствиям для самих разработчиков, например в виде демпинга рынка и сложность в получении заказов, но и для самих заказчиков.

Почему это важно для заказчика

Опасность для заказчиков представляется в выборе разработчика из многотысячной аудитории компаний и фрилансеров которые готовы предоставить свои услуги по созданию сайтов. О том, как выбирать разработчика,  который создаст вам сайт, я уже писал, и сегодня мы будем говорить о качестве того сайта, который вам создадут.

К сожалению, вне зависимости от того, к кому вы обратитесь (к студии ли, или же к фрилансеру) есть вероятность получить некачественный продукт, а ведь каждый хочет пользоваться качественными вещами, не так ли, особенно если за этот продукт были уплачены немалые средства и потрачено немало времени.

И самое ужасное в данной ситуации и в остальных сферах это то, что контроль качества приобретаемого продукта ложится на конечного пользователя. Однако, если у клиента есть возможность проверить качество сборки стола, автомобиля и т.п. продуктов на уровне интуитивном и логическом, то с проверкой качества IT продукта, а в данном случае с проверкой качества созданного сайта, дела обстоят печальней, т.к. в большинстве случаев заказчики абсолютно не не компетентны в данном вопросе. И если вы не хотите читать дальше и заниматься проверкой сайта, то я рекомендую вам обратиться к правильному разработчику.

Кто-то скажет, что все предельно просто, и для проверки качества работы сайта достаточно лишь зайти на него и «поклацать кнопочки», однако я спешу вас разочаровать, и предлагаю ознакомиться с моими предыдущими статьями на тему качества в разработке сайтов:

• Как не стоит создавать сайты;
• Как проверить адаптивный дизайн сайта.

Таким образом, студии и фрилансеры имеют возможность создавать некачественный продукт и зарабатывать на этом деньги. Ввиду специфики моего общения, для разъяснения некоторых моментов я люблю использовать аналогии, и о создании сайта можно говорить как о построении дома. Если строители были нечестны на руку, то и дом простоит не долго, достраивать к нему что-либо будет трудоемко или вообще не возможно, и вешать на стены шкафы тоже не получится — упадут.

Естественно и очевидно, что каждая студия/посредник(и) старается максимально удешевить производство продукта, в нашем случае создание сайта, и единственный способ это сделать — отдать проект на разработку менее опытному и менее профессиональному разработчику. Таким образом, на выходе можем получить не совсем качественный сайт.

Как получить качественный сайт

В первую очередь необходимо обратиться к правильному разработчику ;). Последующие шаги очевидны и абсолютно всем известны, однако, несмотря на все статьи и советы, горький опыт заказчиков и исполнителей, люди продолжают преднамеренно заказывать и получать некачественные сайты.

В первую очередь хочется сразу обратить внимание на ценообразование, и если ваш сайт стоит как «ящик водки», то и результат будет соответственным. И дело не в «расходниках» и «себестоимости продукта», а в банальном интересе к проекту. Ведь если человек заинтересован в проекте, он занимается им с придыханием, то и результат будет соответственный. Более того, разработчик может предложить какие-то идеи, пришедшие ему в ходе разработки, по улучшению вашего сайта.

Следующим, и, пожалуй, самым главным в данном списке, этапом является сам процесс разработки, в котором Клиент, при всем уважении, должен участвовать по-минимуму, т.к. он уже обратился к специалистам и должен им довериться, т.к. именно эти ребята занимаются разработкой сайтов. Ведь когда вы приходите к зубному, я надеюсь, вы не даете советов как ему лечить ваши зубы? А ведь это ваше здоровье! Позвольте и разработчикам удовлетворить ваши потребности самостоятельно. В противном случае, может получиться так:

Безусловно, «Клиент всегда прав», и имеет право на любые капризы, НО! Во-первых, всему есть границы, во-вторых, задача профессионального исполнителя уберечь заказчика от подобных вещей.

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

Следуя этим простым советам вы можете получить качественный сайт. Ну а если вы уже имеете сайт, то его всегда можно изменить/переделать ;). Если у вас возникли вопросы или предложения по теме данной статьи, можете присылать их на почту через форму обратной связи или написать свое мнение в комментариях.

Как правило, сайты с несколькими яыками — это крупные порталы или небольшие сайты-визитки, направленные на представление информации пользователям нескольких стран. Создание нескольких языковых версий для сайтов местного масштаба (городского, областного, масштаба страны) является абсолютно не обоснованной затратой средств и времени.

Сегодня мы рассмотрим один из вариантов создания мультиязычного сайта при помощи JavaScript библиотеки l20n. Данная библиотека позволяет создать мультиязычный сайт используя всего несколько файлов для локализации и собственно саму библиотеку.

Как локализовать сайт с помощью JavaScript

Для локлизации сайта с помощью JavaScript можно использовать библиотеку l20n. Структура файлов данного фреймворка достаточно проста: файл, который необходимо локализовать с подключенным файлом скрипта l20n.js и папка с локализациями. Данный фреймворк от компании Mozilla распространяется бесплатно, и вы можете с ним ознакомится по ссылке http://l20n.org/.

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

Интегрировать скрипт в вашу страничку достаточно просто:

1. скачайте библиотеку по ссылке выше;
2. подключите его в файле, который необходимо локализовать;
3. разметьте соответствующим образом файл, который необходимо локализовать;
4. создайте файлы локализации.

Вы можете скачать простой пример локализации странички при помощи фреймворка l20n от Mozilla для трех языков: английский, русский, французский. Данный пример покажет вам наглядно как работает данная библиотека. Внимание: вам необходимо запускать демо на сервере/локальном сервере — при обычном открытии файла index.html браузер выдаст ошибку: XMLHttpRequest cannot load file:///YOUR_PATH/www/locales/browser.json. Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, https, chrome-extension-resource.

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

Положительные и негативные стороны локализации JavaScript

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

Однако, присутствуют и негативные стороны использования JavaScript как средства для локализации вашего сайта, такие как:

1. По умолчанию, разработчики l20n предлагают оставлять теги для подстановки локализованных строк пустыми, что чревато понижением в поисковой выдаче, т.к. робот не видит текста на вашем сайте, т.к. поисковый робот парсит вашу страницу без JavaScript! Этот огромный недостаток можно с легкостью исправить, просто заполнив теги предпочтительным, преобладающим языком на вашем сайте, как это сделано в примере.
2. Поисковая система не сможет проиндексировать разные версии сайта, и будет видеть только одну версию — версию, которую вы указали в предыдущем пункте. Если реализовать локализацию на php, то можно создать для поисковой системы отдельные каталоги с разными локализациями.
3. На мой взгляд такая реализация мультиязычности не подойдет для больших порталов и крупных сайтов, т.к. она достаточно проста и не функциональна. Необходимо будет прописывать текст для каждой странички отдельно, т.е. такая конструкция позволительна исключительно для сайтов, состоящих из нескольких страниц.

Несмотря на все недостатки данного фреймворка, я тем не менее рекомендую с ним ознакомиться, и использовать в небольших проектах, например лендинг пейдж, промо и т.п. страницах.

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

Если раньше для поддержки мобильных устройств владельцам сайтов предлагалось разработать отдельный проект для мобильных устройств, например на поддомене m.example.com, то сегодня все решается благодаря адаптивной верстке, использование которой стало возможно, с внедрением media query (rules) в CSS3.

Данные медиа запросы/правила — это определенный набор стилей, которые написаны специально под мобильное устройство, имеющее определенный размер (разрешение) экрана. Принцип правил следующий: если устройство имеет размер экрана, подходящее под описанные верстальщиком условия, то применяются соответствующие символы.

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

Как же все таки проверить сайт на наличие адаптивной верстки? Все проще чем кажется: достаточно просто изменить размер окна бразуера и проверить как сайт себя поведет. Пример адаптивной верстки вы изображен на анимированном рисунке ниже (для просмотра кликните по изображению).

Как вы можете заметить, сайт подстраивается под любой размер экрана, и минимальной шириной, которую обычно поддерживают устройства — 320 пикселей. Однако, как показывает мой опыт, нередко можно встретить сайт, который подстроен под мобильные устройства, однако при изменении размера окна он не адаптируется до тех пор, пока размер окна не станет размером менее чем размер окна мобильного устройства.

Дело в том, что с ростом количества мобильных устройств, растет и их разновидность. Разные производители выпускают гаджеты с абсолютно непредсказуемыми размерами дисплеев, в связи с этим в верстке вашего сайта не должно быть таких вот пробелов, т.е. сайт должен выглядить как задумано во всех размерах.

Вот например на этом сайте мобильная версия «включается» поздно, и кнопка «Contact» закрывает собой пункты меню. В данном случае, было бы уместно дописать еще десяток строк CSS-кода для решения данной проблемы (для просмотра кликните по изображению). (сайты были найдены случайным образом, автор не пытается обидеть или оскорбить владельцев или разработчиков сайтов, представленных ниже в виде наглядных примеров)

В следующем примере вообще решили избавится от прокрутки (скроллов), в связи с чем абсолютно невозможно будет пользоваться сайтом на устройствах с маленьким разрешением экрана (для просмотра кликните по изображению):

Следующий пример «адаптивности» — сайт вроде адаптивный, но скрол есть, текст вылазит, элементы залазят друг на друга, образуя такую себе кашу (для просмотра кликните по изображению).

Почему нельзя проработать адаптивность для всех размеров? Почему только мобильные, совсем маленькие устройства? (для просмотра кликните по изображению)

Таким образом, можно сказать что понимание адаптивности в наше время все еще разница. Так что проверяйте ваши сайты на адаптивность очень тщательно, ведь поддержка максимального количества устройств — основная задача адаптивного дизайна.

В данном посте мы рассмотрим установщик расширений, принцип его работы, затронем тему vQmod в OpenCart 2.x, а также рассмотрим новые возможности, предоставляемые OpenCart 2.

Установщик расширений OpenCart 2.x

Первым, что хотелось бы рассмотреть, это установщик расширений, т.к. это, пожалуй, один из самых основных разделов административной части для разработчика интернет магазина на основе CMS OpenCart. В предыдущих статьях, ввиду отсутствия опыта работы с новой версией движка, я мало уделял внимания данному разделу, но в данной статье я постараюсь ответить на все вопросы, с которыми могут столкнуться разработчики.

Для начала рассмотрим из чего состоит сам архив модуля .ocmod:

1. новые файлы (файлы модуля) — файлы для загрузки (которые не затирают основные файлы движка), находящиеся в папке upload;
2. файл install.sql для добавления таблиц в базу данных (если необходимо);
3. файл install.xml в котором хранятся инструкции по модификации основных файлов CMS Opencart (основан на принципе xml-файлов vQmod);
4. файл install.php который содержит код, который будет выполнен во время установки.

Как видно на скриншоте выше, структура папок в папке upload полностью повторяет стандартную структуру папок Opencart. В этих папках расположены файлы, которые будут скопированы на сервер при установке расширения.

Установка расширения происходит в несколько этапов:

1. загрузка и распаковка (в случае если это архив) файлов на сервер во временную папку system/upload/;
2. если это просто .XML файл, то его содержимое будет записано в таблицу oc_modification и на этом установка закончена, а если же это архив с файлами (как в примере), то он будет разархивирован во временное хранилище;
3. проверка доступа к FTP (доступ к FTP настраивается в настройках магазина);
4. загрузка файлов из папки upload модуля;
5. выполнение запросов из .SQL файла (обновление базы данных);
6. внесение правок в существующие файлы из .XML файла (см. п.2);
7. выполнение кода из .PHP файла (спасибо, Андрей Брус);
8. проверка какие файлы будут модифицированы в ходе установки, для того чтобы выдать вам их список в окне и ожидание подтверждения об установке.

В конечном итоге мы получаем скопированные новые файлы в папках нашей CMS, XML файл со сценарием (инструкциями) модификации в базе данных, и кеш этих самых модификаций в папке system/modification.

В целом система достаточно интересная и удобная для конечного пользователя, но не для разработчика. Почему? Потому что чтобы править модификации (инструкции к изменению файлов) необходимо править базу данных. При использовании классического vQmod для OpenCart для этого было достаточно править файл.

Кроме очевидного минуса с точки зрения удобства модификации инструкций, присутствует определенный плюс в данном методе хранения модификаций для файлов — более защищенное хранилище. Так как в базу данных мало кто имеет доступ, а на FTP могут иметь доступ многие (например для загрузки картинок на сервер), то данный метод может иметь преимущество, однако не стоит забывать что и на FTP можно дать доступ к определенной папке. (:

Для себя я сделал вывод, что данная система интересная, новая, удобная, но не для разработчика (: Будем следить дальше за развитием OpenCart 2, и за развитием модификаций и расширений для этой платформы.

Установка vQmod на OpenCart 2.x

Многие разработчики спрашивали, возможно ли использование vQmod как на предыдущих версиях OpenCart, и мой опыт говорит о том что можно! Просто установите его как обычно и пользуйтесь на здоровье. Если возникли проблемы, или вы располагаете иной информацией — пишите в комментариях.

OpenCart triggers

Работая над одним из проектов, я обнаружил в коде интересную строку:

$this->event->trigger('pre.admin.attribute.add', $data);

UPD: чатайте полный обзор в статье система событий в Opencart 2.x: как использовать event

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

На данный момент известно, что для регистрации функции на триггер необходимо написать:

$this->event->register('post.admin.attribute.add', 'checkout/order/send_email');

Однако больше информации внятной найти не удалось, если вы нашли что-то интересное или сами разобрались — пишите, дополним статью.

Подведем итог

В целом система развивается, обростая новыми и новыми функциями и фишками, оценить которые однозначно и объективно достаточно сложно. С моим мнением вы ознакомились, а ваше мнение буду рад прочитать в комментариях.

Надеюсь, очередной небольшой экскурс по новым фукнциям OpenCart 2.x был вам полезен и вы подчерпнули много новой и полезой для себя информации. Спасибо за внимание.

UPD: ознакомьтесь с системой событий и триггеров ($this->event) в новой статье система событий в Opencart 2.x: как использовать event

Однако, необходимо было решить задачу, и я нашел решение. Что ж, давайте вместе разберемся с данной проблемой.

В процессе написания плагинов и модулей для Opencart, в контроллере можно получить доступ к настройкам самого магазина, или же отдельных модулей, однако каково было мое удивление, когда при разработке модуля SEO URL для многоязычного интернет магазина, при обращении к массиву конфигурации $this->config->get(‘config_language’) я получал текущий язык, который выбрал пользователь.

То есть в данном массиве хранится код языка, на котором пользователь просматривает интернет магазин, и отнюдь не язык по-умолчанию: если по-молчанию стоит русский язык, а пользователь зашел и выбрал английский, то значение переменной $this->config->get(‘config_language’) будет «en».

Дело в том, что в файле index.php, где формируются все основные конфигурационные массивы и данные в данную переменную записывается значение текущего языка! Вот строки файла index.php, в которых видно, как в переменную заносится значение текущего языка:

if (isset($session->data['language']) && array_key_exists($session->data['language'], $languages) && $languages[$session->data['language']]['status']) {
$code = $session->data['language'];
} elseif (isset($request->cookie['language']) && array_key_exists($request->cookie['language'], $languages) && $languages[$request->cookie['language']]['status']) {
$code = $request->cookie['language'];
} elseif ($detect) {
$code = $detect;
} else {
$code = $config->get('config_language');
}

if (!isset($session->data['language']) || $session->data['language'] != $code) {
$session->data['language'] = $code;
}

if (!isset($request->cookie['language']) || $request->cookie['language'] != $code) {
setcookie('language', $code, time() + 60 * 60 * 24 * 30, '/', $request->server['HTTP_HOST']);
}

$config->set('config_language_id', $languages[$code]['language_id']);
$config->set('config_language', $languages[$code]['code']);

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

$this->load->model('setting/setting');
$store_settings_config = $this->model_setting_setting->getSetting("config", $this->config->get('config_store_id'));

echo $store_settings_config['config_language']; // Вот тут наш язык по-умолчанию

Вот таким вот нехитрым образом, хоть и сложнее, чем обращение в конфигурационный массив, можно получить язык пользовательской части вашего интернет магазина на Opencart по-умолчанию.

Данный пост размещаю тут больше, пожалуй, для себя, на будущее, однако если вы это читаете и вам помогло мое решение, не поленитесь и поставьте лайк, напишите комментарий. Заранее спасибо. Если возникли вопросы или предложения — пишите, обсудим.