Максим Кузнецов

Для fenom:

{set $canonical_url = $_modx->makeUrl($_modx->resource.id, '', '', 'full')}

<link rel="canonical" href="{$canonical_url}" />
<meta property="og:url" content="{$canonical_url}" />

Тегами modx:

<link rel="canonical" href="[[~[[*id]]? &scheme=`full`]]" />
<meta property="og:url" content="[[~[[*id]]? &scheme=`full`]]" />

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

[[++site_url]][[*id:isnot=`[[++site_start]]`:then=`[[~[[*id]]]]`]]

Да, ну только в моем примере решается аналогичная проблема с /index.php?id=число.
Для вашего случая вам нужно модифицировать входящий параметр (у меня id) и процесс сравнения под себя.

Ну, советую посмотреть index.php для начала и сравнить с дефолтным вариантом.

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

По поводу всего остального — стандартная процедура, нового тут ничего не посоветовать (разве что уже кто-нибудь находил источник такого трояна):
— ищите программами/при помощи хостера/руками вредоносный код
— чистите сайт
— меняете пароли
— чистите сайт

Можно расписать плагин для такой ситуации:

<?php
	if ($modx->event->name != "OnHandleRequest" || $modx->context->key == 'mgr') {
		return;
	}
		
	if ($_SERVER['REQUEST_URI'] != '/') {
		$uri = strtok(substr($_SERVER['REQUEST_URI'], 1), '?');
		
		if ($uri == 'index.php') {
			//Заменяем страницы вида /index.php?id= на чпу-шные
			$id = intval($_GET['id']);
			
			if ($modx->getCount('modResource', array('id' => $id))) {
				$modx->sendRedirect($modx->makeUrl($id), array('responseCode' => 'HTTP/1.1 301 Moved Permanently'));
			}
			else {
				//Если url не чпу, то обработка OnPageNotFound не срабатывает и необходимо дублировать определение страницы переадресации
				$error_id = intval($modx->getOption('error_page'));
				
				if ($error_id > 0 && $modx->getCount('modResource', array('id' => $error_id))) {
					$redirect_page = $modx->makeUrl($error_id);
				}
				else {
					$start_id = intval($modx->getOption('site_start'));
					$redirect_page =$modx->makeUrl($start_id);
				}
				
				$modx->sendRedirect($redirect_page, array('responseCode'  => 'HTTP/1.1 404 Not Found'));
			}

		}
	}

— написал на скорую руку, если что — поправляйте %)

Хранят. Но только в общем поле properties в формате json:

{
	"tickets": {
		"disable_jevix":false,
		"process_tags":false,
		"rating":1,
		"rating_plus":1,
		"rating_minus":0
	},
	"ms2gallery": {
		"media_source": "4"
	}
}

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

К слову, на modx.pro хранение рейтинга реализована примерно таким же способом.

— Заходите в phpmyadmin.
— Выбираете таблицу modx_site_content
— Переходите в закладку «структура»
— Внизу открывшегося окна нажимаете ОК (Добавить 1 поле в конец таблицы)
Имя: ticket_rating
Тип: int
Длина/значение: 10
По умолчанию: Как определено (0)
Null: галочка
(сохраняем)

Таким способом мы расширили дефолтную таблицу MODX'a со списком ресурсов. Далее:
— Создаем плагин (допустим, customTicketRating) со следующим содержанием:

<?php
    switch ($modx->event->name) {
    	
    	case 'OnMODXInit':
    		$modx->loadClass('modResource');
    		$modx->map['modResource']['fields']['ticket_rating'] = 0;
    		$modx->map['modResource']['fieldMeta']['ticket_rating'] = array(
    			'dbtype' => 'int',
    			'precision' => 10,
    			'attributes' => '',
    			'phptype' => 'int',
    			'null' => true,
    			'default' => 0,
    		);
    		break;
    		
    		case 'OnTicketVote':
    			if ($object->class == 'Ticket') {
    				if ($ticket = $modx->getObject('Ticket', $object->id)) {
    					$properties = $ticket->getProperties('tickets');
    					$rating = !empty($properties['rating'])
    						? $properties['rating']
    						: 0;
    					$ticket->set('ticket_rating', $rating + $object->value);
    					$ticket->save();
    				}
    			}
    			break;
    }

и включаем его на события OnTicketVote и OnMODXInit. Теперь наше новое поле воспринимается модксом и изменяется после каждого голосования за любой ресурс.

Теперь осталось только вызвать сниппет с нужным условием:

[[!pdoPage?
	&element=`getTickets`
	&where=`{"ticket_rating:>": 1}`
]]

Важно: рейтинг начнет вычисляться только с последующих голосований за тикеты.

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

Поэтому, вот этот вариант, пожалуй, самый правильный для хранения таких данных. А дальше дело только за

&where=`{"ticket_rating:>": 1}`

Допустим, у вас есть шаблон отправляемого письма в духе:

<b>От</b>: [[+email]]
<br /><br />
<b>Сообщение</b>: [[+message]]
...

Попробуйте переписать его с учетом модификаторов modx:

[[+email:notempty=`<b>От</b>: [[+email]]<br /><br />`]]
[[+message:notempty=`<b>Сообщение</b>: [[+message]]<br /><br />`]]
...

Да, конечно.

Пишите на любой удобный контакт.

В свое время (относительно давно) реализовал схожую задачу таким методом:

1. Во фронтэнде в форме авторизации обернул поле username jquery-плагином Maskedinput для визуального приведения номеров телефонов к единому формату
2. В файле core/components/office/controllers/auth.class.php редактируем функции formRegister, Login и createUser, в местах получения/проверки Username (очищаем при помощи регулярок). Там же, при необходимости, формируем email.

Важно: подобным методом перекрываются последующие обновления Office (ну или при каждом обновлении придется вновь обновлять вышеописанный файл).

Сейчас же появилась возможность зарегистрировать свой контроллер для Office, поэтому крайне рекомендую реализовать задачу с помощью данного способа.

Ну а подтверждение смс реализуется или при помощи своего плагина на событие 'OnUserSave' ($mode == 'new'), или при помощи сниппета + extended-поля/записи в сессии (в зависимости от того, на каком этапе необходима проверка).

Ambassador'ы MODX'a, например. С пометкой от кого именно.
Ну и сертификат качества «MODX.pro» заместо простого MODX.

В рамках всех заказов на разработку сайтов/модулей — вряд ли.
В рамках modx.pro — бонусный пунктик к доверию, который как минимум не будет лишним при выборе заказчика..)

Ну, у modx.com есть Ambassador. Но в целом идея классная. Весь вопрос в значимости такой бумажки.

UPD: будет довольно забавно, если в случае успеха такой концепции англоязычные разработчики будут идти на modx.pro с целью получения сертификата..)

Да, я понял.)

Ну, примерно так, в моем понимании, может выглядеть накрутка в этой схеме:
— исполнитель регистрирует аккаунт заказчика (т.к. у большинства заказчиков и так по 1-2 сообщению, подозрения это не вызовет)
— свежесозданный аккаунт создает тему с объявлением о работе («разработать модуль под частный проект» и тд, что не отследить)
— Исполнители начинают предлагать себя. Псевдозаказчик выбирает свой аккаунт исполнителя.
— через день-два ничегонеделания аккаунт заказчика закрывает заказ и пишет хвалебный отзыв.

=)

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

Ну и + это не покрывает всю область деятельности, т.к. исполнитель может быть жуть каким пунктуальным/любезным/недорогим, но при этом накодить совершеннейшую дрянь..)

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

Поэтому, предлагаю такой формат:
— значки, выдаваемые руками администрацией/модерацией за какое-либо отличительное событие (награда за серию руководств „MODX для начинающих“, награда за большой вклад в разработку Х и тд). Цель — стимулировать активность.
— значки, выдаваемые за мероприятия. Цель — исключительно для памятности.
— значки, получаемые по определенному шаблону (разработчик 1/2/5/10/… дополнений, 1/2/3/5 лет в сообществе, более 1/2/5000 довольных заказчиков, награда за полностью заполненную информацию в профиле и тд). Цель — наглядная и более визуализированная статистика для заказчиков.

+ в идеале, конечно, еще стимулировать активность заказчиков/дизайнеров — но это что-то из разряда фантастики..)

Ну и вопрос о „негативных“ значках остается открытым — стоит ли и как это будет влиять на дальнейшую активность.

Да, бесспорно, ручная модерация в плюсе. Но кто будет этим заниматься и каким образом будет проводить оценку «эффективности» исполнителя? Проводить контрольные?

Опять же, если реализовывать шкалу по «глубине» знаний — то это далеко не всегда может соответствовать действительности (существует вполне ненулевая вероятность появления новых «незадокументированных» разработчиков, обладающих тем не менее весьма внушительном багажом умений). Тогда, возможно, стоит подумать о рейтинге «доверия», но опять же кем это будет определяться? Если заказчиками — то что поможет защитить от накрутки?

Плюс, заказчик есть заказчик — ему почти наверняка будут нужны «максимальные» цифры, вне зависимости от того, какую задачу ему нужно реализовать (и что эти цифры вообще означают).
При таком раскладе и сложность заказов нужно кем-то оценивать..)

Ага, вижу.
Попутно всплыли проблемы с jgrowl (по дефолту) и с sisyphus (при попытке отправить форму).

Похоже, почему-то не отрабатываются следующие строки:

if (!jQuery().ajaxForm) {
			document.write('<script src="' + TicketsConfig.jsUrl + 'lib/jquery.form.min.js"><\/script>');
		}
		if (!jQuery().jGrowl) {
			document.write('<script src="' + TicketsConfig.jsUrl + 'lib/jquery.jgrowl.min.js"><\/script>');
		}
		if (!jQuery().sisyphus) {
			document.write('<script src="' + TicketsConfig.jsUrl + 'lib/jquery.sisyphus.min.js"><\/script>');
		}

Попробуйте вначале убрать подключенные вами (руками) скрипты для markitup'a и jquery.form и если это не поможет, то вернуть их и до кучи подключить sisyphus и jgrowl.

А, да, если не секрет — для чего вы подключаете 2 разные версии jquery?

<script src="//code.jquery.com/jquery-1.12.0.min.js"></script>
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.7/jquery.js"></script>

Детективная составляющая порадовала..)

По поводу рейтингов для заказчиков — есть же вот эта колонка (возможно, не слишком очевидная для заказчика, но все же).

А то получается что лису минусов в коммент нафигачили, а в профиле по-прежнему нет никакой информации о том, что «лучше с ним не связываться»

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

С другой стороны, идея стимулировать написание статей, документаций и других полезных для сообщества действий вполне актуальна (если не ошибаюсь, еще Wassi Wassinen предлагал разработать модуль «наград», но как-то не пошло).

Ну и в целом, по поводу «рейтинга» — на мой взгляд, продуктивнее (и нагляднее) было бы разработать в профиле рубрику «портфолио». Это и довольно наитивно для заказчика (смотреть контакты в профиле и там же уже реализованные работы) и избавит от потребности постоянного выкладывания реализованных сайтов в каждой теме с предложением о работе.