Такое может быть, если используется обертка (напр., какой-нибудь jquery-плагин) над элементами формы для придания красивостей. И надо смотреть документацию по этой обертки, у некоторых предусмотрены специальные события или методы, которые надо вызывать после задания значения селекту или радио-/чекбоксу, чтобы внешние «оберточные» элементы тоже обновились. Что-то типа того:

$('.select').val(3);
$('.select').trigger('refresh');

Если не ошибаюсь, то в php.ini прописать:
allow_url_fopen=on

Настройки PHP на сервере не позволяют выполнить операцию. Учту, что такие настройки могут быть

Раз не пускало, значит, действительно что-то не так. Буду анализировать, постараюсь понять, в чем проблема. Только уточните — вот прямо сразу при заходе на сайт пустая белая страница?

Да, это так — скин, написанный для LS, не дает 100%-ной функциональности Alto. Например, в случае с персональными блогами — в LS-скинах персональный блог жестко прописан в самом шаблоне, и исправить это можно только правкой самого шаблона. Так что плагин совместимости обеспечивает полную работоспособность LS-скинов, но не дает им полной функциональности Alto

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

altocms.ru/689.html

connection to 127.0.0.1:9312 failed (errno=111, msg=в соединении отказано)

Думаю, сообщение «в соединении отказано» намекает на проблемы с правами

Для вывода ника (логина) используется метод getLogin(), для имени, которое юзер указал в профиле — getProfileName().

Но сайты на движке создаются разные, правила и порядки тоже разные могут быть. Для того и придуман метод getDisplayName(), чтобы админ сайта мог настроить вывод, как угодно.

Там, где идет отображение имени, можно убрать уже конструкцию {if}...{else}...{/if} и оставить просто getDisplayName(), а как это выводить — это уже на уровне настроек движка будет

Недавно в 1.0.8 добавлена настройка в конфиге, которая задает формат вывода имени юзера, т.е. метода getDisplayName():

$config['module']['user']['display_name'] = '%%login%%'; // будет выводиться логин
$config['module']['user']['display_name'] = '%%profilename%%'; // будет выводиться имя из профиля

Но возможны и комбинации. Например, задано:

$config['module']['user']['display_name'] = '%%profilename%% (aka %%login%%');

Тогда для меня вывод будет такой: Вадим (aka aVadim). Это может быть полезно, чтоб, с одной стороны, отображались реальные имена, а с другой — чтоб не путались в одинаковых именах.

Да, возможность смены кодировки писем сделали (спасибо Николаю aka Klaus ), но как и на что это может влиять, и почему с разных серверов с одной и той кодировкой уходят письма с разным результатом — в это не вникали. Надо «курить мануалы». Возможно, inliquid может прояснить — он, вроде, разбирался с этим.

Я посмотрел, это небольшая ошибочка, видимо, с самого начала была в шаблоне, только проявилась сейчас: в файле шаблона /themes/default/layouts/default_light.tpl после

{if $bRefreshToHome}
    <meta HTTP-EQUIV="Refresh" CONTENT="3; URL={Config::Get('path.root.url')}/">
{/if}

пропущен хук

{hook run="html_head_tags"}

Надо добавить эту строку и все нормально будет

Вообще, любое увеличение когда, разумеется, ведет к увеличению времени его обработки. Это неизбежно.

В данном случае, если волнует, не будет ли файл каждый раз считываться с диска — нет, не будет. Если есть 100 фото и, соответственно, 100 раз встречается директива {include...} с одним именем файла, то прочитан файл будет только один раз.

Другое дело, что на странице, в итоге, будет 100 совершенно одинаковых модальных окон, которые отличаются только ссылкой на изображение — вот это, конечно, уже не есть гуд. Вы ведь не стремитесь к тому, чтобы 100 окон одновременно были на экране, не так ли? Значит, модальное окно надо только один раз включать в шаблон. И писать небольшой скрипт, который по клику на миниатюру будет сначала подставлять нужную ссылку в модальное окно на большое изображение, а потом уже открывать само модальное окно.

А настройки в конфиге не забыли изменить под новый сервер? В первую очередь это:
$config['path']['root']['dir']

Должны же быть причины, по которым плагин не может загрузиться. И, кстати, версия Альто какая?

А на самом деле плагин Ls есть? Прав хватает, чтоб скрипты этого плагина читались и могли выполняться?

Отвечу за Андрея — плагин готов, буквально на днях будет в продаже в каталоге

А ну да, я все по старинке для апача указываю :)

Все верно — два разных домена, регистрация будет работать на обоих, но независимо друг от друга, т.к. куки устанавливаются для разных доменов. Вы определитесь, какой домен будет главным и в .htaccess задайте нужный редирект. Например, так:

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

Тогда все запросы с www.abuga.ru будут автоматически перенаправляться на abuga.ru

А что конкретно не работает? Вот этот сайт доступен, например, и по altocms.com/ и по altocms.ru/ и я нормально авторизуюсь в обоих доменах