Владислав Балабанович

В настройках этого поля есть 2 свойства - формат хранения данных и формат возвращаемых данных. У вас формат хранения (в котором вы записываете) по ходу отличается от того, который ожидает ACF (указан в настройках поля).

Не согласен с предыдущим оратором (@geeek), в частности с утверждением

В общем если хочешь быть в тренде - бери

- Meteor совсем не в тренде.

Если дать краткий и резкий ответ на вопрос "расцветает или чахнет?" - отвечу: интерес к Meteor чахнет, не смотря на все усилия команды разработки.

Компания MDG (Meteor Development Group) подняла $31M инвестиций (https://www.crunchbase.com/organization/meteor) и хотела всё сделать круто, стать мейнстримом, а потом зарабатывать на хостинге Meteor проектов - такой план монетизации. Хостинг они, кстати, сделали. И в какой-то момент было много хайпа вокруг Meteor, казалось, что всё идёт по плану. Полтора года назад вышел Meteor 1.0 (октябрь 2014), потом была пара хороших релизов, которые убрали всю "сырость": Meteor 1.1 и 1.2.

Но в середине 2015 стало понятно, что никаким мейнстримом они не стали, мейнстрим нынче React!
Не смотря на простоту старта и скорость разработки с Meteor, были очевидны следующие минусы:

1. Собственная система пакетов со своим центральным репозиторием https://atmospherejs.com - посмотрите на счётчики скачивания пакетов, это крохи по сравнению с npm. Посмотрите на активность разработки основных пакетов - всё очень тухленько.

2. Собственная система сборки. С одной стороны всё работает из коробки, с другой стороны в неё не вклинишься (это сложно). Плюс всякие странные условности, что всё в глобальном пространстве имён и ваши js файлы загружаются в алфавитном порядке. В Meteor 1.3 частично решили проблему, ходят слухи, что в будущем будут использовать webpack.

3. Собственный шаблонизатор blaze (похож на handlebars). В начале blaze выглядел хорошо, но теперь все внезапно пишут на React и многие потирают руки в ожидании Angular 2, в итоге blaze оказался ещё один велосипедом, с которым не понятно что делать.

4. На бекенде всё ещё Node 0.10. Даже с Node 0.12 Meteor уже не работает из-за некоторых бинарных зависимостей! Обещали в будущих версиях обновиться с поддержкой Node 4.

5. Метеор сильно завязан на MongoDb. Чтобы реактивно доставлять новые/изменившиеся данные от сервера в бразуер они парсят логи Mongo. Были попытки сделать аналогичное для SQL баз, но не увенчались успехом. В итоге встречайте их новый проект Apollo, который поверх GraphQL и не привязан к конкретной реализации бекенда www.apollostack.com А что теперь будет со старым добрым DDP?

6. Ваше Meteor приложение одной командой можно упаковать в мобильное приложение Cordova - выглядит круто, но сейчас время ReactNative и вот мы читаем обсуждения на форумах, что возможно, они таки интегрируются с ReactNative, но когда?

Подводя итог: ребята из MDG подняли кучу денег и хотели сделать всё сами: свои пакеты, свою сборку, свой шаблонизатор, свой реактивный протокол (DDP) и чтобы всё работало из коробки. И они сделали это!

Только это оказалось никому не нужно, т.к. для пакетов все сидят на npm, сборка должна быть гибкой (и поэтому у нас есть gulp и webpack), самый модный шаблонизатор нынче - это React, реактивный протокол GraphQL и базы на сервере люди любят разные, а не только MongoDb. А Meteor, по сути, остался на обочине всей экосистемы и движухи вокруг JavaScript. Поняв это, MDG начали двигаться в сторону JS комьюнити и первый шаг сделан: Meteor 1.3 поддерживает нормальные модули ES2015, npm пакеты, рендринг через React и Angular. Но Meteor 1.3 - это куча костылей поверх старого велосипедного Meteor. Почитайте их планы на будущее в официальном блоге, хотя бы в этом посте: info.meteor.com/blog/announcing-meteor-1.3 - им по сути предстоит переписать всё заново! И первые ласточки такого "переписывания" - это выделение проекта Apollo.

Возможно, со второй попытки они всё сделают правильно и Meteor 2.0 действительно выстрелит. Если только у них деньги не закончатся раньше.

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

Передавать данные фильтрации методом GET, а на странице с галереей принимать эти данные. Если их нет, то сбрасываем фильтр на настройки по умолчанию.

Для профессионалов https://developer.wordpress.org/
Уроки по разработке вещь сильно размытая, у каждого свои требования и задачи, и не для начинающих их особо и нет, ни у нас ни у буржуев.
Достаточно хорошо изучить возможности ядра а зная ядро можно уже реализовать все что угодно.
Если надо что то специфическое и нет мыслей как это сделать то путь на stackoverflow там, как минимум натолкнут на алгоритм.

а так самая болшая подборка более ли менее хороших туторов лежит тут code.tutsplus.com/categories/wordpress

Тут 2 варианта:

1. Заказывают верстку, подразумевают создание шаблона/темы для CMS. По хитрости, по не знанию, по глупости - не важно. Важно не подписаться пилить это по цене только верстки.

Верстка - это когда макет превращается в набор html/css/js файлов.

Да, могут быть вариации. Может быть сразу под движок: Smarty, Twig, Jade, или все шаблоны в Handlebars, или сразу чтобы всё под Angular было. Но это всё частные случаи, требующие более высокой квалификации, или находящиеся уже где-то во front-end разработке.

2. Просят учесть особенности CMS.

Маленьких нюансов может быть много.

Вот Битрикс, например, и его Эрмитаж (тыкнул в блок - тут же его отредактировал если по простому). Где-то лишняя обертка элемента, чтобы в режиме редактирования не разваливалось. Везде - z-index меньше 1000, чтобы Эрмитаж не перекрывало.

Wordpress вообще генерирует огромное количество своих классов. Взять те же навигационные меню. Использовать их = наплевать на все эти ваши БЭМ и прочее.
И т.д.

Если я верстал и без проблем натягивал свои макеты на Wordpress - могу ли сказать что у меня есть опыт верстки под Wordpress?

Могу.
Так же как могу сказать что есть опыт верстки под Drupal (не знаю натягивали ли какие-то из моих работ на Drupal, но чё бы нет).

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

.nav
    .nav__list
        .nav__item

Когда ему движок выдаст меню в виде

.menu
    ul
        li

Но я не считаю это своей проблемой.
Когда понадобилось, оказалось нет ничего сложного 1 раз потратить время и написать свой вывод меню в Wordpress, чтобы можно было любую верстку натянуть. Почему так не может сделать тот кто натягивает? Почему в ТЗ об этом не предупредили?

Уменьшает ли "опыт верстки под CMS" время верстки?
Если не были оговорены нюансы (те же меню WP) - то нет.
Может увеличиться время натягивания верстки на движок, но это уже проблемы заказчика, который не озвучил требования заранее.

Таким образом, хотя в идеале на движок должно быть возможным натянуть любую верстку, действительно некоторые имеют CMS особенности.
Об этих особенностях следует договариваться заранее. Должно быть конкретное ТЗ на верстку.
В остальном как правило речь об "опыте верстки под %CMS%" - просто болтовня.

Только кастомайзом

В общем виде так

/**
* Замена директории для загрузки
*/
function edd_set_upload_dir( $upload ) {
    $upload['subdir'] = '/video';
    $upload['path'] = $upload['basedir'] . $upload['subdir'];
    $upload['url']  = $upload['baseurl'] . $upload['subdir'];
    return $upload;
}

//  меняем директорию
add_filter( 'upload_dir', 'edd_set_upload_dir' );
//грузим файл
$video_id = media_handle_upload( 'video-file',$post_id );
// возвращаем директорию на дефолтную
remove_filter( 'upload_dir', 'edd_set_upload_dir' );

Дальше копайтесь, он в принципе не сложно

На вскидку через api. Сделать статус заказа "на рассмотрении", менеджер сможет его менять через админку и после этого заказ можно будет оплатить.

С FB та же история, что бы получить идентификаторы событий нужно воспользоваться запрос search где type=event, но возникает проблема что конкретно искать, я в данном случае использовал название города в котором был поиск, например q=London, еще можно искать события заведений/страниц, правда сначала нужно получить идентификаторы этих страниц, например оппять же из search

У тебя есть сайт, к которому подключена гугланалитика
На него заходят пользователи
заходим на
caniuse.com
Settings->From Google Analytics: -> import

теперь можно смотреть что могут, а что не могут твои пользователи

Если у тебя нет такой статистики, то берешь свой регио и указываешь какой процент аудитории ты можешь обеспечить не всеми фичами

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

Хотел написать много, цитирую как вопрос так и ответы, но передумал.
Коротко:

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

Совсем не понимаю, оно же ведь неплохо получается и без всяких дополнительных вещей?

Задумайтесь, делаете ли вы проекты или сайты-визитки, корпоративные сайты, интернет-магазины от $100 за пять рабочих дней ?

Ознакомиться нужно сначала с:
www.phptherightway.com
https://github.com/dypsilon/frontend-dev-bookmarks

Руби, пхп, питон или ноджс в подавляющем большинстве - неважно. Но вот я отвечал на подобный вопрос про руби и постарался ответить объективно на вопрос о различиях с пхп: PHP+Symfony или Ruby+RoR?

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

Зачем гадать? Документация дает исчерпывающий ответ
docs.woothemes.com/document/tutorial-customising-c...

Использую такой код для вывода популярных товаров (те, которые отмечены звездочкой в админке)

<?php
   $args = array(
   'post_type' => 'product',
   'meta_key' => '_featured',
   'meta_value' => 'yes',
   'posts_per_page' => 2
   );
   
   $featured_query = new WP_Query( $args );
   
   if ($featured_query->have_posts()) :
   
   while ($featured_query->have_posts()) :
   
   $featured_query->the_post();
   
   $product = get_product( $featured_query->post->ID );  ?>
   
   <li class="featured-products-item">
   
   <a><?php the_post_thumbnail();?></a>
   <?php the_excerpt();;?>
   </li>
   
   
   
   <?php endwhile; ?>
   
   <?php endif; ?>
   
   <?php wp_reset_query(); // Remember to reset
   ?>

citieslist.ru

1 167 514 объектов в 234 странах, собрано с ВК

База данных городов ВКонтакте, включая коды городов "ВКонтакте" для Украины, России и Беларуси в формате SQL-дампа.
В базе содержится приблизительно: Украина — 746 городов, Россия — 2,505 городов, Беларусь — 147 города. Ссылка: sauron.org.ua/post/90

Ух, что ж вы так обстоятельно и с такой опаской к этому подошли-то? Это же всего лишь фриланс, здесь всё проще)

Расскажу свою маленькую историю. Работа у меня неплохая, в принципе устраивает, было интересено просто попробовать себя на одеске развлечения ради. Прочёл пару статей, зарегистрировался, прошёл тест на знание английского (натыкал только на below average :( ) и начал глядеть простенькие задачки «на вечер».
Никакую почасовую ставку даже не рассматривал, только fixed price. Зачем загонять себя, если опыта пока маловато?

Далее про выбор задачек. Смотрим цену, если она устраивает, ставим предложение процентов на 10 ниже, чтобы обратили внимание. И самый основной шаг — правильно составить cover letter. Минимум общих фраз о том, какой вы хороший (я вообще об этом писал одно предложение в начале), основное внимание уделяем задаче. Надо показать заказчику, что вы прочли задание и прониклись им. Задаём пару уточняющих вопросов или предложений по вариантам решения. Только не переборщите, письмо размером с этот ваш вопрос никто читать не будет. Помните, вводное письмо — это то, по чему оценит вас заказчик в первую очередь. Это то, что отличает нас от индусов, которые просто штампуют своё письмо, даже не читая текст задания. Наверняка замечали, что во многих вакансиях специально стоит такая «защита от дурака» :)

В конце, конечно же, следует указать примерные сроки выполнения. Я, как уже говорил, выбирал задачки на один-два вечера плотной работы с учётом моих скиллов. При этом писал заказчику, что, прямо сейчас я сильно загружен, но в уикенд у меня будет достаточно времени, чтобы завершить работу. Вам ведь никто не мешает предложить комфортный срок выполнения с учётом основной работы, шашлычков, семьи и проч.? Любые вакансии со словом urgent закрывал даже не дочитывая, нервотрёпка мне не нужна.

В таком режиме примерно 25-30% моих писем находили отклик. Дальше — предварительное согласование с заказчиком. Тут важно понять, какой он человек, дабы не напороться на неадеквата. Если общается в стандартном английском деловом стиле, отвечает на поставленные вопросы — всё скорее всего будет хорошо. Однажды мне попался человек, которые дважды не ответил на конкретный вопрос, продолжать общение с таким не было никакого смысла. Либо некомпетентен, либо невнимателен, а зачем нужен человек, из которого потом придётся тянуть клещами? И да, лучше конечно выбирать европейцев/американцев, общаться с малограмотными азиатами не слишком приятно.

На некоторые вакансии я отвечал только для тренировки — обмозговывал задачу и составлял письмо. Было интересно, ответят или нет. Потом просто отклонял предложение, ведь до заключения контракта вы никому ничего не обязаны. После одного из таких отклонений (с пометкой «слишком маленькая цена»), ко мне снова обратился заказчик с предложением заплатить больше. Пришлось всё таки взяться и сделать :)

В общем, у меня к вам один совет: относитесь проще. Начинайте с простого, не нужно рубить с плеча и уходить во фриланс с основной работы. Уйти вы всегда успеете. А за то время, пока вы читали уйму книжек, зачем-то проходили кучу тестов и писали огромный вопрос на хабр, вы могли просто взять и сделать несколько простых задачек на одеске, получить немного звёздочек и практический опыт вместо голой теории.

P. S. Всё вышенаписанное воспринимать как поток сознания дилетанта с тремя выполненными задачками и парой сотен баксов на счету)