danforth

danforth
Рейтинг
153
Регистрация
18.12.2015

ubuntu@ubuntu-xenial:~$ sudo ls /etc/php/7.0/fpm/conf.d/

10-opcache.ini 20-curl.ini 20-gd.ini 20-phar.ini 20-sockets.ini 20-wddx.ini
10-pdo.ini 20-dom.ini 20-gettext.ini 20-posix.ini 20-sysvmsg.ini 20-xmlreader.ini
15-xml.ini 20-exif.ini 20-iconv.ini 20-readline.ini 20-sysvsem.ini 20-xmlwriter.ini
20-calendar.ini 20-fileinfo.ini 20-json.ini 20-shmop.ini 20-sysvshm.ini 20-xsl.ini
20-ctype.ini 20-ftp.ini 20-mbstring.ini 20-simplexml.ini 20-tokenizer.ini 20-zip.ini

Да я понимаю, что phpenmod включает. Только толку-то. Вот пример:

ubuntu@ubuntu-xenial:~$ sudo phpenmod curl

ubuntu@ubuntu-xenial:~$ sudo phpenmod mbstring
ubuntu@ubuntu-xenial:~$ sudo service php7.0-fpm restart
ubuntu@ubuntu-xenial:~$ php -m

calendar
Core
ctype
date
dom
exif
fileinfo
filter
ftp
gd
gettext
hash
iconv
json
libxml
openssl
pcntl
pcre
PDO
Phar
posix
readline
Reflection
session
shmop
SimpleXML
sockets
SPL
standard
sysvmsg
sysvsem
sysvshm
tokenizer
wddx
xml
xmlreader
xmlwriter
xsl
Zend OPcache
zlib

[Zend Modules]
Zend OPcache

Зона в основном под софт и стартапы. От Input/Output.

Я бы задумался над тем, чтобы оптимизировать архитектуру. Если они были написаны в 2000-х, значит код старый. Можно все переписать, прикрутить кеши всякие, освежить все. Пережмите все стили, html шаблоны можно компилировать без табов и переносов строк. Экономит на 50% вес самой страницы. Базу тоже можно оптимизировать. Переписать запросы.

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

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

1) Человек вводит на сайт vasya@ramler.ru (не хватает буквы b)

2) Вы берете доменную зону ramler.ru и высчитываете расстояние между теми доменными зонами, на которые письма успешно доходят.

3) Сравниваем ramler.ru и rambler.ru - расстояние 1, потому что не хватает одной буквы (b). Тут утрированно, можно сделать так, что на вставку и на замену разные очки/баллы. Но в вашем случае достаточно 1 для всех случаев не попадания.

4) Если левенштайн > 1 значит что-то не так. Предлагаем варианты, отсортированные по возрастанию левенштайна.

5) Если левенштайн = 0 - значит, как минимум домен, корректный.

Но ошибиться он может и до знака @. Тут поможет подтверждение почты. Можно прикрутить авторизацию по телефону, но тут затраты на SMS. Дебилизм не искоренить.

К наркоману нужно относится так, как будто это человек с раздвоением личности. Сегодня он говорит что готов бросить и сделает все что скажете, завтра пойдет за дозой. И подход нужен соответствующий. Работал с дядькой, который тоже наркоманил сильно по молодости. Единственное что остановило: смерть матери. После похорон зарекся, не пить и не употреблять. Если честно, вы вряд ли что-то сделаете тут. Он сам должен к этому прийти, через какой-то стресс или эмоции. При этом важно не доводить до отчаяния, в котором человек может сорваться и заново начать наркоманить. Если он сам не захочет - то вы ему не поможете. Наркоман становится настолько изобретательным, что вы даже не поймете как он проносит и где берет дозу.

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

id: 2647,
sku: "ng-ch-10",
name: "Чашка новогодняя с рисунком обезьяны",
price: 199.99,
url: "store.ru/chashka-novogodnyaya-s-obezjanoy/"

В данной ситуации девочка просто создала новый товар потому что скоро новый год. А старый скрыла с витрины. Сама чашка - та же. И все. Реальная ситуация, где поставщики меняют артикулы как захотят и когда захотят. И объясняй ты им хоть ты тресни, что артикул создается раз, он должен быть уникальным, и не меняться на протяжении жизни товара. Они в артикул вообще могут "1" вписать. Привязываться к идентификаторам поставщиков нельзя. Вообще у меня реализована система, когда прайс импортируется, то все данные сохраняются во временную таблицу. Когда ты заходишь в импорт, там видно товар до, и товар после. И кнопки "Применить все" и "Применить выделенные". Даже после применения есть возможность откатиться назад. Потому что есть лог импортов. Но опять же, автоматизировать я это никогда не рискну, потому что часто косяки.

Marat_Kh, ну и код)) 😕

[id] VARCHAR(32) PRIMARY KEY ON CONFLICT ROLLBACK NOT NULL UNIQUE, 

id = strlen($url)>32 ? md5($url) : str::translit($url,'_', str::URL);

Данная конструкция шаткая. Объясняю: если символов меньше или равно 32, то вы транслитеризируете текст, очевидно на английский. Я конечно не знаю что там у вас за транслитеризация, но если она какая-то более вменяемая, то подав на вход url текст "Жирный жираф бежит через поле" на выход вы получите "zhirnyiy_zhiraf_bezhit_cherez_pole", что уже не вмещается в 32 символа VARCHAR(32), потому что их тут 34.

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

_SP_:
Вы мне одно объясните, нафига ВП для сайта ресторана-то ?
Чем нотепад + html не подходят ?
Не хватает сил освоить десяток тэгов ?

Ну вообще, как бы да. Можно и так. Почитайте эту тему: /ru/forum/953962

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

Marat_Kh:
Варианты:
$vendorId . $itemId; $vendorId . $name; $vendorId . $sku; $vendorId . $catId . $sku | $name | $itemId;
--- или
url (md5|crc от url) - считаю самым простым и лучшим, но каждый урл реально д.б. уникальным на вашем сайте. В случае смены урл, в таблице обвеса тоже надо изменить. Уполномоченный юзер (role=manager например) зашел залогиненным на документ, ткнул капу, залил фото/отредактировал текст/(....). По крону, таблица обвеса, чистится от того, чего уже нет на сайте.

Вот вам прайс из одного товара.


id: 2047,
sku: "001-red",
name: "Чашка с обезьяной",
price: 199.99,
url: "store.ru/chashka-s-obezyanoy/"

Пусть я буду vendor = 1;

Покажите как вы его сохраните у себя, со всеми таблицами.

Marat_Kh:
Важно где хранить в ВП и как оттуда быстро добывать, при этом обезопасив себя от коллизий при обновлении прайса и от обновления ВП. И, вообще, есть ли тогда смысл в ВП, только для роутинга (гуру ВП помогите человеку), загрузки картинок, размещения десятка статичных страниц, отчетов вукомерса, м.б. платежей картой и еще там чего по мелочи. Коли мы все равно напишем 100500 строк кода и создадим x-таблиц/файлов для хранения данных (привет обновлениям ВП/плагинов).

Как хранить? Да так же, как и на фреймворках. Только проблема в том, что я не сторонник WP (пруф за 2016 год), но я всегда буду выбирать нужный инструмент под конкретную задачу. А задача другая: сайт ресторана а не интернет-магазина.

Ну а по поводу роутинга, нужно делать canonical. Показывать или не показывать страницу при опечатке или точке/слеше в конце - спорный момент.

borisd:
Простой пример: если описания отделены от товаров, то я могу спокойно удалить целиком базу товаров и импортировать её из файлов поставщиков заново. Все описания товаров останутся на месте. А если описания находятся в самих товарах, то вы уже будете связаны по рукам и ногам при импорте.

А связываете вы описания с товарами как? По SKU который дает поставщик? А если два поставщика дадут одинаковые SKU? А знаете как поставщики меняют SKU? А если привязываете к какому-то PRIMARY KEY AUTOINCREMENT, тогда не прокатит ваш трюк.

Marat_Kh, с трудом понимаю ваши посты, манера речи у вас немного не ясная, но все же... Права доступа на что? Есть RBAC/ABAC, выдал контентщикам доступ на изменение фоток и описания, и все. Все остальное не видят. Для этого обязательно микросервис пилить? И то что вы мне скинули, в частности ItemSpecifics, это EAV, ясное дело что никто не будет хранить его в таблице рядом с товаром, хотя BJSON это позволяет и более того, решает некоторые вопросы проивзодительности.

Всего: 1540