1. Главная
  2. postgres

postgres: Комментарии

Главные вкладки

10 января 2017 в 18:23

Так как вы делаете - неправильно, работать будет 1 или 2 раза - потом заглохнет.. потому что с каждым откликом вы будете навешивать обработчик еще и еще...
Сделайте так внутри вместо:

10 января 2017 в 16:24

значит шансов что связано очень мало. Весь сайт хранится в базе данных, если сайт держите у хостера - то резервная копия есть всегда, боятся нечего (но хранится может недолго - неделю например). Если на своем сервере, то вопрос к вашему админу.

10 января 2017 в 16:02

Если и связана то лучше сейчас об этом не думать. Smile только если вирус стащил данные из total commander которые хранятся в простом файлике и доступны всем ну и использовал их по своему усмотрению. Только не волнуйтесь заранее.

9 января 2017 в 14:22

Call to undefined function field_attach_load() -
вызов функции из ядра сайта которая еще по каким то причинам не загружена...

удалите все таблицы с префиксом cache
очистите каталог tmp
и выполните /update.php

9 января 2017 в 10:36

bsyomov, не сочти за занудство,
но RewriteCond %{REQUEST_URI} /
работает в полном соответствии с документацией:
http://httpd.apache.org/docs/2.4/mod/mod_rewrite.html#rewritecond
хороший перевод на русском здесь например:
http://htaccess.net.ru/doc/mod_rewrite/RewriteCond.php

8 января 2017 в 23:34

Вот я тоже первым делом убрал из глобал редирект правило "убрать конечный слэш", но ситуация не изменилась.
Кто еще правила может писать?
По поводу прав-не-прав - да проверить то просто как угодно, вот так например:
perl -e "print '/bla/bla/bla =~ /\//';"
perl -e "print '/bla/bla/bla =~ /^\/$/';"

но хорошо, схожу проверюсь Smile

8 января 2017 в 10:47

Если бы "является /" то либо ^/$ либо ="/"
а в таком виде
RewriteCond %{REQUEST_URI} /
/ - это регулярное выражение в правилах perl и это регулярное выражение будет "TRUE" если хотя бы один слэш встречается
поэтому и вопрос собственно не про документацию mod_rewrite, а про мысль автора. Про остальное - все знаю, все там в порядке, поэтому и пишу:
правило меняет на слэш любой url (.*) передает (перепрыгивает) в обработку мимо (правил Boost) кэша (на обычные правила Drupal)

23 декабря 2016 в 0:28

нет бесплатных, есть временные.
Самоподписные в принципе не канают, ибо нет корневого сертификата у них.
Ищите конечно по акциям. В глобальном масштабе это беспредел.
Цена доменного имени - от 650 до 1200, а сертификат на него - от 5000. Это я про Комодо, других не покупал.
При этом регистрация доменного имени - хоть какая то формальность соблюдается - в течение месяца нужно прислать ксерокопии документов.
По SSL - нужна только оплата.

21 декабря 2016 в 17:42

1. напоминаю, что результат отработки view - он кэшируется. И с точки зрения поле или шаблон - разницы нет никакой, вообще. Это вопрос проектирования.
2. Вопросы производительности являются таким же элементом разработки, как и алгоритмизация и прочее и прочее и почти всегда индивидуальны.
3. Я не вижу связи между существованием в Drupa php filter и тем, над какими проектами я работал и какая у них посещаемость.

MODX Revo.
Весь пользовательский php - в базе.
Более миллиона скачиваний.

19 декабря 2016 в 14:53

Вот, о чем я и говорю,
переносить логику в шаблон - это взорвать мозг следующему админу.
Но допустим -а дальше?
Маркетолог говорит - срочно за пять минут изменить сроки новинок - 20 дней и 5 часов, все остальное отрезаем.
Views - он сам по себе уже админка, причем с тестовым выводом.
А темплэйт - это уже иной уровень ответственности и компетенции.

18 декабря 2016 в 15:47

> нажать "Сохранить" и молиться, чтоб не белый экран)
Вы хоть раз пробовали положить в белый экран views? Нет?
Так вот:
1. Обращение к несуществующему методу
2. Обращение к несуществующему элементу массива
3. ОБращение к несуществующему свойству
4. Деление на ноль

Не приводят к белому экрану, единственное последствие - отсутствие вывода. То есть срабатывает Try catch блок.
5. Синтаксические ошибки - приводят к появлению диагностического сообщения во всплываыющем ajax-окне views
скриншот прилагаю (второй)

18 декабря 2016 в 1:01

Давате вернемся к началу дискуссии - вот ваш первый пост:
- Хранить исполняющий код в бд как минимум не безопасно. Где Вы начитались, что это правильно?
Вообще то еще раз, речь идет о конкретном php filter, который является частью core Drupal 7.
Из документации конечно я узнал как его использовать.
Автор views знал что писал, зачем и для кого.
https://www.drupal.org/u/merlinofchaos

18 декабря 2016 в 0:25

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

17 декабря 2016 в 23:07

1. Контроль версии чего? global $language?
да нет, никакого такого супер кода в php фильтр ставить не требуется
2. eval ну да, и что? на php fpm не заметил ничего, memcache тоже не возражал, а ему и тем более все равно
3. отладка - заходите в админку во view, и нажимаете внизу кнопку - вывести результат - выводите - смотрите
4 5 6 - вообще то изначально речь шла о конкретном php filter, кажется это было упущено. Мысль ушла далеко вбок.
поэтому пункты 4 5 6, они не об php filter