В css пишем .title { background: url(/images/img.png) top left no-repeat; _background:none; _filter: progid: DXImageTransform.Microsoft.AlphaImageLoader(src='/images/img.png',sizingMethod='crop'); }
атрибуты с "_" для ie потом в шаблоне вставляем phg <div class="title"><img src="/images/img.png"></div>
sud falke, все фиксеры и основаны на этом фильтре. Только там добавлены проверки на браузер и т.п.
К тому же, в таком варианте работать скорее всего не будет (проверять не хочется) - т.к. IE выведет это: <img src="/images/img.png">. Ему нужно подсовывать прозрачный gif. А FF - не нужно ничего подсовывать, так что проверка нужна.
Ну и косяк с палитрой можно исправить, только отредактировав инфу самого файла.
надо в syslog'ах смотреть, когда изменяли файл и раньше - пробрались через фтп с паролем или взламывали скрипт.
Я думаю, это незабытое старое - просто усовершенствовали код инъекции:) Раньше знали только html и ставили iframe, теперь почитали самоучитель по js и вон какие простыни пишут:)
Что-то долго - я недавно запускал программу, которая брутфорсом подбирает пароли. Четырехсимвольники (я использовал максимальное количество возможных комбинаций) перебрались за секунды, пятисимвольники - минут 10 пыхтели, для 6-символьников нужно было уже 24 часа, поэтому забил я на это дело:)
Нет, там данные подгружаются AJAX'ом (исходники несложно посмотреть).
Можно и таким способом (только непонятно, зачем), но проще действительно загрузить все в блоки, и с помощью javascript управлять их свойством display - либо hidden, либо block.
ну, имхо, лучше сразу писать оптимальные решения, потому что если ситуация изменится (увеличится посещаемость, уменьшатся ресурсы и т.п.) - замучаешься вычищать из всех запросов по чуть-чуть, чтобы проект в целом работал чуть быстрее:)
PS: а вообще, в данном случае пофиг - т.к. mysql работает таким образом, что сначала выбирает все записи, соответствующие условию (т.е. полноценный запрос), а LIMIT использует только для вывода. Т.е. экономия получается на обработке массива средствами PHP.
.title
{
background: url(/images/img.png) top left no-repeat;
_background:none;
_filter: progid: DXImageTransform.Microsoft.AlphaImageLoader(src='/images/img.png',sizingMethod='crop');
}
атрибуты с "_" для ie
потом в шаблоне вставляем phg
<div class="title"><img src="/images/img.png"></div>
sud falke, все фиксеры и основаны на этом фильтре. Только там добавлены проверки на браузер и т.п.
К тому же, в таком варианте работать скорее всего не будет (проверять не хочется) - т.к. IE выведет это: <img src="/images/img.png">. Ему нужно подсовывать прозрачный gif. А FF - не нужно ничего подсовывать, так что проверка нужна.
Ну и косяк с палитрой можно исправить, только отредактировав инфу самого файла.
Если сохранять в png с прозрачностью, то в IE6 вылезет бага.
Не всегда.
Поэтому если 8-битного хватает, то с ним все ок.
PS: а для остальных желательно еще и сам файл поправить, удалить у него информацию о палитре, т.к. в том же IE цвета получаются неправильные.
надо в syslog'ах смотреть, когда изменяли файл и раньше - пробрались через фтп с паролем или взламывали скрипт.
Я думаю, это незабытое старое - просто усовершенствовали код инъекции:) Раньше знали только html и ставили iframe, теперь почитали самоучитель по js и вон какие простыни пишут:)
у jpeg'а нет прозрачности. Нужен gif или png
я подобрал пароль вида "ken7" за 9 часов
Что-то долго - я недавно запускал программу, которая брутфорсом подбирает пароли. Четырехсимвольники (я использовал максимальное количество возможных комбинаций) перебрались за секунды, пятисимвольники - минут 10 пыхтели, для 6-символьников нужно было уже 24 часа, поэтому забил я на это дело:)
Нет, там данные подгружаются AJAX'ом (исходники несложно посмотреть).
Можно и таким способом (только непонятно, зачем), но проще действительно загрузить все в блоки, и с помощью javascript управлять их свойством display - либо hidden, либо block.
ну, имхо, лучше сразу писать оптимальные решения, потому что если ситуация изменится (увеличится посещаемость, уменьшатся ресурсы и т.п.) - замучаешься вычищать из всех запросов по чуть-чуть, чтобы проект в целом работал чуть быстрее:)
PS: а вообще, в данном случае пофиг - т.к. mysql работает таким образом, что сначала выбирает все записи, соответствующие условию (т.е. полноценный запрос), а LIMIT использует только для вывода. Т.е. экономия получается на обработке массива средствами PHP.
мне нужна сортировка именно по сумме
поправил предыдущее сообщение, чтоб не возникало непоняток:)
Нельзя сортировать по функции видимо.
ORDER BY count - работает
аа:)
SELECT site, SUM(count) as sumcount FROM `$ipdb` GROUP BY site ORDER BY sumcount DESC LIMIT 20;
А чем самый верхний запрос не подходит? Он ведь и отличается от второго тем, что сортирует и обезает.