1. Главная
  2. Dеmimurych

Dеmimurych: Комментарии

Главные вкладки

17 мая 2010 в 18:28

в догонку. посмотрел в код модуля.

не знаю насколько это критично НО

у вас
SELECT COUNT(*) AS count FROM {users} WHERE name = '%s'

в модуле user
SELECT COUNT(*) FROM {users} WHERE uid != %d AND LOWER(name) = LOWER('%s')

как видите модуль user не пропустит к регистрации ник demimurych если уже есть зарегистрированный Demimurych.

14 мая 2010 в 17:06

А загляните в функцию.

А потом на json.org

без слез смотреть на это невозможно.

особенно обратите внимание на работу с юникодом.

ну или еcли уж совсем в лом
http://drupal.org/node/479368

9 мая 2010 в 15:54

в linux у вас будут те же проблемы что и виндовс.

если вы уж настроить виндовс не смогли на приемлемую для вас производительность
то в линукс вам соваться не стоит.

6 мая 2010 в 13:04

ваша главная ошибка заключается в том что вы упускаете из виду такую вещь как особенности работы файловой системы и используемых в ОС систем кеширования.

самый примитивный пример повторное чтение файла в почти любой nix системе в общем случае не приведет к дисковым операциям.

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

30 апреля 2010 в 12:53

"<a href="mailto:volocuga@drupal.org">volocuga@drupal.org</a>" wrote:
нтересный топик. Вот только если у меня сайт в Украине и рассчитан на 100% на украинскую публику, то до задницы эти тесты из Далласа

именно так.
это именно то о чем я говорил, о большой относительности этих пузомерок.

30 апреля 2010 в 12:36

Все эти пузомерки весьма относительны.

1. гугл легко обманывается отдачей ему статики при приходе их бота, с максимальной скоростью. это если о рейтинге.

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

28 апреля 2010 в 12:59

"cloudgears" wrote:
еmimurych, так было в старой реализации NotCaptcha, которая под WordPress.

я смотрел пример расположенный на сайте где опубликован модуль.
точнее по ссылке что там была http://cloudgears.com/comment/reply/3#comment-form

27 апреля 2010 в 17:38

Забавная капча.

НО если я все понял верно то:

в текущей ее реализации даже в лоб легко ломаемая.

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

даже не применяя никаких оптимизаций, сейчас перебирая каждую картинку по алгоритму:
повернуть сравнить
будет уходить в среднем 4 секунды на каждую капчу используя оптерон 2Ghz

27 апреля 2010 в 16:36

"solomenikm" wrote:
Какой будет оптимальным?

два пути. первый посмотреть в ваш штмль чтобы сказать точнее

второй путь более универсальный обрабатывать
$(document).click(function(e)) {

if ($(e.target).hasClass(.views-field-title)) {выполнить что там надо}
}

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

26 апреля 2010 в 9:02

с точки зрения МОИХ привычек. Крайне неудобно.
у меня курсор мыши всегда в центре страницы, и я привык колесом мыши скролить страницу.
а тут попадаю в какой то блок, который визуально МНЕ не дает ощущение того что он перематываемый.
ну это лично мои проблемы.

А вообще
присоединяюсь к Stan.Ezersky.

ознакомьтесь с такой штукой как
http://jqueryui.com/demos/slider/#default

да и вообще
http://jqueryui.com/home

25 апреля 2010 в 19:37

"solomenikm" wrote:
ример на польском: http://bialystok2016.eu/calendar. Подробнее что конкретно?

не работает в google chrome 5.0.34

не оптимальный селектор. впрочем если дом небольшой то и так сойдет.
$(".views-field-title a").click(

24 апреля 2010 в 21:22

"graker" wrote:
upd: А, нет, посмотрел еще раз: вы правы, hook_view можно использовать. Отлично сделано.

ну на самом деле не очень и отлично.
потому что при такой реализации нужно модифицировать хук виев.

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

24 апреля 2010 в 16:34

"graker" wrote:
Вот это здорово.
Еще бы API какой-нибудь в виде хука, чтоб можно было для программно создаваемых типов нод написать обработку - что вставлять в случае эмбеда.

что мешает в хуке node_view
проверить значение поля $node->node_embedded
которая в случае работы это фильтра будет равно TRUE?

21 апреля 2010 в 23:41

"Shift-Web" wrote:
Знаете, мне как-то по барабану на кого этот лохотрон. Просто одна мысль о том, что кто-то будет на моем сайте лохотронить мне не по душе ... ну а в целом дело житейское

простите у вас на сайте разрешено аплоадить флеш и тем более его размещать в материалах?

эта глупость сродни разрешению фильтра full html всем пользователям.

21 апреля 2010 в 22:46

"graker" wrote:
Нельзя ли фееричную цитату, где написано, что это правило?

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

21 апреля 2010 в 22:29

чтобы таким образом что то ломать, атакующий должен иметь права на размещение флеша в материале куда атакуемый может зайти.

мало того. атакуемый должен еще произветис клик.

так что простите это не атака. а лохотрон на админа.

20 апреля 2010 в 3:29

"olk" wrote:
Да причем тут быстродействие если ваш запрос дает не правильный результат :)

в моем распоряжении две базы
400 000 нод и 201 000 записей в term_data
128 000 нод и 78 000 term_data

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

Мой запрос может работать неправильно только в двух случаях. Оба случая говрят о том что у вас неверная таблица term_node

19 апреля 2010 в 12:52

"<a href="mailto:screenager@drupal.org">screenager@drupal.org</a>" wrote:
большое спасибо, очень помогли =)

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

достаточно глянуть explain запроса чтобы понять какой ужас ждет сервер при попытке выолнить его.

правильно эта задача решается вот так.

19 апреля 2010 в 12:40

"<a href="mailto:Siegfrid@drupal.org">Siegfrid@drupal.org</a>" wrote:
Воспользуйтесь советом natbampo, если человек использует выражение с having, то ему явно можно доверять Smile

нельзя. запрос составлен крайне не оптимально, без понимания того как mysql оптимизирует запросы.