Получить id статьи - Модификации расширений для Joomla

Добрый день.

Я пишу модуль, с помощью которого пользователи на моём сайте могут оставить сообщение об ошибке. Модуль почти готов, но осталась одна загвоздка.
На админский ящик отправляется письмо с текстом сообщения (туда должен быть скопирован текст с ошибкой) пользователя и ссылкой, с какой страницы пришло сообщение. Следовательно, на этой странице и есть ошибка. Если сообщение было отправлено со страницы, где открыта конкретная статья, всё понятно: идем в эту статью и правим. А если сообщение пришло со страницы блога, вот тут то и начинается ерунда.

Вопрос состоит в следующем: как мне узнать id статьи, с которой скопирован текст?
Посоветуйте что-нибудь. Заранее спасибо.

Добавить поле, в которое пользователь сам название статьи впишет. Определить, откуда скопирован текст мне кажется нереально...

Ну если по выделению определяется то вполне реально...
$(this).parent и ищем h2 или что там..

Ага, я об этом тоже думала. Но может возникнуть такая ситуация, когда в блоге не указано название статьи, и иконки печати, к примеру, тоже нет. Тогда вообще проблема, откуда взять id...

Модуль универсальный? Если да, то пожалуй решений нет.

А вы случайно не знаете, как подобные модули на других сайтах работают? В смысле, что отправляется на почту к редактору?

Понятия не имею.. не юзал

Ага, я об этом тоже думала. Но может возникнуть такая ситуация, когда в блоге не указано название статьи, и иконки печати, к примеру, тоже нет. Тогда вообще проблема, откуда взять id...

А ссылка на полную статью полюбому же есть?

-выведет адрес страницы текущей

Код: php

//получаем текущий урл:
$url = JURI::current(); 
//преобразовываем его в неSEFный:
$uri = JURI::getInstance($url);
$app = JFactory::getApplication('site');
$router = $app->getRouter();
//выводим в массив все параметры
$vars = $router->parse($uri);
//проверяем, если это страница контента, то выводим айдишнег статьи в переменную $artid:
if (($vars[option] == com_content)&&($vars[view] == article)) {
	$artid = $vars[id];
}

И что этот код дает? Ссылку на блог, в котором была часть статьи с ошибкой? И зачем столько запросов?

Можно только поиском получить id статьи, где есть текст с опечаткой. Для этого его нужно передать побольше, желательно с помощью js. Т.е. тут как раз выделение полезно.
Это если нет ссылки на статью. И нет возможности хакать движек.

Да, проглядел, что автор про блог спрашивает. Тогда надо отсылать на почту так же список id статей на текущей странице, и потом запросом уже искать только в этих статьях. Просто запрос "SELECT id FROM #__content WHERE text LIKE '%$search%' " мне кажется нерациональным, особенно если на сайте 10 000 статей.

Чем он такой нерациональный? Нетрадиционный что ли?  Он же аяксом отсылается. Ответ - id, который сразу подставляется в форму. Достаточно попросить юзера кликнуть по опечатке.

Ага, нетрадиционной ориентации запрос. Я ж написал, вы предлагаете лопатить поисковым запросом ВСЕ статьи, а я дополнил, что достаточно указать только те, что на странице находятся. И при чём тут AJAX? От аякса sql-запрос быстрее ветра полетит чтоли?

Занятно, кстати, если выбирать по слову "новость", если оно просто в неверном падеже стоит. На выходе получим вероятно точный айдишнек конкретной статьи, где это слово есть?

От аякса sql-запрос быстрее ветра полетит чтоли?

А что ему? Глазом моргнуть не успеешь. Один то? Аки птица.

Занятно, кстати, если выбирать по слову "новость", если оно просто в неверном падеже стоит. На выходе получим вероятно точный айдишнек конкретной статьи, где это слово есть?

Вы в курсе, что с помощью js можно получить содержимое до любого тега в сторону родителя?

О чём, собственно, спор?
Вы преложили такой вот запрос:

Код: php

SELECT id FROM #__content WHERE text LIKE '%$search%' 

Я говорю, что этот запрос ничего не даст.
Потом появился уже js. Я в курсе, что с помощью js можно получить что угодно, но давайте к нашим баранам вернёмся, ок? Вот я выделил слово "новость" и нажал на "да, тут ошибка". Пусть перед этим мы аяксом получим id статьи по такому-вот запросу: SELECT id FROM #__content WHERE text LIKE '%новость%'. Ок, получили массив из 100500 чисел. Что дальше с этим делать будем?

Коли мы приплели JS, вообще не понял, зачем нам к BD обращаться? . Можно, например, к заголовку каждой новости в блоге дописывать class="id-$item->id". И потом его элементарно и отсылать.

Вы не думаете последовательно. Получать id нужно не пред, а после. И отправлять нужно не %ошибка%, а содержимое всего тега. А лучше, перед этим  посчитать в нем кол-во символов, и при необходимости, получить тег выше. Проверить его, чтобы не выйти за пределы контейнера статьи. Это же элементарно все, пол часа на всю разработку. Десяток строк кода.

Коли мы приплели JS, вообще не понял, зачем нам к BD обращаться? . Можно, например, к заголовку каждой новости в блоге дописывать class="id-$item->id". И потом его элементарно и отсылать.

Так нельзя. Это же модуль, ты всем обьяснять будешь, что нужно движок хакнуть?

удалено, продублировано.

удалено, продублировано.

удалено, продублировано.

Вы не думаете последовательно. Получать id нужно не пред, а после. И отправлять нужно не %ошибка%, а содержимое всего тега. А лучше, перед этим  посчитать в нем кол-во символов, и при необходимости, получить тег выше. Проверить его, чтобы не выйти за пределы контейнера статьи. Это же элементарно все, пол часа на всю разработку. Десяток строк кода.

Искать по БД тэги с уже отрендереной страницы? О_о. Весьма последовательно. Например, стоит у пользователя плагин "русская типографика", допустим выделяет он номер телефона, ушёл запрос вида "<nobr>23&ndash;32&ndash;99....". Вернулся ноль. Или автору писать сразу в описании: не использовать никаких плагинов, которые могут текст изменять?

Так нельзя. Это же модуль, ты всем обьяснять будешь, что нужно движок хакнуть?

С каких пор оверрайд шаблона стал хаком - хз. Хотя верно подметил, тут модуль разрабатывается, не будем лезти в шаблон. Будем дальше активно пользоваться аяксом. Обращаемся к этой же странице, но возвращаем данные в формате json. Вот уже по-ним и ищем. Тут и текст нетронутый, и айдишники статей есть.

удалено, продублировано.

Ох сколько мыслей..
Проще всего текущий урл отправлять, а контент-менеджер уже сам поймет что и откуда, ну или запомнить ветку DOM`а

Про текущий с сразу подумал, не годицо. Для блога категории он будет "плавающим". Т.е., сегодня на странице блога таких-то пять статей. Юзер отослал багрепорт об ошибке. Менеджер затупил, приболел пару дней. А там уже три раза статьи сменились, а проблемная ушла, скажем, на третью страницу блога.

В общем, конечное решение на JS будет такое:
1. по клику обращаемся аякс-запросом к текущей странице. Данные получаем в формате JSON
2. ищем позицию выделенного текста ориентируясь на тэги заголовоком например. Можно предварительно посчитать одноимённые тэги и сравнить с кол-вом объектов в массиве полученном аяксом. Это на случай, если шаблон будет переписан и там <h2>, например, тупо на <div class="contentheading"> заменили.
3. отсчитваем полученный индекс в массиве, получаем id проблемной статьи. Профит. Его и отсылаем вместе с выделенным текстом на почту.