Опять вопросы новичка

Доброго времени суток, уважаемое сообщество.
Понимаю, что возможно вас утомили вопросы от новичков, но я честно попытался найти ответы самостоятельно — на данном этапе не получилось.
Есть пара проектов, для реализации которых мне, по моим замыслам, должен неплохо подойти Альто CMS (ну или LS, но о нем тут не будем).
Собственно пока вопросов два. Хотя нет, вру — целых три)
1. Как лучше всего отключить вообще все блоги, кроме одного. Т.е., нужна «пикабу-основа» (или другого аналогичного проекта — не сочтите за рекламу) — все пишут в один блог, рейтинговое попадает на отедльную (главную страницу). Ну вот, я так понимаю, http://mylig.ru/, тут это было реализовано.
2. Как лучше всего наладить более плотную работу с тегами — возможность подписаться, либо наоборот — кинуть тег в «игнор»?
Ну и третий, пожалуй, самый главный вопрос — что лучше — залить текущую актуальную версию на сервер и начать потихоньку ковырять, допиливая под свои нужды и добавляя контент, либо все же дождаться релиза?

18 комментариев

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

По блогам: самое простое решение по отключению блогов — это отключить все ненужные типы блогов в админке (/admin/settings-blogtypes/) включая персональные и поднять ограничение по карме на создание нового блога до большого значения (over 9000). В шаблоне убрать ссылку (или сделать видимой только админам) на создание блога, оставить только на создание сообщения.

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

Ну и если вы делаете новый проект, то лучше начинать с версии 1.0 (скачать последнюю с GitHub github.com/altocms/altocms/archive/master.zip), так как если начнете делать на предыдущей версии — все ваши наработки рано или поздно придется переделывать под новую версию, ибо все новинки (плагины) улучшения и прочее, будут уже только для версии 1.0+
0
Спасибо большое за ответ.
С блогами так и поступлю, а с тегами — буду разибраться.
А по поводу версии — я имел ввиду качать 1.0 пре-релиз, или ждать релиза?
0
1. Как лучше всего отключить вообще все блоги, кроме одного. Т.е., нужна «пикабу-основа» (или другого аналогичного проекта — не сочтите за рекламу) — все пишут в один блог, рейтинговое попадает на отедльную (главную страницу). Ну вот, я так понимаю, mylig.ru/, тут это было реализовано.
Для Alto версии 1 задача решается в несколько шагов:
   1. Нужно в админке: «Админка-Настройки-Типы блогов» отключить использование персональных блогов. после этого пользователи вообще не смогут никуда писать.

   2. Администратором сайта создаем новый блог стандартным способом.
   3. Настраиваем виджеты. Из файла common/config/widgets.php в файл app/config/widgets.php переносим те, которые нужны (не нужны блоги).
   4. Из шаблона выпиливаем все упоминания блогов. Например на странице создания топика выпадающий список с блогами меняем на скрытый input… и так далее по шаблону

2. Как лучше всего наладить более плотную работу с тегами — возможность подписаться, либо наоборот — кинуть тег в «игнор»?
Средств из коробки для «расширенной» работы с тегами нет, скорее всего придется дописывать этот функционал.

Ну и третий, пожалуй, самый главный вопрос — что лучше — залить текущую актуальную версию на сервер и начать потихоньку ковырять, допиливая под свои нужды и добавляя контент, либо все же дождаться релиза?
Я думаю, лучше сразу новую версию. На нее переходить все равно прийдется — мое мнение.
0
Спасибо. Но с блогами вы, видимо, не совсем меня поняли. Мне надо, чтобы пользователи тоже могли писать — но все в один блог. Но, я уже, в принципе понял, куда копать.
По поводу тегов — странно, думаю, что для такой системы — это должно быть уже в коробке, но раз так — буду искать решение, либо заказывать отдельно)

И тоже, новую — это та, что сейчас идет под номером 1.0, или ждать совсем релиза?
0
Да, 1.0. Пока это бета версия в которой структура и функционал уже меняться не будут. Сейчас устраняются мелкие баги и сама версия вполне рабочая. Ждать релиза стоит только тем, кто уже имеет рабочие сайты и желает обновиться но новую версию.
0
Ага, спасибо еще раз.
+1
Я все правильно понял.
Если брать чистую установку, то после удаления персонального блога пользователи, да, не смогут вообще никуда писать. Но, как я указал выше — "2. Администратором сайта создаем новый блог стандартным способом", — то есть, вы создадите новый блог, и он будет единственным на сайте, даже персональных не будет — вы их удалили. Поэтому, пользователи смогут публиковаться только в этот, созданный вами, единственный блог. О чем вы и спрашивали.

Плюс, я забыл, а marques нет, что нужно запретить пользователям создавать свои блоги.

Ну а далее, как я и пояснил раньше, нужно убрать из шаблона всё, что касается упоминаний других блогов.
0
Тогда извиняюсь, теперь понял.
Все упоминания убираем, дабы не иметь потом вопросов со всякими «у вас нет прав» и т.д. Т.е. просто комментим все эти кнопки, верно?

И еще один вопрос — я пока просто не копался во всех файлах. Языковой файл один? Всмысле, без отдельных модулей, локализацию можно выполнить отредактировав один файл?
+1
Языковой файл один здесь common/templates/language/ru.php, и в каждом плагине тоже common/plugins/[ИМЯПЛАГИНА]/templates/language/russian.php.

Т.е. просто комментим все эти кнопки, верно?
По хорошему нужно в экшенах убирать всю подготовку данных для шаблона. Например, если на странице профиля /example.com/profile/[USERNAME]/ выводится список созданных пользователем блогов, то в шаблоне actions/ActionProfile/info.tpl если убрать строки
{if $aBlogsOwner}
    <li>
        <span>{$aLang.profile_blogs_self}:</span>
        <strong>
            {foreach $aBlogsOwner as $oBlog}
                <a href="{$oBlog->getUrlFull()}">
                    {$oBlog->getTitle()|escape:'html'}
                </a>{if !$oBlog@last}, {/if}
            {/foreach}
        </strong>
    </li>
{/if}

Тогда список блогов, которые создал пользователь перестанут выводится. Но, несмотря на то, что блог всего один, для каждого пользователя будет выполнятся поиск созданных им блогов — а это один лишний SQL-запрос (обращение к кэшу). Что бы этого избежать нужно в файле common/classes/actions/ActionProfile.class.php убрать сам запрос на получение данных.
И так для каждого случая вывода данных о блогах в шаблоне.
0
В очередной раз спасибо) Копать — неперекопать :)
0
А еще лучше сделать простейший плагин и переопределить
class ActionProfile extends Action {...}
в нем как
class PluginExample_ActionProfile extends PluginExample_Inherit_ActionProfile {...}
а там уже переопределяем нужный метод.

Таким образом мы избежим головной боли и длительных воспоминаний всех изменений в коде, при обновлении движка на свежую версию.
0
А что лучше, делать плагин, или изменить в исходном классе поведение системы?
Эмм… и если честно не очень понятно именование как вот это соотносится..?

class ActionProfile extends Action {...}

в нем как

class PluginExample_ActionProfile extends PluginExample_Inherit_ActionProfile {...}

Как второе связано с первым?
+1
Можно делать и в исходном классе, но вот представьте, вы один раз что-то поменяли, потом другой раз, а потом еще раз. и т.д. и тут, в один прекрасный день, вышла новая версия Alto, в которой добавили много интересных вещей и исправили кучу ошибок.

Что вам придется делать в этом случае? Да ничего сложного, по большому счету, просто сначала вспомнить в каких классах и что вы меняли (еще вспомнить нужно вспомнить зачем, ибо со временем это забывается), потом сохранить все эти файлы, потом обновить движок и на основе старых файлов восстановить эти изменения.

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

Теперь подробнее про переопределение.
Для примера возьмем файл /common/classes/actions/ActionBlog.class.php
он содержит
class ActionBlog extends Action {...}
в нем есть свойство которое содержит в массиве список URL с котрыми запрещено создавать блог
protected $aBadBlogUrl = array('new', 'good', 'bad', 'discussed', 'top', 'edit', 'add', 'admin', 'delete', 'invite', 'ajaxaddcomment', 'ajaxresponsecomment', 'ajaxgetcomment', 'ajaxupdatecomment','ajaxaddbloginvite', 'ajaxrebloginvite', 'ajaxremovebloginvite','ajaxbloginfo', 'ajaxblogjoin');
и нам захотелось поменять этот список (добавить или убрать каке-то ключевые слова)
Для этого сделаем простейший плагин.
в папке /common/classes/actions/plugins создадим папку example в этой папке создаем папку classes, а в ней папку actions и уже в этой папке создаем свой файл ActionBlog.class.php со следующим содержанием
<?php
class PluginExample_ActionBlog extends PluginExample_Inherit_ActionBlog {
    protected $aBadBlogUrl
        = array('здесь','пишем','нужные','нам','слова'
        );
}
теперь возвращаемся в корневую папку плагина example и создаем там два файла PluginExample.class.php
<?php

if (!class_exists('Plugin')) {
    die('Hacking attemp!');
}

class PluginExample extends Plugin {

    protected $aInherits=array(
	'action' => array(
            'ActionBlog'
        ),
    );

    public function Init() {
        
    }
}
и файл plugin.xml
<?xml version="1.0" encoding="UTF-8"?>
<plugin>
    <name>
        <lang name="russian">Example</lang>
    </name>
    <author>
        <lang name="russian">автор</lang>
    </author>
    <homepage>http://example.com</homepage>
    <version>1.0.0</version>
    <description>
        <lang name="russian">Описание плагина Example</lang>
    </description>
</plugin>
Вот и все. Теперь можно идти в админку и включать наш плагин. Для тех, кто хочет сказать, что это слишком сложный путь для простого изменения отвечу: для одного изменения да, но если изменения у вас на сайте все же планируются, то проще сделать такой плагин и потом дописывать его по мере необходимости (новый плагин для каждого изменения делать не нужно!).

И напоследок — загляните в /common/console/protected/plugin/ и там вы найдете демо-плагин с подробными комментариями и полной структурой папок и файлов.
0
Спасибо за развернутый ответ! мне кажется его можно вынести как отдельный топик, многим эта информация может пригодиться. Если понимаешь как устроен движок, логично ты с большей веротяностью его будешь использовать… а много таких моментов вызывают вопросы, даже на уровне общей терминологии. Было бы еще здорово если бы кто-то нарисовал схематично архитектуру и что с чем как взаимодействует…
Отредактирован:
+1
Да, я с вами согласен. Просто сейчас доделываю плагины и еще есть некоторая работа. Но в ближайшее время хочу написать об этом подробнее в отдельном топике. Это довольно большая и интересная тема.
0
нужно убрать из шаблона всё, что касается упоминаний других блогов.


У меня такой теоретический вопрос, а если мы допустим, вот так вырезаем из интерфейса какую-то функцию, правильно я понимаю что нужно в коде также ее закрыть, чтобы всякие хакеры не могли ей воспользоваться несмотря на ее отсутствие? Или там невозможно въехать без глубокого знания движка?
+1
Да, вы правы. В коде тоже нужно закрывать. И не только для защиты от злоумышленников, а что бы снять лишнюю нагрузку тоже (немножко подробнее ответил выше). Знание движка здесь, действительно, лишним не будет.
0
Спасибо!
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.