Александр Мельник

У меня на днях был подобный глюк на одном очень странном хостере ho.ua.
Проблема оказалось в том, что они изменили hostname для подключения к базе данных.
Когда сайт устанавливался, были даны данные для подключения к базе hostname abs123 (к примеру)
А относительно недавно они переделали на localhost
При этом частично работал и сайт, но симптомы были именно как вы описываете. С точно правильным паролем войти нельзя, сбросить нельзя, в базе изменяю и все равно пишет что нет такого пользователя.
Заменил настройки подключения на localhost и сразу все заработало.

Спасибо. Но я не могу понять, как это может помочь?
Если данный инпут вставляется на событие загрузки страницы, то она произойдет и у «бота».
В 2022 году спам боты это очень совершенные программы, умеющие имитировать поведение пользователя на высоком уровне.
Но раз помогает, то наверное я в чем то не прав.

Какие родились у меня мысли.
Видимо почтовый сервис, делает какой-то предварительный запрос по ссылкам, указанным в письме.
С какой целью, понять сложно, может хотят убедиться что там не 404 или что там безопасно или ведут свою «слежку» за всем.
А уже потом человек кликает по ссылке и совершается второй запрос.
Только так я могу пояснить тот факт, что пользователь активируется, но человек перешедший по ссылке, видит надпись что такой пользователь не найден или уже был ранее активирован.
Это не приятно(

Ох страшное вы что то напридумали.
У вас проблема в том, что если вы находитесь на одной странице, кликаете на пункт меню, который содержит якорную ссылку на элемент на этой же странице, у вас не закрывается меню?
Почему не написать 3 строчки javascript которые при клике на ссылку в меню, кликнут по крестику закрывающему меню?

Вы правы на 100 процентов. Но я считаю, что развиваться нужно постепенно, гармонично и обдумано, что ли.
Бесполезно прыгать через три ступени, а лично для меня все те страшные слова, которые вы написали — это и есть «через три ступени»).
Так же наблюдая за собой, пришел ко мнению, что бесполезно вкладывать большие усилия в изучение того, что не понадобиться ближайший год. Нужно быть разносторонним, интересоваться разными аспектами программирования (мне например очень интересно и администрирование серверов), но тратить серьезные усилия нужно только на то, что сможешь применить в ближайшее время. Потому что что-то «выучишь», потом полгода это не применяешь, через полгода открываешь учебник и «как баран на новые ворота».
Понимаю вашу идею смотивировать самого себя, это очень достойно.

Уверен многих, как и меня, пугает фраза

Архитектура проектируется по DDD, слоями, планируется внедрение CQRS + Event Sourcing

Мы же на форуме о modx, у которого нет даже composer и автозагрузки классов, а тут какое-то DDD c SQRS )

только написать свой сниппет который принимает те же параметры что и pdoPage и который вернет общее количество страниц. Его вызывать в head.

Я понял, спасибо.
Если вы действительно осознанно выбрали typescript а не просто следуя трендам, это приятно и похвально.

А Руслан, простите, я думал это ответил автор заметки.

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

Насчет того, влияет ли последовательность выбора характеристик в фильтре. Вы правы, что не влияет. Но это если говорить о фильтре для покупателя. Ему не важно, сначала он выберет что хочет красную футболку а потом добавит что хочет еще и белые, или наоборот.
Но чаще всего наши СЕО специалисты требуют, чтобы фильтр не был только инструментом для пользователя но был и СЕО инструментом и тут начинается такое… Иногда бывают требования, чтобы урл страницы изменялся так, в какой очередности человек кликает в фильтре. К примеру если сначала на красный а потом на белый, то урл чтобы был
site.com/filter/red-white/
а если сначала на белый а потом на красный, то
site.com/filter/white-red/
и не смотря на то, что оба запроса вернут один и тот же товар, но например это позволит «порадовать» клиента, и показать ему товары сначала красные, а потом уже белые, тоесть «первое слово главнее второго)».
И получается что от очередности выбора характеристики напрямую зависит то, сколько данных нужно кешировать.

[[++site_url]][[*uri]]

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

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

ps. прочел внимательнее и понял, что на изучение ts вас толкнул выбор nest.js

Верно.

У меня вопрос, философский. Как раз вчера над ним размышлял и возможно вы поможете.
Вопрос наверное можно сформулировать так — откуда берутся стеки технологий?
Поясню, что я имею ввиду.
Если спросить у разработчика php какую базу данных он использует, 99 процентов ответят что mysql.
Врядли они смогут ответить на вопрос — почему.
Если спросить разработчика на python то ответ будет Postgress.
Если у разработчика на node js — ответ будет Mongo.
Хотя каждая из этих систем может работать с любой из этих баз данных.
Хотелось бы услышать ваш опыт — работая на php вы наверняка использовали mysql, а перейдя на nodejs выбрали mongo. Почему?
Просто потому что как в опыте с «обезьянками в запертой комнате» — здесь так принято?
Или вы провели для себя сравнительный анализ между возможными базами и выбрали mongo как лучшую?
Ведь mongo относится к группе nosql баз данных и чтобы работать с ней — нужно кардинально перестроить голову и мысли в ней, она очень отличается по характеру от mysql.

Наверное только тем, что для MODX я этого делать не умею)
Ну и в моем мировозрении это несколько странно. Систему нужно либо принимать как она есть или не принимать совсем.
Хотя несколько раз я делал нечто подобное, если клиенты уж совсем психовали — делал отдельные страницы для управления некоторыми данными, которые не были связаны с админкой и «закрыты» теми или иными способами. Но это скорее исключение из правил.
Плюс мне «удобно думать» в концепции MVC, а в MODX она очень искажена на мой взгляд.
Как то вот комфортно мне в той микросреде, которую я вокруг slim себе создаю — slim, composer, orm doctrine, twig, php-di, классический mvc, поддержка стандартов psr-7, middleware и psr-15, стараюсь использовать чистый js и parcel (кстати отличная альтернатива излишне замороченному webpack)

Вы правы. Специфика работы той фирмы в которой я «программист» — это не разработка сайтов. Основной упор делается на СЕО продвижение, поэтому к нам приходят (ну или мы ищем) уже готовые сайты, на которые все махнули рукой разработчики, а заказчики недовольны прибылью от сайта. В данном контексте программист получается лишь придатком, цель которого исполнять бесчисленные и иногда бессмысленные идеи наших сео специалистов. Сайты приходят разные, сделанные на чем угодно, поэтому и работать приходится со всем подряд.
Но все же в 30 процентах случаев мы делаем заказчику новый сайт. И тогда я уже стараюсь хоть примерно (как правило заказчик сам понятия не имеет что ему нужно да и сео специалисты тоже) пытаюсь провести анализ и выбрать инструмент. Если это что то очень простое и на всю разработку дается 4-5 дней, то делаю на modx или opencart. Если позволяет время и я вижу, что проект по моим меркам средний или выше среднего по сложности — выбираю slim.
Наверное есть и вторая причина, почему выбираю не modx. Я не умею делать на нем красивые админки. Когда в админке работают наши контент менеджеры, то они привыкли к админке modx. Но если в админке будет работать заказчик — они все поголовно жалуются, что сложно, ничего не понятно, какие-то ресурсы…
А slim позволяет разработать свою админку, лаконичную и понятную.
Почему именно slim — наверное люблю минимализм. Смотрел в сторону laravel и понял что он мне не приятен именно тем, что в нем многое уже реализовано. Разговаривал с одним своим коллегой, просил его рассказать что такое storage в laravel, потому что сам не очень понял. Он сказал — а зачем ты пытаешься понять, вот же в документации написано — пишешь вот это, вызываешь такой то метод и все. Я так не люблю, мне такой подход не нравится.
Как раз в данную минуту разрабатываю личный кабинет для клиентов компании воздушного такси.

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

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