@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 должен работать. Что за ошибка была?
Best practices есть тут https://github.com/Automattic/_s/issues, вперемешку в ответах. Первый шаги, конечно же, будут медленными, это нормально. Со временем накапливается свой собственный код, который базируется на WP и его стандартах и который можно повторно использовать в новых проектах. Тогда становится легче и быстрее. Но это не появляется в один день и сразу. Но очень важно с самого начала начать делать все "канонически", тогда потом меньше надо будет ломать и переделывать, а сам рост будет быстрее. Coding standards, полезный урок. Материалов в сети полно, но одной волшебной пилюли или волшебной стартовой темы, где есть все что нужно и именно так как нужно - не существует. Есть основа, базис. Все остальное - опыт и наработки. WordPress же штука очень гибкая)
@nezzard да, parse_request и parse_query это такие же хуки, как pre_get_posts. Только они выполняются раньше. Первый парсит запрос и транслирует его в переменные, зарегистрированные и понятные WordPress. Второй собственно на основе этого готовит все для запроса. Pre_get_posts позволяет еще до выполнения этого запроса внести какие-то изменения. Дальше идет сам запрос, получение результатов. В процессе есть еще один важный хук - template_redirect. Он на основе данных из parse_query определяет какой шаблон загружать. Эти хуки - это основные моменты для работы с кастомными данными. Понять что пользователь запросил. Подготовить это в понятном виде. Сформировать запрос в бд. Получить результаты и загрузить нужный шаблон. Но в промежутках до, между и после есть еще множество экшнов и фильтров, которые позволяют делать точечные включения и выполнять таргетированные действия. Эта система хуков - одна из очень сильных сторон WP, но вкурить ее целиком - задача непростая. Тем более документации мало. Но! Есть секрет :) На самом деле документация существует. Она находится в коде файлов ядра. Можно лазить по самому коду в проекте (XDebug кстати направит куда надо), либо открыть Trac или Git-зеркало и смотреть там. Весь код WordPress очень подробно задокументирован.
@nezzard есть такое понятие как WordPress Page Lifecycle. Цикл жизни, сценарий, по которому работае система. Один из разработчиков ядра как-то составил схемку - https://tommcfarlin.com/wordpress-page-lifecycle/. Но эта схемка - весьма абстрактна и показывает только основное. По ссылкам которые я дал выше - немного полезной инфы в Кодексе, но она далеко не полная, знаю. Некоторые моменты приходится искать в сети по крупицам, в основном на StackOverflow и в постах разработчиков, так или иначе связанных с WordPress (упомянутый Tom McFarlin - хороший источник, как и Samuel Wood он же Otto, Mark Jaquith и многие другие). Найти их блоги - не проблема. Еще хорошие источники - Paul Underwood, Pippin Williamson. Ну а уже от них можно и остальных найти. Что касается понимания процесса работы WordPress - есть очень хороший способ. Запускаешь XDebug построчно, и смотришь все, что за чем и как происходит. Один такой прогон даст массу полезной информации.
@nezzard работает - и хорошо) Подебажь объекты, посмотри что приходит. Проверка REQUEST_URI - это конечно лоботомия, не скажу что правильный способ, но тоже вариант. Я бы все же шел по каноническому пути (см. коммент выше), так и порядок в системе, и логика в коде. Но, как я уже где-то ранее писал, вордпрес штука гибкая, можно делать по-разному.
@nezzard в принципе, я до сих пор не могу понять, зачем вам сдалось это делать именно на странице, если для этих целей разумнее использовать отдельный шаблон, и, собственно, определять его на уровне parse_query, загружать в template_redirect и формировать запрос с помощью pre_get_posts. Это как раз и есть правильный способ построения кастомных страниц. Ну а с помощью add_query_var и add_rewrite_rule это все окончательно оформляется в нужный нам результат. Но если уж дело так уперлось в страницу - тогда вероятно будет разумнее и проще использовать new WP_Query и смириться с тем, что перед ним будет выполнен основной запрос на пустую страницу (ведь у нее собственного контента нет), и все остальное окружение (виджеты и т.д.) вполне возможно придется допиливать вручную. Тут не уверен, надо тестировать.
@nezzard да, оказывается таки нельзя. Но варианты есть. Кодекс рекоммендует в данном случае все же использовать new WP_Query в самом шаблоне страницы, но я бы посмотрел в сторону более ранних хуков - parse_request, parse_query. Также можно присмотреться к хукам, работающим с SQL-запросом - posts_clauses, posts_join и другие. См. тут и тут.
именно об этом я писал :) но вообще использование данных функций не совсем корректное. Правильно делать так (для всех функций - _e, __, pll_e, pll__ и так далее):
_e( 'String in english', 'text-domain' );
где первый аргумент - собственно строка, на английском, а второй - уникальный домен шаблона/плагина. Именно из-за отсутствия второго аргумента при первой попытке возникали проблемы.
@Aklaim можно придумывать разные варианты, я остановился на том, если сам процесс происходит без резких движений, заметных глазу, то никто попросту не обращает внимания, и вообще думают что так надо, так задумано.
