Сoncrete5 Russia

вопрос к тем у кого стоит последняя и предпоследняя версии
то есть 5.7.1 и 5.7.2
ни че не замечаете ?
у меня плывет сетка разметки блоков при входе в режим редактирования или добавить блок на версии 5.7.2, в отличии от 5.7.1,- там все норм, понятно куда ты ставишь, цвет марк подсказывает
то есть там пипец сплошной и хрен поймешь что и куда втыкать, при перемещении блоков в хедере, они копируются, а не перемещаются и получается прикол, когда один и тот же блок отсвечивает на разных местах при сохранении изменений
сначала думал чет замкнуло при установке новых блоков из магазина(волшебным образом стили ядра переопределились), но нет
поставил спец голый двиг и проверил, стили в основном шаблоне при редактировании страницы, или добавлении блоков плывут,- думаю они все больше приближаются к русскому стандарту, по типу угадай куда и что, иль кривая вывезет
чет они там загоняют с ентим вариантом 5.7 с самого начала выпуска,..
ощущение такое, что делают на оте2ись, иль выпустили под опред дату и началось)))

к вопросу о том чего не может быть вообще:

кстати об этом я оказывается уже говорил тут: viewtopic.php?p=4031#p4031

Что-то не понял. Чего не может быть? К чему эти изображения? Вы о чем?

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

Warning: require() [function.require]: open_basedir restriction in effect. File(/home/u170292723/public_html/concrete/dispatcher.php) is not within the allowed path(s): (/home/u834461023:/tmp:/var/tmp:/opt/php-5.3/pear) in /home/u170292723/public_html/index.php on line 2

Warning: require(/home/u170292723/public_html/concrete/dispatcher.php) [function.require]: failed to open stream: Operation not permitted in /home/u170292723/public_html/index.php on line 2

Warning: require() [function.require]: open_basedir restriction in effect. File(/home/u170292723/public_html/concrete/dispatcher.php) is not within the allowed path(s): (/home/u834461023:/tmp:/var/tmp:/opt/php-5.3/pear) in /home/u170292723/public_html/index.php on line 2

Warning: require(/home/u170292723/public_html/concrete/dispatcher.php) [function.require]: failed to open stream: Operation not permitted in /home/u170292723/public_html/index.php on line 2

Fatal error: require() [function.require]: Failed opening required 'concrete/dispatcher.php' (include_path='.:/opt/php-5.3/pear') in /home/u170292723/public_html/index.php on line 2

,и использует не свои куки

Count_Raven писал(а):2. Он не может иметь доступ к Cookies не своего домена. Это невозможно. Вы что-то путаете.

1. Если у вас на этом же хосте работает или работал когда-то раньше phpBB3, то всё нормально. Cookies от Concrete5 и от phpBB3 вместе хранятся. Вы же сами сказали, что они рядом стоят. Значит и все Cookies будут вместе.

2. Как я вижу, у вас Concrete5 работает в /home/u170292723 но на хосте этого пути нет в разрешенных. Обратитесь к хостеру, спросите почему в разрешенных стоит /home/u834461023 который вроде к вашему отношения не имеет. Это специальное ограничение безопасности open_basedir, которое ограничивает работу скриптов заданными путями. Пару раз была такая проблема когда-то давно.

Не увидел, чтобы Concrete5 куда-то лезла не на свои хосты.

все бы хорошо, если б так же вел себя и форум, отсвечивал у себя куки с конкрете
под виндовз на локалке С5.7.2 на данный момент ведет себя не так, как пред версии, и куки имеет только свои

Почему вы показываете на картинке Cookies запроса? Какой вообще смысл имеет этот скриншот? Показывайте Cookies для всего хоста.

))) скриншот имеет смысл с тем, что его можно сравнить с предыдущим и понять разницу

vbnm писал(а):))) скриншот имеет смысл с тем, что его можно сравнить с предыдущим и понять разницу

И что из этого? Зачем нужна эта разница?
В первом скриншоте у вас браузер отправил все имеющиеся Cookies скрипту. Все хорошо. Так и должно быть.
Concrete5 тут ни при чем вообще, мы даже тут с ним никак не встречаемся. Вы можете с тем же успехом на сервере создать пустой php-файл и потом открыть его из браузера. Cookies запроса будут такие же. Этому пустому файлу будут переданы все имеющиеся Cookies для текущего хоста. Это Cookies запроса, которые отправляет браузер, какие бы ни были у вас Cookies на хосте, они все отправляются с запросом.

Так и не понимаю о чём мы тут вообще рассуждаем. Воду в ступе месим и за "Капитана Очевидность" работаем. Либо я чего-то не понимаю в происходящем, тогда объясните.

мысля очевидна,- скрипты не срабатывают просто потому, что запросы идут не туда куда надо, вот и все
лишние куки и стороннии пути, как раз и подводят к этой мысли

а по другому пока не объяснишь полное отсутсвие ошибок в логах сервака, если на нем все врубленно и проверено

хм, давайте так попробуем, скиньте свой php.ini
помотрим

терь еще прикол
оказывается все енти ошибки 500 это всего лишь верхушка айсберга
ента ошибка в основе грит что не срабатывает JSON
который отвечает за то, чтобы всего лишь вывести предупреждение о том, что функшн, иль метод не сработал, то есь должно появится модальное окошко с предом, его нет, и мы видим 500
дык в принципе енто пофиг,..не пофиг то, что дебагеры ни на серваке, ни на КМС не выводят ошибки, когда речь идет о том что скрипт, который грит Джейсону: выведи ошибку на экран не срабатывает
Так шо:
1 нерабочий скрипт
2 не рабочий Джейсон
их надо рассматривать отдельно
уже имею минимум два таких примера, с одним разобраться удалось исключив функшн(а может метод функции, - пока не копался), когда не срабатывала кнопка редактирования в конвазе
терь есть еще одна нерабочая ссыль в ,- админка-файлы,=раширенный настройки.
когда на нее жмешь происходит все, как и ранее с кнопкой конвазе
логи чистые за исключением 500 на Джейсон
эт самое прикольное, что по дебагам не отследишь в чем же трабла
приходится залазить в файл и там уж по логике мотреть, что и откуда он должен брать, а затем идти туда и там мотреть
с путями и перезаписью конфига у них точно напутано, как это исправлять не наю
причина одна у нескольких ошибок, вычислить не могу, шарилки не хватает

vbnm писал(а):лишние куки и стороннии пути

Мы ведь так и не обнаружили никаких лишних Cookies и никаких сторонних путей тоже. В этом плане у вас всё в норме.

vbnm писал(а):оказывается все енти ошибки 500 это всего лишь верхушка айсберга
ента ошибка в основе грит что не срабатывает JSON

Нет, как раз наоборот. JSON и всё подобное - это всё уже следствие. Конечно никакого JSON не будет получено, если на сервере 500-я ошибка. Так что самое главное это разобраться с 500-й ошибкой.

Вам нужно вообще забыть про браузер и забыть про JSON и вообще про JavaScript и всё, что происходит в браузере.
500-я ошибка на стороне сервера. Причиной 500-й ошибки могут быть сто-тыщ-мильёнов любых ошибок. Причину надо смотреть НЕ в браузере, так как даже при использовании xdebug не во всех ситуациях можно увидеть конкретную причину. Факт этой ошибки обязательно должен быть зарегистрирован в логах сервера.

Практически полностью перенес сайт с Drupal 6.x на Concrete 5.7.2, установил на

Пожалуйста зарегистрируйтесь, чтобы увидеть ссылку

. Работает вполне не плохо, неделя тестов показала, что Concrete 5.7 очень хорошо ест процессор (В сравнении с Drupal 6.x показатель использования CPU вырос в 10! раз).

AxL, вообще лучше бы было создать отдельный топик. Что касается роста нагрузки, то при правильной настройке она не растет, т.ч. нужно смотреть конкретно что у вас там нагружает сервер, мониторить логи. У нас на проекте был случай, когда один запрос к БД постоянно попадал в лог медленных запросов и "подвешивал" MySQL. Удаление из запроса двух полей, которые там были в общем-то не нужны, а просто до кучи болтались, привело к повышению скорости исполнения запроса почти в 100 (!) раз. В общем нужно прикладывать голову и руки, сразу из коробки - средненькие настройки обычно.

AxL писал(а):Практически полностью перенес сайт с Drupal 6.x на Concrete 5.7.2, установил на

Пожалуйста зарегистрируйтесь, чтобы увидеть ссылку

. Работает вполне не плохо, неделя тестов показала, что Concrete 5.7 очень хорошо ест процессор (В сравнении с Drupal 6.x показатель использования CPU вырос в 10! раз).

Ну, Drupal 6 это весьма старая ветка. По сути использовал его году в 2008-м. Т. е. 6 лет назад. Тогда у меня и железо было в несколько раз слабее.
Сейчас уже Drupal 8 Beta есть.
А так - Concrete5 никогда не была легковесной системой. Она конечно не жрет так как 1C:Bitrix, однако и не была замечена в "легкости". Также как и Zend Framework и Symfony, на компонентах которых построена Concrete5, не являются легковесными фреймворками.
Также посмотрите настройки кэширования, но в любом случае Concrete5 будет прожорливее, чем Drupal 6.
Опять же это зависит от того, какие дополнения используются на сайте. К примеру, Ubercart для Drupal тоже довольно тяжеловат.
Ну и плюс ко всему, мне кажется, что 5.7 это все же не оптимальное решение на данный момент. Они еще долго будут пилить её, так как это совершенно новая система. Может к 5.8 будет лучше.

Count_Raven писал(а):Ну, Drupal 6 это весьма старая ветка. По сути использовал его году в 2008-м. Т. е. 6 лет назад. Тогда у меня и железо было в несколько раз слабее.
Сейчас уже Drupal 8 Beta есть.
А так - Concrete5 никогда не была легковесной системой. Она конечно не жрет так как 1C:Bitrix, однако и не была замечена в "легкости". Также как и Zend Framework и Symfony, на компонентах которых построена Concrete5, не являются легковесными фреймворками.
Также посмотрите настройки кэширования, но в любом случае Concrete5 будет прожорливее, чем Drupal 6.
Опять же это зависит от того, какие дополнения используются на сайте. К примеру, Ubercart для Drupal тоже довольно тяжеловат.
Ну и плюс ко всему, мне кажется, что 5.7 это все же не оптимальное решение на данный момент. Они еще долго будут пилить её, так как это совершенно новая система. Может к 5.8 будет лучше.

За Друпал 8 знаю, много его уже тестил, еще с dev версий (больше всего интересовал проект Spark), но такой функциональности сейчас не нужно. У меня есть еще один сайт, портирован с Drupal 6.x на Concrete 5.6 (concrete5russia), по потреблению ресурсов оказался не на много прожорливее D6. Вообщем ждем новых релизов))