alextwinner, если вам нужно получить значение поля для его дальнейшей обработки в sprintf, например, то нужно использовать функцию get_field(). Функция the_field() его сразу же выводит.
JerichoGB, у вас на страницах записей (файл single.php темы оформления) есть вызов функции twentythirteen_post_nav(), которая в рамках вашего шаблона не задана.
musulman, начать стоит с формулировки условий задачи.
Зачастую подобные задачи решаются так: на катере устанавливается небольшой компьютер (Arduino, Paspberry PI или что-то другое), который периодически опрашивает датчики скорости и температуры, а также GPS. После этого с определенной периодичностью он отправляет данные на сервер через SMS или Интернет. Сервер эти данные тем или иным образом получает и записывает в базу данных. На том же сервере должен быть запущен веб-сервер, который выводит страницу с картой и меткой. Сама метка время от времени меняется с помощью скрипта, который подтягивает обновленные данные из базы.
Если катер маленький и плавает относительно недалеко, то можно данные с него загружать через телеметрию.
Astrol, если вы используете статическую страницу в качестве главной, то создайте файл front-page.php и поместите туда код из шаблона услуги. Найти его можно с помощью таблицы иерархии шаблонов.
Это решение скорее-всего сразу не заработает, нужно будет еще дополнительно править как минимум header.php, footer.php и сам код вывода услуги.
LEOnidUKG: Скорее всего в wp_options сделали дорвей и там лежат миллионы страниц дорвея.
В таблице wp_options хранится transient-кеш. Если его не чистить, то размер таблицы может сильно вырасти. Для его очистки есть специальные плагины вроде Transient Cleaner.
Dtachkov: Optimize Database after Deleting Revisions попробуйте поставить этот плагин, возможно он почистит мусор
Ревизии хранятся в таблице с записями wp_posts. Это немного иная история.
NewMoneyMaker: Может же вешать именно эта кривая база?
Запросто. Поиск опций по 1.3 Гб - это не самая простая задача, особенно с учетом того, что таких запросов зачастую много. Не все ведь в курсе об autoload.
От проектов по обновлению чужих проектов на OpenCart я зачастую отказываюсь по описанным выше причинам.
Chukcha: Вы путает бухгалтерскую статистику с web статисткой
Если вы о синхронизации с 1С и другими сервисами, то это совершенно иная история. В некоторых случаях наличие дублей товара с другими опциями может усложнить задачу по синхронизации.
Chukcha: Да все нормально с этим. Как ни странно, разработчики таких модулей идут охотно на контакт.
К сожалению, мой опыт говорит об обратном.
Опции, например, - это достаточно сложный функционал. Его сложность заключается в том, что они используются во многих местах системы: они выводятся на странице товара, в корзине, используются при расчете стоимости, как-то сохраняются при заказе, отображаются в списке заказов, участвуют в управлении остатками на складе и т.д..
По этой причине подобного рода функционал нуждается в качественном тестировании. Если он входит в состав движка, то есть шансы, что его более-менее внятно протестировали и отладили.
Если речь идет о сторонних модулях, то тут возможны варианты, как говорится. К сожалению, их разработчики далеко не всегда подходят к их тестированию со всей ответственностью. Еще меньше они заморачиваются с тестированием совместимости их решений с другими схожими.
На это накладывается проблема отсутствия внятного API для опций и многих других функций. Грубо говоря, разработчикам постоянно приходится выдумывать свои костыли и изобретать велосипеды. В итоге вероятность появления ошибок очень сильно увеличивается.
На практике это мы и наблюдаем: установили несколько модулей для опций, например, они вроде как работают, но картинка в корзине не та, на почту отправляется не то, в списке заказов они отображаются не так и т.д., цену считают неправильно.
Chukcha: Мне кажется, что такая же участь может настичь и филтры в wp (не берусь утверждать) Да согласен проблема есть, проблема связана с семантикой Если color это color, то он должен быть color, хотя в приведенном случае правильно было бы color_my или my_color
В 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.
I-To, скорее-всего там используется Ads-WordPress.
alextwinner, если вам нужно получить значение поля для его дальнейшей обработки в sprintf, например, то нужно использовать функцию get_field(). Функция the_field() его сразу же выводит.
То есть есть:
1. Карта - гуг,яндекс
2. На ней иконка кораблика двигается туда сюда(обновление раз в 15 минут)
В этом случае нужно работать непосредственно с 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 сделали дорвей и там лежат миллионы страниц дорвея.
В таблице wp_options хранится transient-кеш. Если его не чистить, то размер таблицы может сильно вырасти. Для его очистки есть специальные плагины вроде Transient Cleaner.
Optimize Database after Deleting Revisions попробуйте поставить этот плагин, возможно он почистит мусор
Ревизии хранятся в таблице с записями wp_posts. Это немного иная история.
Может же вешать именно эта кривая база?
Запросто. Поиск опций по 1.3 Гб - это не самая простая задача, особенно с учетом того, что таких запросов зачастую много. Не все ведь в курсе об autoload.
Упс.. И часто вы его обновляете?
От проектов по обновлению чужих проектов на OpenCart я зачастую отказываюсь по описанным выше причинам.
Вы путает бухгалтерскую статистику с web статисткой
Если вы о синхронизации с 1С и другими сервисами, то это совершенно иная история. В некоторых случаях наличие дублей товара с другими опциями может усложнить задачу по синхронизации.
Да все нормально с этим.
Как ни странно, разработчики таких модулей идут охотно на контакт.
К сожалению, мой опыт говорит об обратном.
Опции, например, - это достаточно сложный функционал. Его сложность заключается в том, что они используются во многих местах системы: они выводятся на странице товара, в корзине, используются при расчете стоимости, как-то сохраняются при заказе, отображаются в списке заказов, участвуют в управлении остатками на складе и т.д..
По этой причине подобного рода функционал нуждается в качественном тестировании. Если он входит в состав движка, то есть шансы, что его более-менее внятно протестировали и отладили.
Если речь идет о сторонних модулях, то тут возможны варианты, как говорится. К сожалению, их разработчики далеко не всегда подходят к их тестированию со всей ответственностью. Еще меньше они заморачиваются с тестированием совместимости их решений с другими схожими.
На это накладывается проблема отсутствия внятного API для опций и многих других функций. Грубо говоря, разработчикам постоянно приходится выдумывать свои костыли и изобретать велосипеды. В итоге вероятность появления ошибок очень сильно увеличивается.
На практике это мы и наблюдаем: установили несколько модулей для опций, например, они вроде как работают, но картинка в корзине не та, на почту отправляется не то, в списке заказов они отображаются не так и т.д., цену считают неправильно.
Мне кажется, что такая же участь может настичь и филтры в wp (не берусь утверждать)
Да согласен проблема есть, проблема связана с семантикой
Если color это color, то он должен быть color, хотя в приведенном случае правильно было бы color_my или my_color
В 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.