xmoonlight: график не только не актуальный а вообще бредовый. По каким критериям скорость меряли? Скорость чего? Загрузка страниц? Обработка скриптов? На каком железе? С какими настройками? И т.д.
Все правильно. Сначала вы просто использовали дополнительный запрос, а пагинация брала данные из основного запроса. Через хук parse_query вы меняете параметры основного запроса. А вообще если это не 2й loop на странице, а единственный, то лучше полностью все аргументы вашего WP_Query выполнить через хук pre_get_posts. Тогда все необходимые данные получите собственно сразу в основном запросе.
asd111: правильный html важнее для поиска и для accessibility. А также для корректного рендеринга. Правильный css важен для корректного внешнего вида, отображения, не более. Мухи отдельно, котлеты отдельно. Советую почитать про семантику.
@nezzard: мы все еще говорим о странице? То есть, странице - как объекте post с типом "page", который хранится в бд в таблице wp_posts. Правильно? Или уже о кастомном обработчике, и страница тут - виртуальный шаблон по своей маске урл?
@nezzard: parse_request и parse_query - это два разных хука, делаеющих разные вещи. Я же ранее рекоммендовал посмотреть WordPress Page Lifecycle. Сначала выполняется init, загружается functions.php и плагины. Далее выполняется функция wp(), которая инициализирует класс WP и выполняет $wp->main(). Далее вызывается $wp->parse_request который берет часть урл (кроме домена и GET-хвоста) и парсит ее в переменные, транслирует красивый урл в обычный запрос типа index.php?ke1=value1&...&keyX=valueX. Вот тут идет хук parse_request. Далее устанавливаются все переменные is_*, уже в $wp_query->parse_query() и формируется SQL-запрос. Хук parse_query идет уже в этом классе (WP_Query).
В общем, если надо использовать проверки is_* - надо работать через parse_query или pre_get_posts, если надо раньше - тогда через parse_request.
Какой пример привести? Я не совсем понимаю что вам в конечном итоге нужно) Вы уж лучше напишите четко что вам нужно получить, при каких условиях и на какой странице. А я тогда попробую на конкретном примере показать.
@dmitrytut: именно. Это уже просто переливание из одного сосуда в другой. Главное чтобы число было одинаковые - например, 10 убрали у одного, другому 10 добавили. Вот и все.
@olmerlv: а чего вы меня спрашиваете? я вообще использую и Flickr, и Amazon S3. Яндексфотки не использовал и не собираюсь, по идеологическим причинам, но это дела не касается. Это вопрос к автору, а не ко мне. У меня на крайняк еще есть один старенький дедик с 2Тб HDD, так что вопрос места на диске меня мало беспокоит.
@FMars: хватит за $5, максимум $10. Не тратьте деньги впустую. Если вырастете и потребуется больше ресурсов - на Digital Ocean можно легко перейти на более мощный сервер. Это же облако.
Вы издеваетесь? Для 10-20к как раз базового тарифа за $5 - по самые уши хватит. У меня на 1м таком дроплете раньше крутилось 3 сайта на WP c суммарным посещением 70-80к в день. И ресурсы использовались далеко не полностью. Сейчас перешел на дроплет за $10, там 7 сайтов на WP, один из них - WordPress Multisite, в котором 4 независимых сайта сети. Суммарно идет около 200к посещений в день, при чем на 2х сайтах большая часть трафика не из статического кеша - авторизованные пользователи и полностью динамический контент. Использование процессора скачет до 40% только когда целиком репраймится кеш, в остальное время не выше 15%. Память - максимум 60%, swap не используется.
@omnamahshivaaya: так он же пишет, что не установлен требуемый плагин Google Apps Login. Но это все не важно, если вы хотите сделать полный offload на Google Drive, чтобы локально вообще ничего не хранилось. Насколько мне известно, более-менее нормально это сделано только в 1м плагине, который оффлоадит всю библиотеку на Amazon S3. Но даже он работает через родную медиа-библиотеку - заливает в нее, потом только копирует файлы в S3, после успешного зеркалирования - заменяет везде урлы и удаляет локальную копию. Вот этот плагин. А вообще, если речь зашла именно о месте, посмотрите в сторону Flickr.com. Там фикс аплоад в месяц, за 25$ в год получаете полный анлим. В целом - безлимитный фотохостинг. Сам пользуюсь уже лет 8.
@buttersmai: под рутиной я в первую очередь имею в виду работу, которая проста и понятна, как правило уже что-то подобное делалось. А это как минимум половина всех задач вне зависимости от проекта. Как бы мы ни старались следовать идеологии DRY, от проекта к проекту нам все равно приходится писать одно и то же, только в профиль.
Бывает по-разному. Иногда втянешься в задачу, и спустя пару часов очнешься, понимаешь, что кофе, который ты заварил эти пару часов назад уже давно остыл, музыку ты даже забыл включить или один и тот же трек играет все это время... А бывает так, что у тебя рутинная задача на 5-6 часов, которая в общем-то, мыслительного ресурса и не требует. В такой ситуации включить на втором экране сериал или видео с какой-нибудь конференции - вполне нормально. На скорость и качество работы никак не повлияет.
@xaver: я тоже работаю по часам, и ребята у меня так же. Только мы себе немного другую схему внедрили - берем задачу, дробим на мелкие задачи, считаем по времени и делаем почасовую оценку. Клиент оплачивает по ней. Если на каком-то этапе мы потратили больше времени - значит это наша проблема - неверно оценили задачу, переоценили свои силы, что-то не учли. Клиента это не должно касаться и на стоимость не должно влиять. При таком подходе нет нужды стоять у разработчика над душой и требовать скриншоты.
@omnamahshivaaya: да, кстати, вспомнил. Есть Nextgen Gallery. Он кажется позволяет работать с файлами по папочкам (по крайней мере виртуальным - альбомам и подальбомам), и позволяет загружать целиком архивы и распаковывать их по этим папочкам. Возможно он подойдет. Но, честно говоря, я бы не советовал. Nextgen, несмотря на свою популярность, сделать не самым лучшим образом и создает достаточно ощутимый overhead.
@omnamahshivaaya: ничего подобного, исключительно вопрос привычки. У меня 3 больших сайта на WP, 2 из них - новостные ресурсы, на каждом есть галереи. На 1м - около 27000 фото на данный момент, на другом - 8000. Никаких проблем. 3й проект - вообще SaaS-платформа на WordPress Multisite, там сейчас пока 3 сайта, на одном из них уже за 1000 фото перевалило, скоро там запускается возможность пользователям самим загружать галереи. И все прекрасно каталогизируется медиа-категориями и медиа-тегами. Тут проблема исключительно в парадигме восприятия. Есть люди привыкшие к WinAmp и сортировке файлов через файловую систему - по папочкам, подпапочкам и т.д. А есть люди, которые вообще в файловую систему не заглядывают, а управляют библиотекой из iTunes на базе тегов и других метаданных. Второй способ более гибкий. Но придется расстаться со старыми привычками :)
@omnamahshivaaya: понял. Ну, тут могут быть нюансы со скоростью работы. Все же Google Drive предназначен немного для других задач, хотя такое использование весьма привлекательно на первый взгляд. Плагин из п.3 должен работать. Что за ошибка была?
