Vladislav, стоит ли, действительно, менять? Стиль (соглашусь с Evg) есть, узнаваем и привычен для ваших пользователей. Мне там все понравилось, даже вопроса не возникло: «Что бы поменять?» ) Между прочим, газета «Нью-Йорк Таймс» уже полтора века зимой и летом одним дизайном, и не парится по этому поводу. ))
Викторыч
+77
Репутация
151
Рейтинг
.ru вряд ли отрезает почта. Дело в сайте.
В файле system/config/config.php адрес сайта правильно написан? В поле host
Ну нет, конечно! site… Поправил на site.ru, буду сейчас пробовать с инвайтом. Ну что за пипец такой, правда, что-ли, в отпуск уходить пора! В горы куда-нить...
Добавлено спустя 42 минуты
Все нормально, после правки в конфиге прошла регистрация по инвайту. Закрываю.
Добавлено спустя 1 час
.ru вряд ли отрезает почта. Дело в сайте.
В файле system/config/config.php адрес сайта правильно написан? В поле host
Ну нет, конечно! site… Поправил на site.ru, буду сейчас пробовать с инвайтом. Ну что за пипец такой, правда, что-ли, в отпуск уходить пора! В горы куда-нить...
Все нормально, после правки в конфиге прошла регистрация по инвайту. Закрываю.
Кстати, что-то не работают кнопки «Проблема решена» и «Закрыть тему»… но, может, мне опять мерещится. )
Собственно, не зная, какой почтовый транспорт использовать, сначала попробовал PHP mail(). Пользователь сменил e-mail, ему на почту письмо было доставлено (значит, транспорт работает). Но по ссылке подтверждения он не может зайти на сайт, в браузере: «Не удается получить доступ к сайту». Точно такая же проблема у человека, которому я выслал инвайт-ссылку (письмо на Украину даже с gmail'a не дошло почему-то). Вбивает инвайт-ссылку в браузер и та же история — Не удается получить доступ к сайту.
Какие действия предпринять, что делать? Это на стороне хостеров проблемы, или я опять что-то накосячил? Кто подскажет, поможет?!
Добавлено спустя 13 минут
В ссылке почему-то нет .ru: site/users/2/edit/password?new_email_confirm-так далее… Где-то у меня ошибка, да?
Разобрался… впендюрил при создании поля изображения для статьи системное имя «image». А надо было «picture». С picture все встало на свои места.
Ставлю 10 к 1, что запутались, а не разобрались))
В чем же запута? ) picture работает, картинка без размытия. Так то можно было бы и с image работать, мне только в списке картинка нужна, но, кмк, выбрал наилучший вариант. )
Расскажите, не томите, где подвох? Я еще только учусь. )
Не смог повторить. Есть ссылка, где можно это увидеть?
Нет, увы… на Опенсервере еще.
Добавлено спустя 20 минут
Тысячу извинений, недоглядел — это не TinyMCE, а поле для загрузки изображения (которое выводит картинку в список). Причем, в списке статей на главной странице картинка (средняя) отображается без размытия. В TinyMCE все нормально грузится. А вот с полем что-то не так...
Добавлено спустя 41 минуту
Разобрался… впендюрил при создании поля изображения для статьи системное имя «image». А надо было «picture». С picture все встало на свои места. Вопрос закрыт, Make, спасибо за участие! )
Релиз 2.14.3, Modern, чистая установка. Вставка картинки из TinyMCE дает вот такое странное отображение, размытие по левому-правому краям. Вопрос знатокам css — в каком файле css править, чтобы привести к нормальному виду? В theme.css потыкался, не нашел чего-то похожего на div class=«value» (Edge предлагает его править).
Видимо, издержки виртуального хостинга)В том же ISPmanager и других панелях — PHP для домена отключается довольно элементарно.
Ну хотя бы вот: docs.ispsystem.ru/ispmanager-lite/php/reyoimy-raboty-php
Или FastPanel: fastpanel.direct/wiki/ru/site-settings#php-settings
Временами чувствую, как сильно не хватает команды, хорошего технаря-программера. Я же — гуманитарий, и работаю над сайтом один, поэтому в технические дебри не лезу… боюсь! ))
Первый блин комом (хотя, любой опыт полезен, считаю)) Три дня барахталась ТП хостера с моим поддоменом. В итоге — мягкий самоотвод, по сути, в последнем ответе:
«Изучил тему безопасности на форуме. Насколько я понял, вас заинтересовал момент с возможность загрузки php скриптов в директорию upload с дальнейшей возможностью их запуска из браузера. Но в этом же посте было сказано, чтобы закрыть уязвимость, нужно отключить выполнение php скриптов для новой директории (поддомена), однако без .htaccess это получится реализовать, только разместив поддомен (добавив отдельным сайтов) на отдельном веб-сервере с другим интерпретатором.
Исходя из вышесказанного, не уверен, что реализация изменения отдачи статики окупит потраченное время и действительно обезопасит сайт. К тому же в upload уже есть .htaccess с запрещающей директивой php_flag engine 0, которая закрывает уязвимость.»
Поскольку я некомпетентен в вопросах веб-безопасности настолько, чтобы давать им советы как и что надо сделать, да и терпением не отличаюсь (увы), решил не испытывать больше ни свое, ни их. Может быть, позже, когда-нибудь… )
Интересно почему автор шаблона указан Maxisoft
Денис передал свои разработки Максу. Надеюсь я не выдал никакие секреты)).
Оно как бы подразумевается и логично. ) И думаю, что это к лучшему — было бы жаль потерять хорошие разработки, а теперь они будут поддерживаться и развиваться (надеюсь).
Я за то, чтобы люди не лазили в код)
Поздно! Я уже там! )) Даже дилетанту интересно и поучительно — а уж когда что-то мало-мальское получается, то аж крылья вырастают! )
На этом и закончим, ибо проблема решена. )
Викторыч, что же вы медлите, пробуйте. Этот путь(для хранения сессий) определён у вашего хостера в директории временных файлов.
Конфиг перезалил… поредактировал посты, сохранил, все нормально, кажется. )
Викторыч, Make ситуацию вам определил. Теперь пробуйте это.
Запустил файлик, на выходе получилось: /tmp. Вот это и вставить?
На Sprinthost поддержка круглосуточно, все настроят. Ошибки исправят, напишите.
С двух часов дня у них торчу… не можем пути к upload прописать (метод тыка даже на Спринхосте никто не отменял, оказывается), про этот с: я даже не заикался. Здесь быстрее ребята помогут. ))
Идем в sysytem/config/config.php и смотрим что у вас прописано на строке 64
Если какая-то билиберда связанная с диском с — удаляем и пишем свой путь
'session_save_path' => 'c:/openserver/userdata/temp\\61265fdfa349e'
Отжеж зараза! А на что надо заменить? *вообще голова не варит уже (
Обнаружил странную папку с: в корневой директории сайта.
При заливке файлов ничего такого… увидел спустя какое-то время, когда понадобилось перезалить один из файлов. Из Filezilla удалить не удалось. Удалил файловым менеджером на хостинге (Sprinthost), но, стоило на сайте сделать хоть какое-то действие, эта папка появилась снова. Видно, что продукт Опенсервера. Вроде, не мешает, но как бы лишняя. Сам Open Server был отключен во время заливки. Кто-нибудь сталкивался? Что это за зверь, и как его удалить безвозвратно?
Добавлено спустя 22 минуты
Не удаляется вот эта папка. Filezilla пишет: 553 Prohibited file name: temp\61265fdfa349e