+0.13
Рейтинг
0.46
Сила

Дмитрий

Пожалуйста :)
AddDefaultCharset UTF-8
Options -Indexes
RewriteEngine On

RewriteCond %{HTTP_HOST} .
RewriteCond %{HTTP_HOST} !^mysite\.ru [NC]
RewriteRule (.*) http://mysite.ru/$1 [R=301,L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ ./index.php

<Files "plugins.dat">
order allow,deny
deny from all
</Files>
Разместил скрипт поиска и замены в базе данных. Может быть вам пригодится.
Буду рад, если администраторы посчитают полезным разместить данный топик в блоге Tips & tricks.
В файл конфига (sphinx.conf) в описаниях индексов топиков и комментариев нужно добавить:
morphology = stem_enru, soundex, metaphone


А вообще, подробней можно почитать на Хабре: habrahabr.ru/post/147745/
Раньше этот баг так же присутствовал. Приходилось делать исключения в настройках Sphinx, исключая закрытые блоги при выборке:
SELECT ... FROM... WHERE ... target_parent_id!='ID_закрытого_блога' ...
На моем проекте присуствует. Делал так:
<li class="soc-links addthis_toolbox addthis_default_style ">
	<a class="addthis_button_facebook" title="Поделиться в Фейсбуке"></a>
	<a class="addthis_button_twitter" title="Рассказать в Твиттере"></a>
	<a class="addthis_button_vk" title="Поделиться Вконтакте"></a>
	<a class="addthis_button_livejournal" title="Рассказать в ЖЖ"></a>
</li>

Выглядит и работает так.
Присоединяюсь к поздравлениям! Успехов в проектах, ort !
Есть.
1. Айпи привязывается к домену через А-запись в DNS. Вы зайдите во вкладку IP&DNS панели управления Скалакси: там второй блок называется «Обратные зоны» и в нем должен быть прописан домен и айпишник.

2. В /etc/hostname должен быть прописан домен, с адреса которого отправляются письма. То есть, если у Вас адрес (с которого отправляются уведомления) aaaa@bbbb.ccc, то именно bbbb.ccc и должно быть прописано в файле. У вас какой домен, если не секрет?

3. Аналогично второму пункту. Надо прописывать вместо OG — доменное имя.

4. Вы сервер сами настраивали? Какая операционка, версия?

6. Я привязываю домен к Google Apps, чтобы пользоваться почтой гугла с именем ящика на своем домене. ИМХО это проще и надежней, чем устанавливать на своем сервере почтовый сервер. Не говоря уже о том, чтобы настраивать антиспам, который у гугла на мой взгляд один из лучших.
Описался:
Например, могут возникнуть домены, если почта домена привязана к Google Apps.

Например, могут возникнуть проблемы, если почта домена привязана к Google Apps.
У самого 2 проекта ЛС на Скалакси. Сталкивался с проблемой попадания письма в спам на мэйл.ру и других почтовых сервисах.

Проблему решил следующим способом.
Пусть почта отправляется с адреса info@mysite.ru (для примеров).

1. В идеале на одном айпишнике должен быть один сайт. В панеле Скалакси во вкладке IP&DNS прописываем для основного домена обратные зоны PTR (привязываем к домену айпи). В некоторых сервисах антиспам проверяет корректность обратных зон. Пример: mysite.ru в «обратных зонах» должен быть привязан к айпишнику на котором он находится.

2. Прописываем в hostname домен. Пример: набираем в SSH-терминале сервера «hostname mysite.ru» и проверяем в файлике /etc/hostname правильно ли указан домен.

3. Смотрим в файлике /etc/hosts, правильно ли указан домен. Пример: 188.127.229.85 mysite.ru.clients.scalaxy.ru mysite.ru

4. Внимательно настраиваем EXIM (если он используется в качестве MTA, например как у меня). Набираем в SSH-терминале сервера: dpkg-reconfigure exim4-config и следуем по шагам. В гугле-яндексе можно найти много описаний как пройти эти шаги.

5. Можно просмотреть все настройки EXIM в конфиге (у меня находится в /var/lib/exim4/config.autogenerated). Например, могут возникнуть домены, если почта домена привязана к Google Apps. Тогда в файлике надо прописать «MAIN_LOCAL_DOMAINS=:localhost:» вместо «MAIN_LOCAL_DOMAINS=@:localhost:localhost.localdomain». Только учтите, что файл config.autogenerated перезапишется при автоматическом конфигурировании (с помощью dpkg-reconfigure exim4-config).

6. Правильно прописать SPF в TXT-записи для домена. Например, у меня прописано так (почта привязана к гуглу):
v=spf1 ip4:188.127.XXX.XXX +a +mx a:mysite.ru a:mysite.ru.clients.scalaxy.ru include:mysite.ru include:mysite.ru.clients.scalaxy.ru include:_spf.google.com ~all


7. Есть хорошие сервисы для проверки SPF: www.openspf.org/Why?show-form=1

8. Ну и интересная статья: habrahabr.ru/post/114852/

Вроде все. Главное в логах смотреть /var/spool/exim4/ — туда падают возвращенные письма. Ну и /var/spool/exim4/msglog/ — текст сообщений об ошибках. Главный лог EXIM: /var/log/exim4/mainlog. Я по логам начинал разбираться, находя в интернете решения по кодам ошибок.
По поводу крона: в /etc/cron.d/ должен лежать файлик sphinxsearch, содержащий как минимум следующую строчку:
3,8,13,18,23,28,33,38,43,48,53,58 * * * * root . /etc/default/sphinxsearch && [ "$START" = "yes" ] && [ -x /usr/bin/indexer ] && /usr/bin/indexer --quiet --rotate --all

Если такого файла нет, то создаем и добавляем строчку.

3,8,13,18,23,28,33,38,43,48,53,58 — это минуты в течении часа, по которым происходит индексация. Тут каждые 5 минут, начиная с третьей минуты.

3,23,43 — это каждые 20 минут, начиная с третьей минуты.

Почему с третьей? ИМХО, главное, чтобы было не кратно 0,5,10..., так как другие сервисы при установке любят забивать минуты кратные пятерке. А одновременно выполнять несколько скриптов — создавать пиковые нагрузки, когда можно без этого обойтись, разнеся выполнение по времени.

Как часто индексировать зависит от того, насколько нужен актуальный поиск. На проекте, где в минуту несколько комментариев и каждые час 1-2 топика, я ставлю индексацию раз в 5 минут. И пользователи активно пользуют поиском (например, проверяя, есть ли топики на срочное событие, чтобы не дублироваться).
Под дебиан squeeze установка намного проще (на данный момент в репозитарии версия 0.9.9):
apt-get install sphinxsearch

В /etc/default/sphinxsearch устанавливаем START=yes

В /etc/sphinxsearch/ редактируем файл (или тупо копируем), меняя 3 значения (обозначены звездочками) sphinx.conf как тут. В файле все прокомментировано по русски.

В ЛивСтрите соответственно указываем в {папка сайта}/config/modules/search/config.php (конфиг сфинкса, лежит изначально):
$config['entity_prefix']  = 'MAIN';
— это сделано для того, чтобы была возможность индексировать несколько разных сайтов на ЛС, указывая разные префиксы.

Проверяем, есть ли следующая строчка в CRONе:
. /etc/default/sphinxsearch && [ "$START" = "yes" ] && [ -x /usr/bin/indexer ] && /usr/bin/indexer --quiet --rotate --all
и настраиваем ее на регулярное выполнение (у меня раз в 10 минут индексируется сайт).

Перезапускаем сфинкс:
searchd --stop
searchd

Проверяем доступность порта:
telnet localhost 3312
Если «Connected to localhost.», то все отлично. Нажимаем «Ctrl-]» и выходим из телнета — «с».
Можно запустить принудительную индексацию вручную (чтобы не ждать следующей индексации по крону):
/usr/bin/indexer --quiet --rotate --all


Работоспособность и возможные ошибки можно выявить в логах (указанных в вышеприведенном конфиге), которые лежат в каталоге /var/log/sphinxsearch/.

Вроде все. Установка должна занять не более 10 минут.
(Хотя, когда я только начинал администрировать сервак, долго разбирался даже по мануалам).
livestreetcms.com/addons/view/250/:
Топик, который был опубликован и открыт на редактирование, после первого автосохранения перемещается в черновики.

Для участников социальной сети, для которой был приобретен ваш плагин, это стало проблемой и мы не смогли использовать плагин автосохранения.
Проблема в том, что уже опубликованный пост при редактировании попадает в черновики.
Есть глюк с плагином Draft Auto Save: при редактировании поста через некоторое время он делает автосейв в черновики и сбивает дату. Причем, если не нажать на кнопку публикации поста — пост останется в черновиках.
Нет, только в редких случаях. Подозреваю, что такое случается, когда одновременно с удалением кто-то из пользователей постит комментарий в удаляемый топик.

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

Если сайт хорошо посещаемый, то при удалении топика очень вероятно получить ситуацию, когда в это время кто-то будет постить комментарий. Пару раз нарывался — после чего чистил базу данных вышеописанным способом. Чтобы минимизировать или избежать такой ошибки, теперь я сначала отправляю топик в черновики, жду 10 минут, а затем удаляю его.
Такая ошибка может возникнуть, когда удаляешь топик с комментариями. Причем при удалении топика комментарии не удаляются и нарушаются связи в базе данных (БД).

В phpmyadmin (или в другом менеджере БД сайта) сделайте запрос:
select * from prefix_comment where target_id not in (select topic_id from prefix_topic) AND target_type = "topic" 

Если появится список таких непривязанных комментариев — можете их удалить вручную (по одному) или попытаться удалить командой:
delete from prefix_comment where target_id = XXX
, где ХХХ — это ID-шник удаленного топика, от которого остались висеть комментарии (его номер Вы можете увидеть в таблице вывода предыдущего запроса — у «висящих» комментариев target_id обычно один и тот же, вот его и надо указывать в ХХХ).

Если было удалено несколько топиков, то у «висящих» комментариев будут несколько разных target_id. Следовательно нужно сделать несколько запросов delete…

Если среди «висящих» комментариев есть вложенные, то удалить сразу все такие комментарии одной командой не получится. В таком случае можно вывести список:
select * from prefix_comment where target_id = XXX
и удалять вручную по несколько штук, начиная с последнего комментария (обратная сортировка по comment_id).

Внимание: delete выполняйте на СВОЙ страх и риск. Если Вы хорошо не разбираетесь в MySQL, то нечаянно этой командой Вы можете грохнуть БД сайта.

Сам вначале разбирался около часа, потом (если возникает) делаю за пару минут.