asmus

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

Ну в общем я так тоже писал, проще метки времени проверить, ну или интервал в DateInterval.Тут я не так выразился, проблема не в том как получать время, а скорее в том "когда определять" его. То есть он может загрузить файл, а потом чесать репу или слоняться бог знает где время, а только потом сохранить. Все усугубляется тем, что нужно это определять гарантированно и вот почему. Это производство модульных картин. До этого у них был просто кошмар с опциями и их значениями, что Opencart предлагает. У них из-за этих опций около 5000 изображений бесхозных в базе обнаружил, а в каталогах там вообще черт ногу сломит. Поэтому и добавлено удаление при изменениях, переносах ... Весь этот хлам с опциями я удалил, все сделано с использованием SVG. По координатам готовятся svg-маски для отображения модулей на странице, и svg-иконки модулей для списков. Все это хранится в добавленных таблицах. Модули я условно разделил на базовые и индивидуальные. Базовые, это кто-то им делал до этого, просто в common.js прописаны координаты из под CorelDraw приготовленные. Кошмар неописуемый, да еще и с ошибками, их отредактировал и это есть базовый. Индивидуальный, это я сделал редактор в админку для их изготовления, ну то есть canvas и прочее от JS. А еще к порядку относится то, что нельзя же любой модуль "натянуть" на любое изображение, если он масштабируется пропорционально, это понятно. Также нельзя модуль для альбомной ориентации применять к портретной, и отношение сторон изображения и модуля не должны отличаться на максимум 0,1 - 0,2. Также нельзя применять индивидуальные модули другим продуктам. Ориентацию и отношения проверить конечно легко, если они не отвечают условиям, то определенные для продукта модули нужно удалять из базы.Но как быть, если и ориентация та же, и отношения в пределах нормы, и имя осталось тем же (о путях можно не говорить, они вообще редко будут меняться), а изображение изменилось? Ведь не только выше указанные параметры определяют "нельзя", но еще и содержимое изображений. На одном какой либо модуль будет нормальным, а на другом "глаз баба потеряет". Вот и нужна гарантия, точно знать, что нужно "сбрасывать" установки. У меня такое чувство, что я топчусь где-то рядом, но никак не могу поймать кошку за хвост.

Диспозиция: 1) У продукта могут быть только два изображения - основное и одно дополнительное, в соответствующих таблицах, которые тут всем известны, прописанные. 2) Основное изображение в конечном итоге будет типа PNG с прозрачностью, но изначально может быть и JPEG, как ранее определенное. 3) Дополнительное изображение может быть только типа JPEG, оно уменьшается при загрузке исходника до фиксированной заданной ширины (или высоты этой же для портретной ориентации). 4) Модифицирован файловый менеджер для определения какое изображение загружается - основное или дополнительное, чтобы уменьшить дополнительное или если загрузка PNG, то сделать запрос на сервер TinyPNG для уменьшения его веса. Иначе он работает как по умолчанию (для прочих изображений). 5) Добавлен класс транслита по "правилам" Яндекса и при сохранении продукта его имя проходит через транслит и результат транслита подставляется в поле SEO пришедшей формы, а также: а) имена всех каталогов продукта (от владельца до верхнего уровня категории продуктов) проходят транслит, из них формируется путь, к которому подставляется имя продукта б) этот сформированный путь подставляется в полях пришедшей формы для основного и дополнительного изображения в) к пути/имени дополнительного изображения подставляется фиксированная величина на которую оно уменьшается, дабы их различать, так как "исходники" в одном каталоге, а разделять это потом, сейчас рук на все не хватает 6) Перед обращением к модели сохраняющей изменения, в добавленный метод отдаются два массива: а) нового файла, это под ключом 'dirname' сформированный по именам каталогов путь и под ключом 'filename' имя продукта, то есть, это не изображение под расширением, это только имя б) старые, существующие пути, взятые из соответствующих таблиц продукта (и могут быть пусты), под ключом 'main' имя основного изображения, под ключом 'add' дополнительного И вот в этом методе логика обработки не нравится мне, чую что есть "дыра" в ней, и рано или поздно будут косяки. Работает так: 1) Путь/имя новое через pathinfo(). В данном случае оно и не нужно было бы, но это заложено для того чтобы использовать этот метод для переноса файлов при смене каталогов. 2) Массив старых путей обходом в цикле, в котором а) текущий файл через pathinfo(), и проверяется: если 'dirname' нового и старого путей не равны, или 'extension' есть в новом пути (при редактировании его нет, как я писал выше) и оно не равно 'extension' старого пути (это как раз проверка при смене JPEG на PNG) или разница текущего времени и времени последнего изменения старого пути в пределах не более одного часа, то: 1) rename(старый путь, новый путь и если ключ 'add', то добавить к имени фиксированный размер) 2) если по старому пути есть "эскизы малые" изображений, то они удаляются 3) если после операций переименования/удаления эскизов каталог пуст, то удаляем его Оно вроде бы работает, но, был косяк, когда при сохранении основного изображения и тоже формата JPEG исчезло дополнительное. Но в момент когда я щелкал и выбирал файлы для продукта, что-то случилось с мышкой, после чего она "прилипла" к нижнему левому углу экрана и ни за что оттуда не убиралась, даже выше панели задач не выходила (это все десятка мать ее). В общем после борьбы с "железом" проверял всякие вариации, такого не наблюдалось, и остается только гадать, либо это был косяк системный/железа, либо все-таки есть "косяк" в моей логике. Более всего меня напрягает проверка по времени, ну как еще можно определить, что файл изменился при равенстве имен. Может есть другие идеи, вообще иной подход?

То есть пользователи всех этих CMS настолько продвинутые, то запросто могут все сами сделать, им только дамп отдай и все. О чем говорим? Если бы я для себя это делал, то я бы не задавал здесь вопросов. Бесспорно, эта CMS может торговать от памперсов до мармелада. Но распиарили слишком, не стоит она этого, она во многом "грязная", не логичная, и до ужаса не удобная в управлении. То есть, если покопаться в ней как следует, то тараканов в ней как на кухне ночью. Вот армия разработчиков и допиливает все ее темные стороны. А каждый то видит мир по своему, а четких соглашений нет, единого координирующего центра тоже, и потом как влезешь в такое, то легче весь этот хлам выбросить и написать весь движок заново. Это не укор в сторону разработчиков, это беда пользователей этой CMS, которые не понимают, что если с ее помощью можно торговать памперсами, то это еще не означает, что она идеальный выбор и для иного. И кто бы не загибал пальчики, и не доказывал, что можно написать любой модуль для нее и она будет и спицами вязать, это не так. Написать можно, а как же при этом ненужный мусор рядом? Обратился ко мне как-то один заказчик, у него эта CMS, описал что нужно, и что у него есть. А ему нужно, чтобы его пользователи искали продукцию у его поставщиков. То есть, продукция не в базе его, это обращение к SOAP поставщиков, анализ ответов, выборка данных из ответов по условиям, компоновка и выдача результата пользователю. Задал вопрос - почему не сохранять результаты в базе, дабы ускорить обработку, исключив запросы к поставщикам по продукции, которая уже есть в базе. Среди доводов почему так нельзя, конечно, были и обоснованные, но ведь можно было бы сделать и синхронизацию, определив задачу для cron. Ну не понимает товарищ, ни в какую. Максимум, чем я мог облегчить ожидание пользователей, это хранить запросы в сессии под создаваемыми уникальными ключами. Вот и получается, что из всей CMS используется скромная доля. Ответ на вопрос почему он эту CMS выбрал меня убил - ему посоветовали, ибо в ней есть возможность выбрать способ оплаты. Вот чем выгодно отличается эта CMS от других! Мне еще повезло, она была практически девственной, а он и не планирует, в чем меня сразу предупредил, чего-то добавлять, расширять, поэтому без всяких модификаторов переписал все что касается search.*, добавил несколько нужных методов в модель, "обрезал руки" всякому хламу, чтобы не мешал и все. А теперь аналогичный случай, в связи с чем и обратился я сюда с вопросом. Опять эта же CMS, мать ее, опять неудачный выбор. Он не торговец памперсами, он оказывает платные услуги, это определение более подходит для него. Его продукция специфическая, ей не нужно определять вес, она не имеет проекции слева, справа, ..., только в анфас, а значит у нее не может быть кучи картинок для галереи. Но в том же время его продукции важно отмечать в базе ширину и высоту, но не в тех единицах которые нужны для другой продукции, и которые определены базой CMS. А определение ширины и высоты не означает, что их нужно показывать на страницах, это чисто для служебного пользования. И такого мелкого, и более объемного много, чего нет у данной CMS, но зато есть многое, что в данном случае куча хлама, не более, очень и очень много. Создавать полностью свои таблицы категорий, продуктов и для всего что связано с ними, и которые будут действительно оптимальны для его продукции, свои методы обращений к ним, а не то что в CMS через пень колоду.., это конечно же опять получается, что легче свое, чего ковыряться в чужом. Долго можно описывать какой кошмар у них творится сейчас на сайте. Но кто из разработчиков, с какого перепоя написал для этой CMS модуль массовой загрузки продукции на сайт, определения путей/имен, которые будут прописываться в базе. Это же какую траву нужно было курить, чтобы именовать продукты так как это делает этот модуль. Я такой ужас впервые наблюдаю. И это бля....тво обязательно нужно тоже исправить. В общем, чтобы добавить ему то, что необходимо, перейти от "абстрактных координат", которые они в прямом смысле руками растягивают, к SVG, автоматизировав практически весть процесс от создания до производства, нужно кучу хлама выковырять, навести порядок с путями/именами и т.п., и т.д. А он, слушая все мои замечания, пояснения, которые в общем то он обязан был и так знать, хоть и выполняет их, спрашивает когда не понятно что, но скажем так - он из тех кто торопится, бежит впереди лошади. В этом случае лучше все взять под свой контроль, а не вот тебе "дамп, затем вот это сделать ...", из опыта знаю, что на каком-то этапе появиться баг. Но это не значит, что я должен ковыряться в РМА, и все сам через FTP рулить. Я одному рассказал, на свою голову, что такое РМА и о его возможностях, так он шельмец, иногда, такие подарки преподносит.

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

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

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