MODX-клуб

Документация для специалистов

Новости

Закрытый. Проекты

Песочница

Организация контроллирующей команды

Каким вы видите будущее MODX-клуба?

PHP. Клонирование объектов и ООП-метод __clone()

по поводу cache.xPDOAPCCache

modAccessibleObject в MODX. Проверка доступов к объектам.

bitbucket.org переводится на русский язык

Есть ли у нас пепреводчики с английского?

Картинки и текст

плагин  'нагрузка на сервер' вставить в секцию /footer/

Как развернуть проект на Bitbucket?

Светлана, здравствуйте!
 Отписался вам на почту.

Приятная новость) Пошел переключаться на русский)

Только там еще не все переведено. Я подал заявку в команду переводчиков, если одобрят, так хоть пару самых важных слов переведу :-)

Только там еще не все переведено. Я подал заявку в

Битбакет переведен уже на 94%, практически все на русском уже.

Битбакет переведен уже на 94%, практически все на 

На полноценную разработку у меня к сожалению времени нет (есть куча работы, которую нужно делать), но вести аудит я согласен. К тому же это дополнительный опыт, да и ревью кода и проекта — важная на самом деле вещь. В компании, где я заканчиваю работу, не смогли до конца это внедрить, так как не хватало ресурсов, но польза была ощутимая.

На полноценную разработку у меня к сожалению време

Иван, привет!
 Замечательно. Можно считать, что у нас уже есть 4 человека в команде. Сегодня вечером настрою группы и политики, а так же создам единую группу проектов на modxcloud.com

Иван, привет!
 Замечательно. Можно считать, что у 

Наверное не сюда, но…
 

Мало постов, да, но для меня важно понять, для чего этот ресурс. Ресурс для профи в целях получения работы? Или это место, где люди будут и получать работу, и самообразовываться. Я, конечно понимаю, что многие тут сами достигли своего уровня и скорее всего сайт не для того, чтобы быстро получать ответы. По себе знаю, что если копать самому, то тратишь уму времени и, не всегда можно найти ответ, как делать правильно. Если проекту нужна молодая поросль, то ее возможно надо помогать растить.
 

У меня всегда есть несколько вопросов и их даже хочется задать, но с такими, как я не всегда интересно копаться :) Очень долго объяснять для кого-то очевидные вещи :) Но знания получиться хочется. Лично мне. Поэтому я слежу за этим ресурсом. 
 

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

Спасибо за внимание, высказана была собственная точка зрения.

Наверное не сюда, но… Мало постов, да, но для меня важно понять, для чего этот ресурс. Ресурс для профи в целях получения работы? Или это место, где люди будут и получать работу, и самообразовываться. Я, конечно понимаю, что многие тут сами достигли своего уровня и скорее всего сайт не для того, чтобы быстро получать ответы. По себе знаю, что если копать самому, то тратишь уму времени и, не всегда можно найти ответ, как делать правильно. Если проекту нужна молодая поросль, то ее возможно надо помогать растить. У меня всегда есть несколько вопросов и их даже хочется задать, но с такими, как я не всегда интересно копаться :) Очень долго объяснять для кого-то очевидные вещи :) Но знания получиться хочется. Лично мне. Поэтому я слежу за этим ресурсом. В порядке предложения, может создать на ресурсе детский сад, если это вписывается в концепцию проекта. Извините за много букв :) Спасибо за внимание, высказана была собственная точка зрения.

Наверное не сюда, но… Мало постов, да, но для меня

Алишер, привет!
 Ресурс создавался сразу с несколькими целями, и в том числе с целью подъема менее опытных программистов. Но ты же понимаешь, что не все так просто. Но вот как раз эта инициатива и должны помочь в этом деле. Руку набивать можно только на реальных проектах, решая реальные задачи. Но и проектами клиентов мы ни в коем случае не хотим рисковать. А так мы и тебе проект может дать, и под контролем он будет. Многое ты и сам сможешь там сделать, но если процесс пойдет не в то русло, тебя будет кому поправить вовремя, даже если ты и сам не попросишь.
 

А вопросы задавай, не стесняйся. В песочницу вообще хоть по 10 раз на день можно писать. И на многие вопросы ты хоть какие-то ответы, да получишь.

Алишер, привет!
 Ресурс создавался сразу с несколькими целями, и в том числе с целью подъема менее опытных программистов. Но ты же понимаешь, что не все так просто. Но вот как раз эта инициатива и должны помочь в этом деле. Руку набивать можно только на реальных проектах, решая реальные задачи. Но и проектами клиентов мы ни в коем случае не хотим рисковать. А так мы и тебе проект может дать, и под контролем он будет. Многое ты и сам сможешь там сделать, но если процесс пойдет не в то русло, тебя будет кому поправить вовремя, даже если ты и сам не попросишь. А вопросы задавай, не стесняйся. В песочницу вообще хоть по 10 раз на день можно писать. И на многие вопросы ты хоть какие-то ответы, да получишь.

Алишер, привет!
 Ресурс создавался сразу с несколь

Добрый день Николай :) Рад тебя видеть, у меня сейчас есть 3 сайта, которые надо делать, все они примерно одного толка. Я бы отдал в Клуб, но платить за них будут тяжело и не хочу подставляться. Поэтому сам. Я думаю, что буду писать в песочницу. Набирать команду младшеклассников :) Но хотелось бы иметь, кого-то, кто мог бы немного подсказать. А, лучше всего, сделать проект под чьим-то руководством. Глядишь и сайты такого толка будут испекаться, как пирожки. У меня всегда проблема с тем, чтобы начать. Есть «страх» начать делать не так и потом долго и нудно переделывать. 
 

PS. Не в тему, ездил в ПФР в Подольск, видел там цех по дверям, которые ты показывал :)

Добрый день Николай :) Рад тебя видеть, у меня сейчас есть 3 сайта, которые надо делать, все они примерно одного толка. Я бы отдал в Клуб, но платить за них будут тяжело и не хочу подставляться. Поэтому сам. Я думаю, что буду писать в песочницу. Набирать команду младшеклассников :) Но хотелось бы иметь, кого-то, кто мог бы немного подсказать. А, лучше всего, сделать проект под чьим-то руководством. Глядишь и сайты такого толка будут испекаться, как пирожки. У меня всегда проблема с тем, чтобы начать. Есть «страх» начать делать не так и потом долго и нудно переделывать. PS. Не в тему, ездил в ПФР в Подольск, видел там цех по дверям, которые ты показывал :)

Добрый день Николай :) Рад тебя видеть, у меня сей

видел там цех по дверям

Там же еще и радиаторы наши :-)
 По поводу сайтов: не обязательно их отдавать в Клуб с объявленными бюджетами, но ты можешь подстроиться под работу Клуба. Во-первых, перенеси их на modxcloud.com
 Во-вторых, добавь меня в свой аккаунт там администратором (мой аккаунт у меня в профиле). Я настрою там командный доступ к группам сайтов.
 В-третьих, заведи эти проекты на bitbucket.org
 И все. Мы сможем подключиться к разработке. Когда ты будешь задавать вопросы, мы сможем в любой момент залезть к тебе на сайт и посмотреть что там не так. А так же на любом этапе аудит провести. Все. Это не потребует от тебя гарантированных бюджетов, но ты сможешь и других программистов из клуба подключить к работе. А как заплатят, так и отблагодаришь каждого по его заслугам.

видел там цех по дверям Там же еще и радиаторы наши :-)
 По поводу сайтов: не обязательно их отдавать в Клуб с объявленными бюджетами, но ты можешь подстроиться под работу Клуба. Во-первых, перенеси их на modxcloud.com
 Во-вторых, добавь меня в свой аккаунт там администратором (мой аккаунт у меня в профиле). Я настрою там командный доступ к группам сайтов.
 В-третьих, заведи эти проекты на bitbucket.org
 И все. Мы сможем подключиться к разработке. Когда ты будешь задавать вопросы, мы сможем в любой момент залезть к тебе на сайт и посмотреть что там не так. А так же на любом этапе аудит провести. Все. Это не потребует от тебя гарантированных бюджетов, но ты сможешь и других программистов из клуба подключить к работе. А как заплатят, так и отблагодаришь каждого по его заслугам.

видел там цех по дверям Там же еще и радиаторы наш

Тогда несколько вопросов :)
 Существует ли таблица расчета бюджета благодарностей по заслугам?
 Предпочитаю не ходить в должниках, но возможен вариант, что не заплатят, берусь, чтобы руку набить, что делать в этом случае? :)
 Как заведу проекты на bitbucket.org, отпишусь. 
 И сейчас у меня 2 проекта на modxcloud висят, болванка и гостиница. Их надо будет удалять?
 

Тогда несколько вопросов :)
 Существует ли таблица расчета бюджета благодарностей по заслугам?
 Предпочитаю не ходить в должниках, но возможен вариант, что не заплатят, берусь, чтобы руку набить, что делать в этом случае? :)
 Как заведу проекты на bitbucket.org, отпишусь. 
 И сейчас у меня 2 проекта на modxcloud висят, болванка и гостиница. Их надо будет удалять? Спасибо заранее :)

Тогда несколько вопросов :)
 Существует ли таблица

Существует ли таблица расчета бюджета благодарностей по заслугам?

Нет, но ведь и на том же modx-cms.ru мы много ответов даем, и бесплатно. Это же часть сообщества. Все, что в рамках (вопрос — ответ на усмотрение), это не может обязывать к какой-либо плате.
 

И сейчас у меня 2 проекта на modxcloud висят, болванка и гостиница. Их надо будет удалять?

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

Существует ли таблица расчета бюджета благодарностей по заслугам? Нет, но ведь и на том же modx-cms.ru мы много ответов даем, и бесплатно. Это же часть сообщества. Все, что в рамках (вопрос — ответ на усмотрение), это не может обязывать к какой-либо плате. И сейчас у меня 2 проекта на modxcloud висят, болванка и гостиница. Их надо будет удалять? В твоему аккаунту здесь не получит много людей доступ, только те, кто не попортят тебе эти сайты, так что можно не переживать. Но если какие-то сайты принципиально надо будет скрыть, то их не надо удалять, а просто перенести в группу, к которой не будет никто иметь доступа.

Существует ли таблица расчета бюджета благодарност

Тогда я доберусь до дома и спрошу, как и, что делать, возможно интересно будет не только мне :)

Тогда я доберусь до дома и спрошу, как и, что дела

ОК.

Иван, загляни в свой профиль :-)

А вот это очень познавательная вещь. Однозначно намотать на ус)

А вот это очень познавательная вещь. Однозначно на

Поскольку плагин вешается на событие OnWebPageComplete (что насколько я знаю указывает на то, что все манипуляции со страницей уже проведены) то парсер уже закончил свою работу и объявить свой плейсхолдер мы уже не сможем. 
 Я могу предложить вам сделать так:
 

$memory = round(memory_get_usage()/1024/1024, 4).' Mb';
$mem = "Memory: {$memory}</div>";

$totalTime= ($modx->getMicroTime() - $modx->startTime);
$queryTime= $modx->queryTime;
$queryTime= sprintf("%2.4f s", $queryTime);
$queries= isset ($modx->executedQueries) ? $modx->executedQueries : 0;
$totalTime= sprintf("%2.4f s", $totalTime);
$phpTime= $totalTime - $queryTime;
$phpTime= sprintf("%2.4f s", $phpTime);

$time = "<div>TotalTime: {$totalTime}</div>";

print "<script type='text/javascript'>
	    var whither = document.getElementById('id елемента без # куда необходимо вставить результат'),
		info = '{$mem}<br />{$time}';
		whither.innerHTML = info
       </script>";
exit;

Теперь информация будет выводиться в любом контейнере, id которого вы указали в скрипте, который в свою очередь может находиться там где вам нужно.

Поскольку плагин вешается на событие OnWebPageComplete (что насколько я знаю указывает на то, что все манипуляции со страницей уже проведены) то парсер уже закончил свою работу и объявить свой плейсхолдер мы уже не сможем. 
 Я могу предложить вам сделать так: $memory = round(memory_get_usage()/1024/1024, 4).' Mb';
$mem = "Memory: {$memory}</div>";

$totalTime= ($modx->getMicroTime() - $modx->startTime);
$queryTime= $modx->queryTime;
$queryTime= sprintf("%2.4f s", $queryTime);
$queries= isset ($modx->executedQueries) ? $modx->executedQueries : 0;
$totalTime= sprintf("%2.4f s", $totalTime);
$phpTime= $totalTime - $queryTime;
$phpTime= sprintf("%2.4f s", $phpTime);

$time = "<div>TotalTime: {$totalTime}</div>";

print "<script type='text/javascript'>
	    var whither = document.getElementById('id елемента без # куда необходимо вставить результат'),
		info = '{$mem}<br />{$time}';
		whither.innerHTML = info
       </script>";
exit; Теперь информация будет выводиться в любом контейнере, id которого вы указали в скрипте, который в свою очередь может находиться там где вам нужно.

Поскольку плагин вешается на событие OnWebPageComp

да вы просто волшебник!) спасибо огромное!!!

Рад помочь)

Сейчас у меня жуткий загруз, но в целом я готов принять участие. Надо еще переварить пост. Может какие идеи возникнут :)

Сейчас у меня жуткий загруз, но в целом я готов пр

в какой именно и что я должен увидеть? :)

Михаил, да, отличное решение. Конечно можно было бы перенести на более раннее событие, но тогда будет потеря в точности подсчета памяти и времени, а так вывод получается воткнуть куда угодно.

Михаил, да, отличное решение. Конечно можно было б

modxclub.ru/profile/alroniks/ ?

Давай, я рассчитываю на тебя :-)

О, уже есть перевод статьи здесь, а обсуждение темы здесь: modx.im/blog/cloud/655.html

О, уже есть перевод статьи здесь, а обсуждение тем

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

Битбакет и modxcloud подружить можно только в одно

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

Вот прям точно не скажу, но скорее всего как и у в

у меня обычный шаред на timeweb. т.е. с настройками я пролетаю?

у меня обычный шаред на timeweb. т.е. с настройкам

Всем привет!
 Со временем у меня полный завал, но можно попробовать.

Всем привет!
 Со временем у меня полный завал, но 

Вам правильно подсказали. Придется поковырять конфиг на сервере. Если у вас ubunta или debian то apc.ini лежит в /etc/php5/conf.d/apc.ini. Тут вам нужна настройка:
 apc.ttl – сколько секунд должны отсутствовать обращения к записи кэша прежде, чем apc перезапишет ее.(значения в милисикундах)
 По умолчанию вроде стоит 7200 т.е. два часа. Если стоит 0 то кэш чиститься не будет.

Вам правильно подсказали. Придется поковырять конф

Вы можете попросить хостера поменять нужное значение.

Вы можете попросить хостера поменять нужное значен

Мне сразу в голову пришли такие мысли:
 1. Сообщество должно быть закрытым (берем пример с Хабра и аналогичных проектов), чтобы кто-то попало сюда не лез. Иначе потом трудно будет фильтровать мух от котлет.
 2. Надо самим искать новичков и приглашать их. Философ уже делал подобное — давал объявления о наборе специалистов на других ресурсах.
 3. И самое главное! Нужен хороший руководитель-менеджер, без него никуда. Нужна команда по управлению проектами и ресурсами (людьми и мат. возможностями). Надо обучать новичков, которые прошли отбор, элементарному тайм-менеджменту и элементарным знаниям управления проектами (могу взять на себя эту задачу — обучу за 3-5 дней).
 Очень надеюсь на нашего организатора Fi1osof'а и готов помогать ему!
 

Мне сразу в голову пришли такие мысли:
 1. Сообщество должно быть закрытым (берем пример с Хабра и аналогичных проектов), чтобы кто-то попало сюда не лез. Иначе потом трудно будет фильтровать мух от котлет.
 2. Надо самим искать новичков и приглашать их. Философ уже делал подобное — давал объявления о наборе специалистов на других ресурсах.
 3. И самое главное! Нужен хороший руководитель-менеджер, без него никуда. Нужна команда по управлению проектами и ресурсами (людьми и мат. возможностями). Надо обучать новичков, которые прошли отбор, элементарному тайм-менеджменту и элементарным знаниям управления проектами (могу взять на себя эту задачу — обучу за 3-5 дней).
 Очень надеюсь на нашего организатора Fi1osof'а и готов помогать ему! Вот, как-то так :)

Мне сразу в голову пришли такие мысли:
 1. Сообщес

Привет, Андрей!
 Отлично:-)

Увидел?

Да. Бэдж :) Я просто не сразу про него подумал.

Да. Вчера пару строк накидал, сделал возможность различного оформления для отдельных групп пользователей. Это не просто картинка (как и надпись «Член клуба»). Это реальные группы пользователей, со своими политиками доступов и т.п. Какие-то группы будут только визуальными индикаторами, но в любой момент для них можно будет, к примеру, создать собственную группу ресурсов, куда будут иметь доступ только члены этой группы (в общих чертах).

Да. Вчера пару строк накидал, сделал возможность р

Сергей, привет!
 Рад что мои идеи нашли понимание и среди других членов клуба. И полностью согласен со всем, что ты сказал. Собственно, так все и задумывалось.
 

По поводу фриланса: все верно. Безусловно фриланс (свободная занятость и заработок) — это основная идея клуба, без этого просто никак. Но все остальное мне кажется довольно оригинальной идеей, родившейся на основе анализа рынка. Я не собираюсь здесь делать новый free-lance.ru, но я собираюсь дать то, чего не дает free-lance.ru и еже с ним. В частности, четкий контроль качества и гарантию выполнения проекта. К примеру, тот же free-lance.ru имеет такой инструмент гарантии, как «сделка без риска». Но что он гарантирует? Он только гарантирует то, что деньги заказчика не потеряются, в случае ненадлежащего исполнения обязательств исполнителя, а исполнителю гарантируется, что если проект выполнен, он получит свои деньги. Но free-lance.ru не гарантирует заказчику выполнение проекта. Если проект не будет выполнен, заказчик не потеряет деньги, но и время он не вернет, и выполненного проекта у него не будет. В MODX-клубе же все проекты будут выполнены в обязательном порядке (если они проходят через сам MODX-клуб). Если не справится специалист, который взялся за проект, этот проект на выполнение заберут более опытные специалисты. В любом случае система будет выстраиваться так, чтобы и новички могли руку набивать, и чтобы проекты не страдали и обязательно выполнялись. Второе отличие: ориентированность на личность. Я хочу, чтобы многие друг друга по имени знали, знали какие есть способности и т.п. Какая-то статическая информация по навыкам и т.п. будет просто видна в профиле, но и сами участники клуба должны друг с другом более плотно взаимодействовать. Помогать советом, участвовать в общих проектах и т.п. Это курс на качество и новый уровень. Здесь вряд ли будет такая огромная движуха, как на free-lance.ru, но здесь точно будет качество и лучшие технологии. Этот как автомобили бентли. Их просто физически нельзя клепать столько же, сколько жигулей клепается. Но многие согласятся, что один бентли стоит тысячи жигулей.
 

И да, ваша помощь а развитии проекта однозначно понадобится, без этого просто никак. По мере необходимости я буду объявлять о задачах, но в дальнейшем работа будет строиться по принципу пирамиды, то есть не на мне все будет зациклено, но и ТОПовые участники клуба постепенно встанут во главе проекта. Каждый себе постепенно наберет команду помощников, те себе новичков наберут и т.п. Чтобы не было беспрезорников, но и была какая-то вертикаль взаимодействия, так как если здесь будет 1000 и более членов клуба, то при всем желании нельзя будет отвечать всем и каждому. Но каждый должен знать, куда ему обратиться, чтобы он точно получил ответ. И если тот, кому он задал ответ, не будет знать на него ответ, он обратится дальше. Не думаю, что здесь возникнут тупиковые вопросы.

Сергей, привет!
 Рад что мои идеи нашли понимание и среди других членов клуба. И полностью согласен со всем, что ты сказал. Собственно, так все и задумывалось. По поводу фриланса: все верно. Безусловно фриланс (свободная занятость и заработок) — это основная идея клуба, без этого просто никак. Но все остальное мне кажется довольно оригинальной идеей, родившейся на основе анализа рынка. Я не собираюсь здесь делать новый free-lance.ru, но я собираюсь дать то, чего не дает free-lance.ru и еже с ним. В частности, четкий контроль качества и гарантию выполнения проекта. К примеру, тот же free-lance.ru имеет такой инструмент гарантии, как «сделка без риска». Но что он гарантирует? Он только гарантирует то, что деньги заказчика не потеряются, в случае ненадлежащего исполнения обязательств исполнителя, а исполнителю гарантируется, что если проект выполнен, он получит свои деньги. Но free-lance.ru не гарантирует заказчику выполнение проекта. Если проект не будет выполнен, заказчик не потеряет деньги, но и время он не вернет, и выполненного проекта у него не будет. В MODX-клубе же все проекты будут выполнены в обязательном порядке (если они проходят через сам MODX-клуб). Если не справится специалист, который взялся за проект, этот проект на выполнение заберут более опытные специалисты. В любом случае система будет выстраиваться так, чтобы и новички могли руку набивать, и чтобы проекты не страдали и обязательно выполнялись. Второе отличие: ориентированность на личность. Я хочу, чтобы многие друг друга по имени знали, знали какие есть способности и т.п. Какая-то статическая информация по навыкам и т.п. будет просто видна в профиле, но и сами участники клуба должны друг с другом более плотно взаимодействовать. Помогать советом, участвовать в общих проектах и т.п. Это курс на качество и новый уровень. Здесь вряд ли будет такая огромная движуха, как на free-lance.ru, но здесь точно будет качество и лучшие технологии. Этот как автомобили бентли. Их просто физически нельзя клепать столько же, сколько жигулей клепается. Но многие согласятся, что один бентли стоит тысячи жигулей. И да, ваша помощь а развитии проекта однозначно понадобится, без этого просто никак. По мере необходимости я буду объявлять о задачах, но в дальнейшем работа будет строиться по принципу пирамиды, то есть не на мне все будет зациклено, но и ТОПовые участники клуба постепенно встанут во главе проекта. Каждый себе постепенно наберет команду помощников, те себе новичков наберут и т.п. Чтобы не было беспрезорников, но и была какая-то вертикаль взаимодействия, так как если здесь будет 1000 и более членов клуба, то при всем желании нельзя будет отвечать всем и каждому. Но каждый должен знать, куда ему обратиться, чтобы он точно получил ответ. И если тот, кому он задал ответ, не будет знать на него ответ, он обратится дальше. Не думаю, что здесь возникнут тупиковые вопросы.

Сергей, привет!
 Рад что мои идеи нашли понимание 

1. Сообщество должно быть закрытым

Так а у нас разве не так? У нас зарегистрироваться может всякий, но далеко не все пользователь видит. Для того, чтобы увидеть все, пользователь должен быть повышен в правах.
 

2. Надо самим искать новичков и приглашать их.

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

3. И самое главное! Нужен хороший руководитель-менеджер, без него никуда.

Это однозначно. Конечно надеюсь, что у нас здесь будут грамотные менеджеры проектов.

Антон, привет! 1. Сообщество должно быть закрытым Так а у нас разве не так? У нас зарегистрироваться может всякий, но далеко не все пользователь видит. Для того, чтобы увидеть все, пользователь должен быть повышен в правах. 2. Надо самим искать новичков и приглашать их. С одной стороны да. Но здесь и другой еще путь есть: сайт открыт для регистрации, и как и на хабре, пользователь может себя проявить в ответах и т.п., показать свой профессионализм, и его всегда можно подтянуть в команду. 3. И самое главное! Нужен хороший руководитель-менеджер, без него никуда. Это однозначно. Конечно надеюсь, что у нас здесь будут грамотные менеджеры проектов.

Антон, привет! 1. Сообщество должно быть закрытым 

А чтобы свой объект сделать объектом modAccessibleSimpleObject (сейчас он xPDOSimpleObject), достаточно переписать тип объекта в мап-файле и в самом классе объекта?
 

Просто сейчас для проверки доступа сам прописал метод checkAccess (чтобы не путаться с checkPolicy — так как объект другой) и в процессоре приходится в метод beforeSet добавлять $this->object->checkAccess().
 

Было бы хорошо просто в объекте расширить метод checkPolicy и процессор оставить обычный, просто расширяющий modObjectUpdateProcessor.

А чтобы свой объект сделать объектом modAccessibleSimpleObject (сейчас он xPDOSimpleObject), достаточно переписать тип объекта в мап-файле и в самом классе объекта? Просто сейчас для проверки доступа сам прописал метод checkAccess (чтобы не путаться с checkPolicy — так как объект другой) и в процессоре приходится в метод beforeSet добавлять $this->object->checkAccess(). Было бы хорошо просто в объекте расширить метод checkPolicy и процессор оставить обычный, просто расширяющий modObjectUpdateProcessor.

А чтобы свой объект сделать объектом modAccessible

А чтобы свой объект сделать объектом modAccessibleSimpleObject (сейчас он xPDOSimpleObject), достаточно переписать тип объекта в мап-файле и в самом классе объекта?

Достаточно просто класс расширить modAccessibleSimpleObject, так как мап-файлы не имеют отличия.
 

Но в целом все равно этот механизм очень сложный, то есть не стоит прям сразу на него переключаться. Сделай копию сайта и поиграйся с этим как следует.

А чтобы свой объект сделать объектом modAccessibleSimpleObject (сейчас он xPDOSimpleObject), достаточно переписать тип объекта в мап-файле и в самом классе объекта? Достаточно просто класс расширить modAccessibleSimpleObject, так как мап-файлы не имеют отличия. Но в целом все равно этот механизм очень сложный, то есть не стоит прям сразу на него переключаться. Сделай копию сайта и поиграйся с этим как следует.

Ну мой график ты знаешь — если проекта нет, то по будням 3 часа могу уделять и аудиту)))

Ну мой график ты знаешь — если проекта нет, то по 

ОК. Кстати, я сейчас тикетную систему прям сюда разрабатываю, будет вообще ураган. И для полного счастья останется только здесь же облако свое сделать :-) Чтобы политики доступов пользователя учитывались в доступах к самому сайту-проекту.

ОК. Кстати, я сейчас тикетную систему прям сюда ра

$xpdo_meta_map['Calls']= array (
  'package' => 'Rehab',
  'version' => '1.1',
  'table' => 'calls',
  'extends' => 'xPDOSimpleObject', // Вот здесь, разве, не нужно менять?
  'fields' => ...

$xpdo_meta_map['Calls']= array (
  'package' => 'R

Можно, но не обязательно, потому что мап-описание классов modAccessibleSimpleObject и xPDOObject не отличаются. Но вообще лишним не будет. Вдруг на каком-то этапе класс modAccessibleSimpleObject и в мап-файле заимеет изменения.

Можно, но не обязательно, потому что мап-описание 

Илья, пока не берись за modAccessibleSimpleObject. 
 Я вот только сейчас победил эту тему, и смог для своего объекта прописать проверку прав. Плюс там огромные заморочки с производительностью (много запросов к БД и т.п., часть инфы в сессию пользователя сохраняется). Я несколько переиначил этот механизм под свои нужды, кеширование прикрутил.
 В общем, пакет когда опубликую, скачаешь, посмотришь, но тема невероятно сложная по объему и количеству сопутствующих багов.
 Но справедливости ради стоит заметить, что оно того стоит…

Илья, пока не берись за modAccessibleSimpleObject.

Ох блин, как всё сложно!
 Уже 4 раза полностью переписывал огромный комментарий с возникшими вопросами, но теперь вот окончательная версия)
 

Во-первых, спасибо огромное за материал! Очень ценно!
 

Ну и, собссна, во-вторых.
 Какие у меня вопросы.
 

Возьмём класс modResource.
 Есть шаблоны политик доступа:
 1. ResourceTemplate с разрешениями:
 

add_children
 copy
 create
 delete
 list
 load
 move
 publish
 remove
 save
 steal_lock
 undelete
 unpublish
 view

2. И есть AdministratorTemplate с кучей разрешений, из которых нам интересны:
 

delete_document
 edit_document
 new_document
 new_document_in_root
 new_static_resource
 publish_document
 resource_duplicate
 resource_quick_create
 resource_quick_update
 resource_tree
 save_document
 tree_show_resource_ids
 undelete_document
 unpublish_document
 view_document

В этих списках есть как уникальные, так и политики-«синонимы»:
 

delete		== delete_document create		== new_document publish		== publish_document copy		== resource_duplicate save		== save_document undelete	== undelete_document unpublish	== unpublish_document view		== view_document

(при чём везде '_document', но 'resource_duplicate', очередная странность). И это при условии, что в шаблоне AdministratorTemplate так же есть простые load, list, view, create, delete, copy и т.д.
 

Я, конечно, понимаю, что политики из первого списка можно проверить только через modResource::checkPolicy(), а из второго списка через $modx->hasPermission(), но лично для меня ясности это нифига не вносит.
 1. В чём между ними в итоге разница-то?
 2. Какие политики надо назначать пользователям, для нужных разрешений? Первые? Вторые? И те и другие?
 Здесь у меня ступор :-)
 

Примеры.
 У modResource, как наследника modSimpleAccessibleObject, вшиты проверки на load, save и remove в соответствующие методы (например). Здесь проверяется локальная политика.
 Предположим, что нам надо создать документ. И по сути, логично найти проверку на create где-нибудь в modSimpleAccessibleObject::newObject().
 Так ведь нифига! Проверки на create ресурсов я вообще не нашёл! (может плохо искал?). Зато в процессоре на создание ресурса проверяется глобальная new_document через $modx->hasPermission().
 Как такое понять??
 

Дальше, предположим, что нам надо опубликовать документ. Процессор modResourcePublishProcessor наследуется от modProcessor (кстати, почему бы ему сразу не отнаследоваться от modObjectProcessor, в котором уже прописан метод для проверки для глобальных прав?).
 Как видно из метода modProcessor::run(), в нём сначала проверяются глобальные права (вызывается modResourcePublishProcessor::checkPermissions(), который возвращает $modx->hasPermission('publish_document')), а затем вызывается метод modResourcePublishProcessor::initialize(), который проверяет локальные права save и publish! Масло масляное? Мало того, ещё и при сохрании ресурса ещё раз проверится локальная политика save! Нафига? Нафига делать одно и тоже 2 раза?
 Т.е. получается, что мало дать юзеру (ну группе этих юзеров) право publish_document из шаблона политик AdministratorTemplate, надо ещё и обязательно дать ему права save и publish из шаблона ResourceTemplate??
 Вот об этом я ни разу не подозревал, сколько раз права настраивал. Видать не правильно настраивал?
 Зачем вообще разделять тогда на глобальные и локальные?
 

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

Изучая процессор resource/duplicate, я начал смутно представлять зачем нужны локальные политики — там внутри методов процессора есть проверки разрешения на добавление к родительскому ресурсу дочерних документов, т.е. как-то так:
 

if ($parentResource->checkPolicy()){
// ...
}

Да, здесь это, безусловно, оправдано. Но, исходя из вышеизложенного, картинка у меня всё-равно как-то не складывается.
 

Николай, помоги советом! А то я уже близок к тому, чтоб плюнуть на всё это и загулять))

Ох блин, как всё сложно!
 Уже 4 раза полностью переписывал огромный комментарий с возникшими вопросами, но теперь вот окончательная версия) Во-первых, спасибо огромное за материал! Очень ценно! Ну и, собссна, во-вторых.
 Какие у меня вопросы. Возьмём класс modResource.
 Есть шаблоны политик доступа:
 1. ResourceTemplate с разрешениями: add_children
 copy
 create
 delete
 list
 load
 move
 publish
 remove
 save
 steal_lock
 undelete
 unpublish
 view 2. И есть AdministratorTemplate с кучей разрешений, из которых нам интересны: delete_document
 edit_document
 new_document
 new_document_in_root
 new_static_resource
 publish_document
 resource_duplicate
 resource_quick_create
 resource_quick_update
 resource_tree
 save_document
 tree_show_resource_ids
 undelete_document
 unpublish_document
 view_document В этих списках есть как уникальные, так и политики-«синонимы»: delete		== delete_document create		== new_document publish		== publish_document copy		== resource_duplicate save		== save_document undelete	== undelete_document unpublish	== unpublish_document view		== view_document (при чём везде '_document', но 'resource_duplicate', очередная странность). И это при условии, что в шаблоне AdministratorTemplate так же есть простые load, list, view, create, delete, copy и т.д. Я, конечно, понимаю, что политики из первого списка можно проверить только через modResource::checkPolicy(), а из второго списка через $modx->hasPermission(), но лично для меня ясности это нифига не вносит.
 1. В чём между ними в итоге разница-то?
 2. Какие политики надо назначать пользователям, для нужных разрешений? Первые? Вторые? И те и другие?
 Здесь у меня ступор :-) Примеры.
 У modResource, как наследника modSimpleAccessibleObject, вшиты проверки на load, save и remove в соответствующие методы (например). Здесь проверяется локальная политика.
 Предположим, что нам надо создать документ. И по сути, логично найти проверку на create где-нибудь в modSimpleAccessibleObject::newObject().
 Так ведь нифига! Проверки на create ресурсов я вообще не нашёл! (может плохо искал?). Зато в процессоре на создание ресурса проверяется глобальная new_document через $modx->hasPermission().
 Как такое понять?? Дальше, предположим, что нам надо опубликовать документ. Процессор modResourcePublishProcessor наследуется от modProcessor (кстати, почему бы ему сразу не отнаследоваться от modObjectProcessor, в котором уже прописан метод для проверки для глобальных прав?).
 Как видно из метода modProcessor::run(), в нём сначала проверяются глобальные права (вызывается modResourcePublishProcessor::checkPermissions(), который возвращает $modx->hasPermission('publish_document')), а затем вызывается метод modResourcePublishProcessor::initialize(), который проверяет локальные права save и publish! Масло масляное? Мало того, ещё и при сохрании ресурса ещё раз проверится локальная политика save! Нафига? Нафига делать одно и тоже 2 раза?
 Т.е. получается, что мало дать юзеру (ну группе этих юзеров) право publish_document из шаблона политик AdministratorTemplate, надо ещё и обязательно дать ему права save и publish из шаблона ResourceTemplate??
 Вот об этом я ни разу не подозревал, сколько раз права настраивал. Видать не правильно настраивал?
 Зачем вообще разделять тогда на глобальные и локальные? И так во многих процессорах — проверяются глобальные разрешения, потом те же, но локальные. Почему тогда не сделать все проверки глобальными и через процессоры?
 Вот всего этого я не понимаю :-( Изучая процессор resource/duplicate, я начал смутно представлять зачем нужны локальные политики — там внутри методов процессора есть проверки разрешения на добавление к родительскому ресурсу дочерних документов, т.е. как-то так: if ($parentResource->checkPolicy()){
// ...
} Да, здесь это, безусловно, оправдано. Но, исходя из вышеизложенного, картинка у меня всё-равно как-то не складывается. Николай, помоги советом! А то я уже близок к тому, чтоб плюнуть на всё это и загулять))

Ох блин, как всё сложно!
 Уже 4 раза полностью пер

Просто у меня ситуация такая — есть свои классы и задумал я тут прикрутить к ним процессоры. Проблема не в создании процессоров, а в организации прав.
 Чего я хочу.
 Я хочу, чтобы юзеры с фронта могли просматривать/создавать/редактировать/удалять/getlist своих/чужих этих самых объектов. И чтобы все разрешения можно было гибко настроить из админки.
 Какие есть варианты?
 а) Создать свои глобальные политики доступа с именами вроде:
 'load_my_super_object', 'list_my_super_object', 'view_my_super_object', 'create_my_super_object', 'delete_my_super_object' и т.п.
 Т.е. какие процессоры нужны, такие политики и насоздавать. И в каждом из этих процессоров проверять нужную в методе mod<какой-то там>Processor::checkPermission().
 

б) Отнаследоваться от modAccessibleSimpleObject, чтобы из коробки получить стандартные проверки на delete, save, load.
 Но здесь я нифига не понял — что именно нужно писать в findPolicy() и checkPolicy()?..
 Всё остальное делать в процессорах.
 Ну и всё так же создать шаблон с вышеописанными политиками.
 

А ведь ещё как-то надо организовать, чтобы политиками можно было регулировать возможность просмотра/редактирования/удаления/etc. чужих объектов, т.е. созданными другими юзерами. Как такое провернуть?
 Надо так же создать несколько политик, вроде такого:
 'load_another_my_super_object', 'list_another_my_super_object', 'view_another_my_super_object', 'delete_another_my_super_object'
 И в каждом процессоре на каждый чих делать проверки — нужной «another» политики и является ли юзер «владельцем» этого объекта? Или есть пути попроще?
 

Решил начать с создания шаблона политик. И вот здесь я снова в тупике.
 

Дело в том, что, при создании своего шаблона политик, modx мне предлагает в принудительном порядке выбрать на основании какого шаблона политик доступа делать новый. (нда, «политики»-«шаблоны», «политики»-«шаблоны»..))
 ?
 Какой бы шаблон не был выбран в качестве основы, при создании новой политики — всё-равно в подсказках будет отображаться весь список всех возможных политик из всех возможных шаблонов.
 ?
 Зачем тогда давать выбирать основу? Что вообще это даёт? Я понимаю, если бы политики из этого шаблона-основы были бы доступны в созданном шаблоне, так ведь нет же! Создаётся пустой список.
 

И какой всё-таки надо выбирать? Есть несколько кандидатов:
 

ElementTemplate:
 add_children, copy, create, delete, list, load, remove, save, view

ObjectTemplate:
 list, load, remove, save, view

ResourceTemplate:
 add_children, copy, create, delete, list, load, move, publish, remove, save, steal_lock, undelete, unpublish, view

и AdministratorTemplate со всем его зоопарком политик.
 

Вот столько у меня вопросов…
 Извини за назойливость, но я реально здесь нифига не понимаю :-(

И ещё пара моментов. Просто у меня ситуация такая — есть свои классы и задумал я тут прикрутить к ним процессоры. Проблема не в создании процессоров, а в организации прав.
 Чего я хочу.
 Я хочу, чтобы юзеры с фронта могли просматривать/создавать/редактировать/удалять/getlist своих/чужих этих самых объектов. И чтобы все разрешения можно было гибко настроить из админки.
 Какие есть варианты?
 а) Создать свои глобальные политики доступа с именами вроде:
 'load_my_super_object', 'list_my_super_object', 'view_my_super_object', 'create_my_super_object', 'delete_my_super_object' и т.п.
 Т.е. какие процессоры нужны, такие политики и насоздавать. И в каждом из этих процессоров проверять нужную в методе mod<какой-то там>Processor::checkPermission(). б) Отнаследоваться от modAccessibleSimpleObject, чтобы из коробки получить стандартные проверки на delete, save, load.
 Но здесь я нифига не понял — что именно нужно писать в findPolicy() и checkPolicy()?..
 Всё остальное делать в процессорах.
 Ну и всё так же создать шаблон с вышеописанными политиками. А ведь ещё как-то надо организовать, чтобы политиками можно было регулировать возможность просмотра/редактирования/удаления/etc. чужих объектов, т.е. созданными другими юзерами. Как такое провернуть?
 Надо так же создать несколько политик, вроде такого:
 'load_another_my_super_object', 'list_another_my_super_object', 'view_another_my_super_object', 'delete_another_my_super_object'
 И в каждом процессоре на каждый чих делать проверки — нужной «another» политики и является ли юзер «владельцем» этого объекта? Или есть пути попроще? Решил начать с создания шаблона политик. И вот здесь я снова в тупике. Дело в том, что, при создании своего шаблона политик, modx мне предлагает в принудительном порядке выбрать на основании какого шаблона политик доступа делать новый. (нда, «политики»-«шаблоны», «политики»-«шаблоны»..))
 ?
 Какой бы шаблон не был выбран в качестве основы, при создании новой политики — всё-равно в подсказках будет отображаться весь список всех возможных политик из всех возможных шаблонов.
 ?
 Зачем тогда давать выбирать основу? Что вообще это даёт? Я понимаю, если бы политики из этого шаблона-основы были бы доступны в созданном шаблоне, так ведь нет же! Создаётся пустой список. И какой всё-таки надо выбирать? Есть несколько кандидатов: ElementTemplate:
 add_children, copy, create, delete, list, load, remove, save, view ObjectTemplate:
 list, load, remove, save, view ResourceTemplate:
 add_children, copy, create, delete, list, load, move, publish, remove, save, steal_lock, undelete, unpublish, view и AdministratorTemplate со всем его зоопарком политик. Вот столько у меня вопросов…
 Извини за назойливость, но я реально здесь нифига не понимаю :-(

И ещё пара моментов. Просто у меня ситуация такая 

В коде ошибку допустил, когда редактировал. Надо вот так:
 

if ($parentResource->checkPolicy('add_children')){
	// ...
}

В коде ошибку допустил, когда редактировал. Надо вот так: if ($parentResource->checkPolicy('add_children')){
	// ...
}

В коде ошибку допустил, когда редактировал. Надо в

Привет!
 Коммент реально зачетный! Сразу видно, что не 5 минут потратил на изучение этого вопроса. Но наверно правильней было сразу в отдельный топик оформить. Ну да ладно, пусть здесь будет.
 Итак, по сабжу: так много писать не буду, а выделю основное. Ты много раз говоришь про локальные и глобальные политики, но никак не можешь уловить разницу между ними. А между тем, суть как раз и кроется в том, что означают эти названия. Глобальные — они и в Африке глобальные. И локальные там же. Вот у тебя есть глобальное право сохранять документы. ОК, априори ты можешь взять, и сохранить документ. НО, документ может находиться в той группе документов, на которую у тебя нет прав на сохранение. То есть, в принципе ты можешь сохранять их, но конкретный документ, находящийся в конкретной группе, ты сохранить не можешь — нет прав на это. То же самое и с публикацией и т.п. Это все равно, как есть у тебя глобальное право Копать. В принципе ты можешь пойти и где-то начать копать. Но придешь в городской парк, и скорее всего тебя быстро скрутят, так как конкретно в этом парке ты копать не имеешь права. Надеюсь ответил на твой вопрос.
 

По поводу расширения не тех процессоров, лишних проверок и т.п.: безусловно, где-то не все оптимально. Но по большей степени там все оправдано.
 

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

Привет!
 Коммент реально зачетный! Сразу видно, что не 5 минут потратил на изучение этого вопроса. Но наверно правильней было сразу в отдельный топик оформить. Ну да ладно, пусть здесь будет.
 Итак, по сабжу: так много писать не буду, а выделю основное. Ты много раз говоришь про локальные и глобальные политики, но никак не можешь уловить разницу между ними. А между тем, суть как раз и кроется в том, что означают эти названия. Глобальные — они и в Африке глобальные. И локальные там же. Вот у тебя есть глобальное право сохранять документы. ОК, априори ты можешь взять, и сохранить документ. НО, документ может находиться в той группе документов, на которую у тебя нет прав на сохранение. То есть, в принципе ты можешь сохранять их, но конкретный документ, находящийся в конкретной группе, ты сохранить не можешь — нет прав на это. То же самое и с публикацией и т.п. Это все равно, как есть у тебя глобальное право Копать. В принципе ты можешь пойти и где-то начать копать. Но придешь в городской парк, и скорее всего тебя быстро скрутят, так как конкретно в этом парке ты копать не имеешь права. Надеюсь ответил на твой вопрос. По поводу расширения не тех процессоров, лишних проверок и т.п.: безусловно, где-то не все оптимально. Но по большей степени там все оправдано. И еще вот такой момент по поводу проверок прав до и после сохранения. Как я и писал выше, проверки прав на документы (ресурсы), основаны на участии документов в группах ресурсов. А так как документ, пока не сохранен, по сути не может и в группе находиться, то прав локальных как бы и не имеется. И получается, что после сохранения и возможного попадения документа в какую-либо группу ресурсов, могут измениться локальные политики конкретно на этот документ.

Привет!
 Коммент реально зачетный! Сразу видно, чт

По поводу проверки прав и наиболее удобного способа: вот это очень и очень сложный момент. Можно даже почитать статью, которая была почти сразу написана после этой статьи, чтобы оценить это примерно. Так вот, в метод checkPolicy лучше не лезть вообще. Нет, в упрощенном варианте конечно можно по какому-либо условию сделать свою проверку, и либо сразу вернуть четкий результат, либо отдать дальше на выполнение родителю через return parent::checkPolicy(), но лучше все-таки этого не делать. Если у тебя все это дело будет использоваться во фронте, то лучше все это делать именно на процессорах, так как тебе довольно не сложно будет расширить базовые процессоры и просто в своих выполнить проверку на уровне нативных методов. Это получится дешево и сердито.
 

Я хочу, чтобы юзеры с фронта могли просматривать/создавать/редактировать/удалять/getlist своих/чужих

Вот это тоже очень интересный момент. Я не раз говорил (и Джейсону тоже), что у нас с политиками есть очень большой промах. У нас в принципе нет такого понятия сейчас как владелец. В моем понимании все создаваемые объекты должны иметь флаг владельца, чтобы можно было выставить исключительные права. Второй момент (тоже очень досадный), что все рассчитано на групповые политики. То есть, права выдаются на группы пользователей, но не выдаются на конкретного пользователя. В итоге получается, что чтобы дать индивидуальные права одному пользователю, надо создать для него группу и отнести его к этой группе. В итоге 1000 пользователей — 1000 групп. Вообще не кульно получается. В своем ModZilla я расширил этот механизм и добавил механизм индивидуальных прав для пользователей, но во-первых, там все равно все не идеально, во-вторых, это вряд ли будет включено в официальное ядро в обозримом будущем, а в третьих, это вообще становится все сложно :-)

По поводу проверки прав и наиболее удобного способа: вот это очень и очень сложный момент. Можно даже почитать статью, которая была почти сразу написана после этой статьи, чтобы оценить это примерно. Так вот, в метод checkPolicy лучше не лезть вообще. Нет, в упрощенном варианте конечно можно по какому-либо условию сделать свою проверку, и либо сразу вернуть четкий результат, либо отдать дальше на выполнение родителю через return parent::checkPolicy(), но лучше все-таки этого не делать. Если у тебя все это дело будет использоваться во фронте, то лучше все это делать именно на процессорах, так как тебе довольно не сложно будет расширить базовые процессоры и просто в своих выполнить проверку на уровне нативных методов. Это получится дешево и сердито. Я хочу, чтобы юзеры с фронта могли просматривать/создавать/редактировать/удалять/getlist своих/чужих Вот это тоже очень интересный момент. Я не раз говорил (и Джейсону тоже), что у нас с политиками есть очень большой промах. У нас в принципе нет такого понятия сейчас как владелец. В моем понимании все создаваемые объекты должны иметь флаг владельца, чтобы можно было выставить исключительные права. Второй момент (тоже очень досадный), что все рассчитано на групповые политики. То есть, права выдаются на группы пользователей, но не выдаются на конкретного пользователя. В итоге получается, что чтобы дать индивидуальные права одному пользователю, надо создать для него группу и отнести его к этой группе. В итоге 1000 пользователей — 1000 групп. Вообще не кульно получается. В своем ModZilla я расширил этот механизм и добавил механизм индивидуальных прав для пользователей, но во-первых, там все равно все не идеально, во-вторых, это вряд ли будет включено в официальное ядро в обозримом будущем, а в третьих, это вообще становится все сложно :-)

По поводу проверки прав и наиболее удобного способ

По поводу шаблонов и общего списка: шаблоны созданы не для того, чтобы сделать исключительно индивидуальные списки, а чтобы разделить единый список. Ведь в конкретной политике на основе конкретного шаблона имеется ограниченное количество вариантов. Согласись, гораздо удобней видеть, что в этой политике назначено 7 из 15-ти, чем просто 7 из вообще всего набора прав. Это если ты пользователям всего одну роль создаешь, это может особо и не понятно, но когда у тебя на сайте штук 30 политик, тогда ты это все оценишь.

По поводу шаблонов и общего списка: шаблоны создан

Сразу видно, что не 5 минут потратил на изучение этого вопроса.

Даа, не один час ушёл)) И даже не три)
 

еще вот такой момент по поводу проверок прав до и после сохранения. Как я и писал выше...

А, блин! Вот теперь дошло, почему я ни где локальной проверки на create не нашёл.

Сразу видно, что не 5 минут потратил на изучение этого вопроса. Даа, не один час ушёл)) И даже не три) еще вот такой момент по поводу проверок прав до и после сохранения. Как я и писал выше... А, блин! Вот теперь дошло, почему я ни где локальной проверки на create не нашёл.

Сразу видно, что не 5 минут потратил на изучение э

Блин, а можно в скайп голосом вопрос задать? А то, если я сейчас свой вопрос печатать буду, то ещё 2 часа уйдёт(

Блин, а можно в скайп голосом вопрос задать? А то,

У меня не много, просто печатать это сложно и долго.

У меня не много, просто печатать это сложно и долг

А аналогия с копанием порвала! Спасибо, стало понятнее))

А аналогия с копанием порвала! Спасибо, стало поня

Пожалуйста :-)

В скайпе у меня такса 1000 рублей/час. Сорри, но со временем у меня напряг. Здесь, в паблике, вы платите уникальным контентом. А в привате для меня все в минус.

В скайпе у меня такса 1000 рублей/час. Сорри, но с

Я, кстати, полностью разобрался в вопросе. Прям вот полностью)
 

Сорри, но со временем у меня напряг

Нельзя ж постоянно работать!))

Я, кстати, полностью разобрался в вопросе. Прям вот полностью) Сорри, но со временем у меня напряг Нельзя ж постоянно работать!))

Я, кстати, полностью разобрался в вопросе. Прям во

Нельзя. Но когда я не работаю, я лучше просто погулять пойду. А консультации — это тоже работа, и бесплатно ее делать не улыбается.

Нельзя. Но когда я не работаю, я лучше просто погу

Не, ничего не подумай, я с этим согласен полностью!
 Сам так же поступаю)