Ну и получается, что я узнал для себя совершенно новый функционал composer
Он проверяет текущую версию программ на моей машине и скачивает ту версию, которая под них подходит. Наверное поэтому он мне все время подсовывал версию 3,4.
И даже если открыть спецификацию более современного тега picture там тоже указано что атрибут src у img обязателен www.w3schools.com/tags/tag_picture.asp
Форма авторизации реагировала на ввод неправильных данных, но как ввел правильные, снова увидел страницу
file.modx.pro/ и кнопку Авторизация.
Если перешел на страницу файлохранилища будучи авторизованным (в момент написания комментария предположим), то вижу лишь страницу с кнопкой авторизоваться и она не работает.
drive.google.com/file/d/1d_nrXTF-TTSDDmyYrNBs5kFgS17KOEjB/view?usp=sharing
вот здесь кликаю по кнопке
file.modx.pro/
Перезагрузка страницы и ничего более.
Совершенно этого не знал, думал какую версию укажешь устанавливаемого приложения, такую и скачает.
А может composer проверяет и другие характеристики сервера? К примеру версию сервера базы данных? Что-то еще?
Но это рождает во мне новый вопрос.
Получается что для переноса проекта с одного сервера на другой нужно воссоздать на новом сервере совершенно идентичные условия иначе composer install может установить совершенно другие версии зависимостей. И это немного странно. Ну разрабатывал я проект например с версией php 7.2, ну установил нужные мне зависимости (установились актуальные для версии 7,2 версии) потом я переношу проект на рабочий сервер, там версия php 7.0 и мне лично это совсем не критично, я знаю что мой проект будет работать и на этой версии чудесно, но получается меня ждет сюрприз. Либо установятся более старые версии зависимостей либо если я в настройках указывал версии — я получу ошибки о том что такие версии недоступны.
Я правильно понимаю?
И вот начиная с этого момента я начинаю понимать, зачем придумали следующие костыли — такие как докер, чтобы подпирать им костыли придуманные ранее)
Смотрите вот сюда docs.modx.pro/komponentyi/minishop2
Проверив какая-же точно версия у
packagist.org/packages/symfony/website-skeleton
и увидев что 4,3,1,5
и задав ее руками мне все же удалось увидеть ошибку уже не о том, что версия не найдена, а о том, что моя версия PHP 7.0.2 не подходит.
Ну и получается, что я узнал для себя совершенно новый функционал composer
Он проверяет текущую версию программ на моей машине и скачивает ту версию, которая под них подходит. Наверное поэтому он мне все время подсовывал версию 3,4.
Если еще не поздно — проделайте его еще, попробуйте другие настройки phpMyAdmin или сделайте это через терминал.
В противном случае «глюки» будут сопровождать этот сайт постоянно и проявляться в совершенно разных местах.
посмотрел какая точно версия — 4,3,1
Пробовал указать ее — результат тот же — не найдено.
Не помогло, к сожалению (грешу наверное много.)
Попытка указать конкретную версию выдала ошибку, что такая версия не найдена.
drive.google.com/file/d/1SXcyWbdV_rPBZWUiU0amUDpnUeiDbCcS/view?usp=sharing
А вот если убрал указание версии, в очередной раз установилась старая версия 3,4
drive.google.com/file/d/1MCtl2_8P3oPAo2MDDLh2Xh186qhVijKi/view?usp=sharing
ps — уже который месяц не могу воспользоваться файлохранилищем на этом сайте, при переходе пишет Авторизоваться, при нажатии просто перезагружается страница.
Ведь никакого файла конфига нет.
Есть директория в которой лежит файл composer.phar
Обращение к нему через командную строку в windows
устанавливает версию 3,4 фреймворка
А та же самая команда, но сделанная в терминале linux — устанавливает версию 4,3.
Именно версия 4,3 актуальна в репозитории packagist.org/ и в ветке master на github
Сначала я думал, что дело в устаревшем файле composer.phar но после команды --self-update все было также. После скачивания с офф сайта последней версии файла — все было так же.
Просто хотелось для саморазвития понять что может быть тому причиной.
Потому что такая ошибка может возникать если хостинг блокирует отправку, к примеру если с вашего сайта шел спама, который могут рассылать вирусы.
Вот у Уткина расписано как это легко сделать.
ilyaut.ru/cheats/checking-of-email-in-modx/
Если и тут увидите надпись что нельзя отправить, смело идите на хостинг и смотрите уведомления от хостера.
Но я говорил немного о другом. о том что такое применение тегов img противоречит стандарту.
По крайней мере пример, указанный Николаем совершенно не содержит атрибута src.
Да я понимаю, что этот атрибут потом появиться, но тут важно понимать, что js скрипт срабатывает и проставит атрибут только в браузере, то есть для пользователя все будет ок. Но поисковый бот не выполняет js скрипты, а значит он будет видеть тег img вот таким
Без атрибута src и соответственно посчитает это ошибкой.
Но может мои знания уже устаревшие и поисковые системы не обращают внимание на ошибки в w3c.
Хотя на этой же странице есть довольна странная надпись.
И хотя все это конечно дикое нарушение стандарта.
www.w3schools.com/tags/tag_img.asp
И даже если открыть спецификацию более современного тега picture там тоже указано что атрибут src у img обязателен
www.w3schools.com/tags/tag_picture.asp
Я не могу понять двух вещей.
— так или иначе ленивая загрузка основана на передаче картинки через какой-то дата атрибут. Но разве уже отменили стандарт W3c и его требования к хтмл тегам? Разве может быть тег img без атрибута src ??? Это ведь ошибка.
— разве будут поисковые системы индексировать изображения без src? Мне кажется, что с точки зрения поискового робота сайт вообще будет лишен изображений. Ведь выводом изображения теперь занимается JS скрипт, который существует только в браузере. А поисковый робот заходит не с браузера, а значит ничего кроме ошибок в стандарте он не увидит.
Или я ошибаюсь?
Я не хотел никому демонстрировать, какой умный ибо чаще получается наоборот.
Но прочтите что я написал, там ни слова о подменах кук и безопасности.
Я просто уточнил, что способов при помощи которых на сайте можно переключить вид карточек товара больше чем 2 указанных вами и привел пример третьего.