Добавление таблиц

[asmus]

Задача - добавить новые таблицы. Прописал запросы в РНР файле (по логике вещей, надо полагать, что вставленный DB_PREFIX в sql файл будет причиной ошибки?), обозвал его Install.php, упаковал в архив lalala.osmod.zip и выбрал его для установки. Скачало, распаковало, сообщило все Ок, отобразилось в разделе админки lalala.osmod.. а таблиц нет. Что не так? 

Змінено 9 лютого 2020 користувачем asmus

[AUSS]

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

Задача - добавить новые таблицы. Прописал запросы в РНР файле (по логике вещей, надо полагать, что вставленный DB_PREFIX в sql файл будет причиной ошибки?), обозвал его Install.php, упаковал в архив lalala.osmod.zip и выбрал его для установки. Скачало, распаковало, сообщило все Ок, отобразилось в разделе админки lalala.osmod.. а таблиц нет. Что не так? 

в тройке такой вариант не пролезет

[asmus]

А какой вариант в ней прокатывает?

[AlexDW]

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

Задача - добавить новые таблицы.

напрямую в ДБ

 

если же делаете модуль

 

[asmus]

54 минуты назад, AlexDW сказал:

напрямую в ДБ

 

Так я поступил в конечном итоге, но  это временное решение. А постоянно проверять создана ли база в самом модуле (как по ссылке) тоже не очень гут. Кто по пьяни эту дурную CMS придумал.  

[Tom]

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

Кто по пьяни эту дурную CMS придумал

Здесь же не лыжи виноваты, а тот кто в них обут.

По ссылке было предложение добавлять таблицы с помощью того же xml файла.

Цитата

....

если мод из одного только xml и контроллера нет - цеплять проверку и создание данных в самом xml в подходящем месте

Пример:

$query = $this->db->query("DESC " . DB_PREFIX . "product_description add_info");
if (!$query->num_rows) { 
	$this->db->query("ALTER TABLE `" . DB_PREFIX . "product_description` ADD `add_info` text COLLATE utf8_bin NOT NULL");
}

 

[anboza]

а через PHPMyAdmin, уже не кошерно таблицы создавать?

[asmus]

9 часов назад, anboza сказал:

а через PHPMyAdmin, уже не кошерно таблицы создавать?

 

То есть пользователи всех этих CMS настолько продвинутые, то запросто могут все сами сделать, им только дамп отдай и все. О чем говорим? Если бы я для себя это делал, то я бы не задавал здесь вопросов.

 

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

 

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

 

Обратился ко мне как-то один заказчик, у него эта CMS, описал что нужно, и что у него есть. А ему нужно, чтобы его пользователи искали продукцию у его поставщиков. То есть, продукция не в базе его, это обращение к SOAP поставщиков, анализ ответов, выборка данных из ответов по условиям, компоновка и выдача результата пользователю. Задал вопрос - почему не сохранять результаты в базе, дабы ускорить обработку, исключив запросы к поставщикам по продукции, которая уже есть в базе. Среди доводов почему так нельзя, конечно, были и обоснованные, но ведь можно было бы сделать и синхронизацию, определив задачу для cron. Ну не понимает товарищ, ни в какую. Максимум, чем я мог облегчить ожидание пользователей, это хранить запросы в сессии под создаваемыми уникальными ключами.

 

Вот и получается, что из всей CMS используется скромная доля. Ответ на вопрос почему он эту CMS выбрал меня убил - ему посоветовали, ибо в ней есть возможность выбрать способ оплаты. Вот чем выгодно отличается эта CMS от других! Мне еще повезло, она была практически девственной, а он и не планирует, в чем меня сразу предупредил, чего-то добавлять, расширять, поэтому без всяких модификаторов переписал все что касается search.*, добавил несколько нужных методов в модель, "обрезал руки" всякому хламу, чтобы не мешал и все.

 

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

 

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

 

В общем, чтобы добавить ему то, что необходимо, перейти от "абстрактных координат", которые они в прямом смысле руками растягивают, к SVG, автоматизировав практически весть процесс от создания до производства, нужно кучу хлама выковырять, навести порядок с путями/именами и т.п., и т.д. А он, слушая все мои замечания, пояснения, которые в общем то он обязан был и так знать, хоть и выполняет их, спрашивает когда не понятно что, но скажем так - он из тех кто торопится, бежит впереди лошади. В этом случае лучше все взять под свой контроль, а не вот тебе "дамп, затем вот это сделать ...", из опыта знаю, что на каком-то этапе появиться баг. Но это не значит, что я должен ковыряться в РМА, и все сам через FTP рулить. 

 

Я одному рассказал, на свою голову, что такое РМА и о его возможностях, так он шельмец, иногда, такие подарки преподносит.      

 

Змінено 10 лютого 2020 користувачем asmus