I-To, скорее-всего там используется Ads-WordPress.
alextwinner, если вам нужно получить значение поля для его дальнейшей обработки в sprintf, например, то нужно использовать функцию get_field(). Функция the_field() его сразу же выводит.
В этом случае нужно работать непосредственно с API Google Maps или Яндекс.Карты. Для карт Google есть целая библиотека для анимации движения маркера
JerichoGB, у вас на страницах записей (файл single.php темы оформления) есть вызов функции twentythirteen_post_nav(), которая в рамках вашего шаблона не задана.
musulman, начать стоит с формулировки условий задачи.
Зачастую подобные задачи решаются так: на катере устанавливается небольшой компьютер (Arduino, Paspberry PI или что-то другое), который периодически опрашивает датчики скорости и температуры, а также GPS. После этого с определенной периодичностью он отправляет данные на сервер через SMS или Интернет. Сервер эти данные тем или иным образом получает и записывает в базу данных. На том же сервере должен быть запущен веб-сервер, который выводит страницу с картой и меткой. Сама метка время от времени меняется с помощью скрипта, который подтягивает обновленные данные из базы.
Если катер маленький и плавает относительно недалеко, то можно данные с него загружать через телеметрию.
Как вариант - можно использовать соответствующее HTML5 API: HTML5 Geolocation
Astrol, если вы используете статическую страницу в качестве главной, то создайте файл front-page.php и поместите туда код из шаблона услуги. Найти его можно с помощью таблицы иерархии шаблонов.
Это решение скорее-всего сразу не заработает, нужно будет еще дополнительно править как минимум header.php, footer.php и сам код вывода услуги.
Это и есть transient кеш, о котором я говорил выше. В большинстве случаев его можно смело чистить.
В вашем случае его сгенерировал виджет Yuzo - Related Posts для хранения схожих записей.
В таблице wp_options хранится transient-кеш. Если его не чистить, то размер таблицы может сильно вырасти. Для его очистки есть специальные плагины вроде Transient Cleaner.
Ревизии хранятся в таблице с записями wp_posts. Это немного иная история.
Запросто. Поиск опций по 1.3 Гб - это не самая простая задача, особенно с учетом того, что таких запросов зачастую много. Не все ведь в курсе об autoload.
От проектов по обновлению чужих проектов на OpenCart я зачастую отказываюсь по описанным выше причинам.
Если вы о синхронизации с 1С и другими сервисами, то это совершенно иная история. В некоторых случаях наличие дублей товара с другими опциями может усложнить задачу по синхронизации.
К сожалению, мой опыт говорит об обратном.
Опции, например, - это достаточно сложный функционал. Его сложность заключается в том, что они используются во многих местах системы: они выводятся на странице товара, в корзине, используются при расчете стоимости, как-то сохраняются при заказе, отображаются в списке заказов, участвуют в управлении остатками на складе и т.д..
По этой причине подобного рода функционал нуждается в качественном тестировании. Если он входит в состав движка, то есть шансы, что его более-менее внятно протестировали и отладили.
Если речь идет о сторонних модулях, то тут возможны варианты, как говорится. К сожалению, их разработчики далеко не всегда подходят к их тестированию со всей ответственностью. Еще меньше они заморачиваются с тестированием совместимости их решений с другими схожими.
На это накладывается проблема отсутствия внятного API для опций и многих других функций. Грубо говоря, разработчикам постоянно приходится выдумывать свои костыли и изобретать велосипеды. В итоге вероятность появления ошибок очень сильно увеличивается.
На практике это мы и наблюдаем: установили несколько модулей для опций, например, они вроде как работают, но картинка в корзине не та, на почту отправляется не то, в списке заказов они отображаются не так и т.д., цену считают неправильно.
В WordPress в общем и WooCommerce в частности вероятность подобной ошибки значительно ниже. Связано это с тем, что данная система целиком и полностью построена на событиях и фильтрах. Наличие огромного количества стабильных вспомогательных функций в движке также упрощает с ним работу.
Возьмем банальнейший пример: для товара нужно добавить возможность выбора метки из списка. Сначала рассмотрим аспект разработки.
В OpenCart для этого нужно сначала добавить соответствующее поле в базе данных, добавить его в шаблон товара в админке вместе с переводами строк, написать его проверку, сохранение и вывод из базы данных. После этого нужно изменить файл модели на фронтенде, поправить контроллер, дописать в массив с товарами это поле и только после этого я смогу его выводить в шаблоне каталога. Если требуется это выводить еще в каком-то модуле, то и там тоже нужно внести эти изменения. Грубо говоря, мне нужно внести изменения в десяток файлов и базу данных, чтобы банально вывести одно несчастное поле.
В WooCommerce для реализации этого функционала мне нужно написать всего две функции: одну для отображения поля в админке и одну для его сохранения. После этого их нужно прикрепить к событиям woocommerce_product_options_general_product_data и woocommerce_process_product_meta. В функции отображения поля я могу воспользоваться функцией woocommerce_wp_select, чтобы не вбивать ручками select-ы с label-ами. Для вывода метки в любом месте шаблона я могу использовать стандартную функцию get_post_meta.
Очевидно, что в случае с OpenCart допустить ошибку на порядок проще, поскольку код движка правится в очень многих местах. В WordPress - в одном.
Второй аспект - это поддерживаемость кода. В случае с WordPress я могу без проблем вынести функции их связывание с событиями в отдельный файл темы или плагин. После этого я могу его переносить между всеми своими проектами на разных версиях WordPress и он там с огромной долей вероятности будет работать. Разработчики, которые будут после меня заниматься проектом, также смогут без лишней головной боли разобраться что тот код делает.
В случае с OpenCart мне сначала нужно внести изменения в кучу файлов, составить xml-файл с описанием что и где нужно менять. После этого нужно откатить изменения во всех файлах и проверить по кешу правильно ли отрабатывает ocmod/vqmod. На этом мои развлечения не заканчиваются. Перед началом каждого проекта на новой версии OpenCart мне нужно проверять ничего ли не сломалось, заменяется ли нужный код в нужных местах. Также мне нужно внести изменения в базу данных. Разработчику, который будет позже работать с этим всем колгоспом, также придется несладко.
Ну и последний аспект - это обновление.
В случае с WP с обновлением существенных проблем не должно возникнуть, поскольку код использует стабильные функции/API, которые разработчики крайне редко меняют. Перед этим PHPStorm еще несколько раз предупреждение выдаст, что мол такой-то функционал помечен как deprecated.
В случае с OpenCart с обновлением проблем на порядок больше. Вот захотелось Даниелю вдруг модель для продуктов поменять. Модификации, которые с этим связаны, могут тихо перестать работать, гордо сообщая при этом в логах при каждой генерации страницы. И вот имеем красивую такую "бомбочку".
Резюмируя, хочу отметить, что на данном этапе с точки зрения удобства разработки и поддержки WordPress на порядок удобнее для разработчика чем OpenCart.
