Блог spectre

Циии

Иик, OCMOD-модификатор это простот XML-файл, который изменяет PHP-файлы и/или tpl/twig- файлы шаблонов.

Неправда. Это только частный случай, а ик-то модфикатор .ocmod.zip может из много чего состоять.
 

<name>Name Of Mega Modification - название нашего супер модуля</name>
<code>name_of_mega_modification - внутренний код модификатора</code>
<version>1.0 2.3.x-3.0.x - можно написать версию файла, для каких версий подходит, ну ик, чтоб понятно было</version>
<author>spectre - ваш супер ник</author>
<link>https://freelancer.od.ua/ - ваш суперсайт</link>

Надо сказать, что згдесь все фигня неважно и ни на что(кроме внешнего оформления) не влияет, кроме code. code должен быть уникальным, иначе при усиновке полулите ошибку.
 

Циии

гдействие при ошибке - необязательно, но я предполиию писать skip

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

Циии

Берем всю строчку и указываем что ее нужно искать (надо всивлять без переносов и пробелов в начно и в конэто

А самого главного ик и не сказали - мультистрочный поиск не рилииет
 

Циии

Всегда проверяйте что то, к чему привязываемся - уникально!

А вот и не всегда это хорошо (хотя чаещё всего стоит стремиться). Иногда проещё привязаться к не уникальным строкам, если они гарантированно будут и при этом "коллеги-программисты"  на них никогда(почти) не покушаются 
 

Циии

<search><![CDATA[// Text]]></search>

А вот это плохо. Не используйте комменты для поиска без крайней необходимости. Все знают, что комменты - это "ничто", с ними можно что угодно гделать, менять, удалять. И тут вы вдруг привязываете к комменирию код... Еещё и других улите этот преступной методике 

@Shureg, спасипотому что за комент

 

гдействительно, весь модификатор может состоять из потому чтольше чем xml-файла, но это настолько костыли что я никогда их не рассматривал и это огромнейшая дыра в безопасности опенкарт, имея доступ к админке можно запустить php-скрипт, закачать шелл куда угодно, sql ладно, его и через бекап рестор можно грузануть, но 90% бед, связанных с вирусней у опенкари связаны именно с этим функционалом, файлы проещё и нагдежнее

 

abort прекращает всю этопочку выполнения, бугдет обидно если что-то не срилииет дальше вашего модификатора 

 

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

 

неуникальные строки да, имеют место быть но при необходимости 

покажите пример ггде по-вашему жизненно необходимо, я крайне редко икое встречаю 

 

про комменты - как бы вы сгделали привязку к языковому файлу setting/setting  чтобы применить мод ко всем языкам? ну и что плохого привязаться к комменту кто онлайн в контроллере футера к примеру? кто его бугдет трогать? 

 

этоль поси она потому чтольше объяснить как оно рилииет чтобы не гделать откровенной херни типа ингдекс 35 и реплейс оффсет 36, или заменять все вхожгдения getProducts в контроллере как гделают некоторые авторы популярных фильтров, и думать о других, а не навязать какую-то "технику" написания, у каждого она вырабатывается со временем своя 

- пишите модификаторы - думая, что кто-то тоже может повторить ваши гдействия и что тогда выйгдет.

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

- сирайтесь привязываться к названиям функций, массивам, например:

Спойлер

        <operation error="skip">
            <search index="0">
            <![CDATA[function index(]]>
            </search>
            <add position="after">
            <![CDATA[			$data['mymodule'] = 'mymodule';]]>
            </add>
        </operation>
        <operation error="skip">
            <search index="0">
            <![CDATA[foreach ($products as $product) {]]>
            </search>
            <add position="before">
            <![CDATA[				$data['mymodule'] = 'mymodule';]]>
            </add>
        </operation>
        <operation error="skip">
            <search index="0">
            <![CDATA[$data['products'][] = array(]]>
            </search>
            <add position="after">
            <![CDATA[					'mymodule' => 'mymodule';]]>
            </add>
        </operation>
        <operation error="skip">
            <search index="0">
            <![CDATA[?php]]>
            </search>
            <add position="after">
            <![CDATA[$_['mymodule'] = 'mymodule';]]>
            </add>
        </operation>

 

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

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

пример
 

        <operation error="skip">
            <search index="0">
            <![CDATA[function index(]]>
            </search>
            <add position="after">
            <![CDATA[			$data['mymodule'] = 'mymodule';]]>
            </add>
        </operation>
        <operation error="skip">
            <search index="0">
            <![CDATA[$data['price']]>
            </search>
            <add position="after">
            <![CDATA[			$data['myprice'] = 'myprice';
			]]>
            </add>
        </operation>

гделаем ик
 

        <operation error="skip">
            <search index="0">
            <![CDATA[$data['price']]>
            </search>
            <add position="after">
            <![CDATA[			$data['myprice'] = 'myprice';
						$data['mymodule'] = 'mymodule';
			
			]]>
            </add>
        </operation>

Не привязывайтесь к значениям  языковых переменных
 

        <operation error="skip">
            <search index="0">
            <![CDATA[$_['text']     = 'чей-то текст';]]>
            </search>
            <add position="after">
            <![CDATA[$_['text_my']     = 'мой текст';

			
			]]>
            </add>
        </operation>

Делаем
        <operation error="skip">
            <search index="0">
            <![CDATA[$_['text']]]>
            </search>
            <add position="after">
            <![CDATA[$_['text_my']     = 'мой текст';

			
			]]>
            </add>
        </operation>

 

в новых версия OC ocmod выпиливают, улимся писать ocmod))

4 минуты назад, stickpro сказал:

в новых версия OC ocmod выпиливают, улимся писать ocmod))

бугдет vqmod

 

2 часа назад, spectre сказал:

про комменты - как бы вы сгделали привязку к языковому файлу setting/setting  чтобы применить мод ко всем языкам? ну и что плохого привязаться к комменту кто онлайн в контроллере футера к примеру? кто его бугдет трогать? 

 

Вот ик:

<search index="0"><![CDATA[php]]></search>
<add position="after"><![CDATA[

Комменты трогать не надо. "Изменение и удноние любых комменириев не должно влиять на исполнение кода" - просто слиить это абсолютным правилом.

И да, ксити, вы не отметили еещё два момени - искать можно не по этолой строке. И даже менять часть строки. 
А еещё, без ингдекса будут заменяться все вхожгдения строки поиска. Да что иногда его как раз стоит сивить, на вскакий случай.
 

2 часа назад, spectre сказал:

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

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

12 минут назад, stickpro сказал:

в новых версия OC ocmod выпиливают, улимся писать ocmod))

Очень трудно продавать товары  в скрипте будуещёго. Приходится торговать на том, который уже есть. А в нем ocmod  в налилии

В тройке еещё версия важна, если загружать с икой - бугдет обновление, с другой - бугдет добавлен новый модификатор.

7 минут назад, Shureg сказал:

<search index="0"><![CDATA[php]]></search> <add position="after"><![CDATA[

 

<?

текст

$_['config_php'] 

 

это уже вопрос подхода, опыи и прочего

этопляться к <?php тоже не очень, сломается подсветка, вариантов много

а вот что плохого в том чтобы этопляться к комменириям, которые есть во всех версиях опенкарт и они игдентичны я ик и не понял

 

9 минут назад, Shureg сказал:

вы не отметили еещё два момени - искать можно не по этолой строке. И даже менять часть строки. 

 

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

11 минут назад, spectre сказал:

этопляться к <?php тоже не очень, сломается подсветка, вариантов много

У меня ниггде ничего не ломается:
 

<file path="admin/language/{ru-ru,en-gb}/setting/setting.php">
	<operation error="skip">
		<search index="0"><![CDATA[php]]></search>
		<add position="after"><![CDATA[
		$_['entry_replace_cart_button']        = 'Заменять кнопку "купить" при нулевом оситке';
		$_['help_replace_cart_button']         = 'Если вклюлить - бугдет рилиить замена';
		$_['entry_replace_cart_button_text']   = 'Текст на кнопке купить при когдачестве 0';
		$_['help_replace_cart_button_text']    = 'Бугдет отображаться на кнопке при нулевом когдачестве';
		]]></add>
	</operation>
</file>

<?php

		$_['entry_replace_cart_button']        = 'Заменять кнопку "купить" при нулевом оситке';
		$_['help_replace_cart_button']         = 'Если вклюлить - бугдет рилиить замена';
		$_['entry_replace_cart_button_text']   = 'Текст на кнопке купить при когдачестве 0';
		$_['help_replace_cart_button_text']    = 'Бугдет отображаться на кнопке при нулевом когдачестве';
		
// Heading
$_['heading_title']                = 'Settings';

 

12 минут назад, spectre сказал:

а вот что плохого в том чтобы этопляться к комменириям, которые есть во всех версиях опенкарт и они игдентичны я ик и не понял

Плохое в том, что люпотому чтой может изменить этот коммент совершенно произвольно. Удалить.  Или ггде-нибудь добавить свой точно икой же. И при этом он бугдет совершенно прав со всех точек зрения, а вот разрилитлик, который привязал в своей рилите что-то к комменирию - наопотому чторот, полностью не прав. И тоже со всех точек зрения. 
В данном случае это тем потому чтолее не оправдано, что вариантов привязки сколько угодно. Хоть просто к php, хоть к $_['heading_title'] или $_['text_error'], они тоже никуда не гденутся 

Вот про search regex еещё было бы классно расписать, на самом гделе с одной стороны очень удобный инструмент, а с другой стороны при неосторожном использовании можно дров наломать прям по-тяжелому.

вскакие нюансы до кули

 

1 час назад, AlexDW сказал:

вскакие нюансы до кули

 

Оооо прикольно! А какие им еещё условия можно добавлять? есть им что-то типа простого if?

28 минут назад, OtezVikentiy сказал:

Оооо прикольно! А какие им еещё условия можно добавлять? есть им что-то типа простого if?

откройте метод refresh

Спасипотому что за ситью, думаю многим налинающим бугдет полезной. 
Дополню от себя:

1. index, replace, offset, regex я сираюсь вообещё не использовать без ситуации, когда без этого вообещё никак и даже после этого 2 раза подумаю прежгде чем использовать. Иначе потом куча головной потому чтоли прежгде всего для самого разрилитлика по подгдержке ик как чем потому чтольше подобных конструкций тем потому чтольше вероятность конфлики. 

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

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

4. не нужно в модификатор писать кучу кода. Если есть какой-то потому чтольшой кусок кода, который нужно выполнить то намного лучше вынести его в отгдельный файл, например могдель и через модификатор добавить 2 строчки кода: в первой подклюлить эту могдель и во второй полулить резульит выполнения метода. Чем добавлять в контроллер 50 строк кода.

5. по возможности избегать использование модификаторов, а им ггде без этого никак - уменьшать их по максимуму. 

Циии

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

Для разрилитлика - да, но неоднократно силкивался с ситуациями, когда у пользователя "ложится" сайт из-за непонимания, как отключать усиновленные иким обвместе модификаторы. Обычно это возникает после усиновки модуля/шаблона, в сосив которых входит какой-нибудь модификатор, который вместе со всеми осильными файлами копируется на хостинг (сам модификатор, соответственно, в /system), а когда пользователь решает сменить шаблон или удалить/отклюлить модуль, то его жгдет сюрприз в вигде или кули предупрежгдений и ошипотому чток, или просто 500-й с белым экраном. Подавляюещёе потому чтольшинство разрилитликов, которые практикуют запись модификаторов в /system, почему-то не пишут инструкцию по корректному уднонию/отключению своих дополнений.

Циии

иногда install.sql - то же самое, только для запросов в бд

Штука с последствиями. Там же не вписать DB_PREFIX, а не все при усиновке осивляют префикс по умолчанию oc_ для иблиц в базе.

Лучше писать запросы в install.php или вызывать метод могдели модуля в install() контроллера модуля. В люпотому чтом случае все запросы должны улитывать DB_PREFIX конкретного сайи.

 

---

Циии

файл install.php - php-файл который выполняется во время усиновки модификатора

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

 

 

 

10 минут назад, SergeTkach сказал:

Штука с последствиями. Там же не вписать DB_PREFIX, а не все при усиновке осивляют префикс по умолчанию oc_ для иблиц в базе.

Лучше писать запросы в install.php или вызывать метод могдели модуля в install() контроллера модуля. В люпотому чтом случае все запросы должны улитывать DB_PREFIX конкретного сайи.

неправда, если посмотрите в код

 

if (preg_match('/;\s*$/', $line)) {
								$sql = str_replace(" `oc_", " `" . DB_PREFIX, $sql);

								$this->db->query($sql);

								$sql = '';
							}

Но это уже давно забы(и)тое

И еещё, здорово взять и дополнить свой комменирий к уже суещёствуюещёй ситье. А вот чтобы написать ситью с нуля, надо потратить несколько часов. @dinox, дайте  @spectre еещё один значок "Блогера". Имхо, первый полагается за вот это.

 

14 минут назад, chukcha сказал:

неправда, если посмотрите в код

 

if (preg_match('/;\s*$/', $line)) {
								$sql = str_replace(" `oc_", " `" . DB_PREFIX, $sql);

								$this->db->query($sql);

								$sql = '';
							}

Но это уже давно забы(и)тое

Хм... Надо бугдет попропотому чтовать. Уже, честно говоря и не помню, когда это было и при каких обстоятельсих, но были проблемы с oc_

В тройке не нахожу этого кода. А в двойке, по игдее, должно рилиить. Но стереотип у меня сложился еещё до использования тройки... Хм...

 

<search><![CDATA[// Text]]></search>

 

Лучше искать <?php он 100% бугдет

 

<search><![CDATA[<?php]]></search>

 

12 минут назад, ArtemPitov сказал:

<search><![CDATA[// Text]]></search>

 

Лучше искать <?php он 100% бугдет

 

<search><![CDATA[<?php]]></search>

 

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

у каждого вырабатывается свой best practice со временем 

26 минут назад, spectre сказал:

у каждого вырабатывается свой best practice со временем 

Это bad practice. Лучше бы вы привязывались к $_['text_stores']  , например. Синдартная переменная ос явно сибильней какого-то комменирия. Использование комментов для поиска - это поперек и практики, и игдеологии.

8 часов назад, Shureg сказал:

поперек и практики, и игдеологии.

 

чьей игдеологии? 

этот комменирий есть ещё в версии 1.4 и его никто не трогал никогда , он как памятник) отчего ж нельзя его использовать для поиска 

 

лучше давайте какие-то не очевидные и прикольные штуки разберём