Removing links from headings in docs where warranted. (#43824)
* Removing links from headings in docs where warranted. * Fix readme capitalizion --------- Co-authored-by: Jacklyn Biggin <hi@jacklyn.dev>
This commit is contained in:
Brent MacKinnon
GitHub
parent
7f2fd37fad
commit
73f50e61b3
|
|
@ -6,7 +6,7 @@ tags: how-to
|
|||
|
||||
When you're adding building an extension for WooCommerce that requires settings of some kind, it's important to ask yourself: **Where do they belong?** If your extension just has a couple of simple settings, do you really need to create a new tab specifically for it? Most likely the answer is no.
|
||||
|
||||
## [When to Create a Section](https://github.com/woocommerce/woocommerce/blob/trunk/docs/extesion-developlment/adding-a-section-to-a-settings-tab.md#section-1)
|
||||
## When to Create a Section
|
||||
|
||||
Let's say we had an extension that adds a slider to a single product page. This extension doesn't have many options, just a couple:
|
||||
|
||||
|
|
@ -15,7 +15,7 @@ Let's say we had an extension that adds a slider to a single product page. This
|
|||
|
||||
That's only two options, specifically related to **Products**. We could quite easily just append them onto the core WooCommerce Products Settings (**WooCommerce > Settings > Products**), but that wouldn't be very user friendly. Users wouldn't know where to look initially so they'd have to scan all of the Products options and it would be difficult / impossible to link the options directly. Fortunately, as of WooCommerce 2.2.2, there is a new filter in place that allows you add a new **section**, beneath one of the core settings' tabs.
|
||||
|
||||
## [How to Create a Section](https://github.com/woocommerce/woocommerce/blob/trunk/docs/extesion-developlment/adding-a-section-to-a-settings-tab.md#section-2)
|
||||
## How to Create a Section
|
||||
|
||||
We'll go over doing this through individual functions, but you should probably create a Class that stores all of your settings methods.
|
||||
|
||||
|
|
@ -43,7 +43,7 @@ _[wc-create-section-beneath-products.php](https://gist.github.com/woogists/2964e
|
|||
|
||||
Make sure you change the **wcslider** parts to suit your extension's name / text-domain. The important thing about the `woocommerce_get_sections_products` filter, is that the last part **products**, is the tab you'd like to add a section to. So if you want to add a new tab to accounts section, you would hook into the `woocommerce_get_sections_accounts` filter.
|
||||
|
||||
## [How to Add Settings to a Section](https://github.com/woocommerce/woocommerce/blob/trunk/docs/extesion-developlment/adding-a-section-to-a-settings-tab.md#section-3)
|
||||
## How to Add Settings to a Section
|
||||
|
||||
Now that you've got the tab, you need to filter the output of `woocommerce_get_sections_products` (or similar). You would add the settings like usual using the [**WooCommerce Settings API**](https://github.com/woocommerce/woocommerce/blob/trunk/docs/settings-api/), but check for the current section before adding the settings to the tab's settings array. For example, let's add the sample settings we discussed above to the new **wcslider** section we just created:
|
||||
|
||||
|
|
@ -130,10 +130,10 @@ _[wc-add-settings-section.php](https://gist.github.com/woogists/4038b83900508806
|
|||
|
||||
We're hooking into the same `woocommerce_get_sections_products` filter, but this time doing a check that the `$current_section` matches our earlier defined custom section (wcslider), before adding in our new settings.
|
||||
|
||||
## [Using the New Settings](https://github.com/woocommerce/woocommerce/blob/trunk/docs/extesion-developlment/adding-a-section-to-a-settings-tab.md#section-4)
|
||||
## Using the New Settings
|
||||
|
||||
You would now just use your newly created settings like you would any other WordPress / WooCommerce setting, through the [**get_option**](http://codex.wordpress.org/Function_Reference/get_option) function and the defined ID of the setting. For example, to use the previously created **wcslider_auto_insert** option, simply use the following code: `get_option( 'wcslider_auto_insert' )`
|
||||
|
||||
## [Conclusion](https://github.com/woocommerce/woocommerce/blob/trunk/docs/extesion-developlment/adding-a-section-to-a-settings-tab.md#section-5)
|
||||
## Conclusion
|
||||
|
||||
When creating an extension for WooCommerce, think about where your settings belong before you create them. The key to building a useful product is making it easy to use for the end user, so appropriate setting placement is crucially important. For more specific information on adding settings to WooCommerce, check out the [**Settings API documentation**](https://github.com/woocommerce/woocommerce/blob/trunk/docs/extesion-developlment/settings-api/).
|
||||
|
|
|
|||
|
|
@ -4,13 +4,13 @@ menu_title: Classes in WooCommerce
|
|||
tags: reference
|
||||
---
|
||||
|
||||
## [List of Classes in WooCommerce](https://github.com/woocommerce/woocommerce/blob/trunk/docs/extension-development/class-reference#section-1)
|
||||
## List of Classes in WooCommerce
|
||||
|
||||
For a list of Classes in WooCommerce, please see the [WooCommerce Code Reference](https://woocommerce.github.io/code-reference/packages/WooCommerce-Classes.html).
|
||||
|
||||
## [Common Classes](https://github.com/woocommerce/woocommerce/blob/trunk/docs/extension-development/class-reference#section-2)
|
||||
## Common Classes
|
||||
|
||||
### [WooCommerce](https://github.com/woocommerce/woocommerce/blob/trunk/docs/extension-development/class-reference#section-3)
|
||||
### WooCommerce
|
||||
|
||||
The main class is `woocommerce` which is available globally via the `$woocommerce` variable. This handles the main functions of WooCommerce and init's other classes, stores site-wide variables, and handles error/success messages. The woocommerce class initializes the following classes when constructed:
|
||||
|
||||
|
|
@ -24,7 +24,7 @@ Other classes are auto-loaded on demand.
|
|||
|
||||
View the [WooCommerce Class Code Reference](https://woocommerce.github.io/code-reference/classes/WooCommerce.html) for a full list of methods contained in this class.
|
||||
|
||||
### [WC_Product](https://github.com/woocommerce/woocommerce/blob/trunk/docs/extension-development/class-reference#section-4)
|
||||
### WC_Product
|
||||
|
||||
WooCommerce has several product classes responsible for loading and outputting product data. This can be loaded through PHP using:
|
||||
|
||||
|
|
@ -34,7 +34,7 @@ In the loop this is not always necessary since calling `the_post()` will automa
|
|||
|
||||
View the [WC_Product Code Reference](https://woocommerce.github.io/code-reference/classes/WC-Product.html) for a full list of methods contained in this class.
|
||||
|
||||
### [WC_Customer](https://github.com/woocommerce/woocommerce/blob/trunk/docs/extension-development/class-reference#section-5)
|
||||
### WC_Customer
|
||||
|
||||
The customer class allows you to get data about the current customer, for example:
|
||||
|
||||
|
|
@ -45,7 +45,7 @@ $customer_country = $woocommerce->customer->get_country();
|
|||
|
||||
View the [WC_Customer Code Reference](https://woocommerce.github.io/code-reference/classes/WC-Customer.html) for a full list of methods contained in this class.
|
||||
|
||||
### [WC_Cart](https://github.com/woocommerce/woocommerce/blob/trunk/docs/extension-development/class-reference#section-6)
|
||||
### WC_Cart
|
||||
|
||||
The cart class loads and stores the users cart data in a session. For example, to get the cart subtotal you could use:
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ Merchants make use of WooCommerce extensions daily, and should have a unified an
|
|||
|
||||
Note: We provide this page as a best practice for developers.
|
||||
|
||||
## [Check if WooCommerce is active](https://woo.com/document/create-a-plugin/#section-1)
|
||||
## Check if WooCommerce is active
|
||||
|
||||
Most WooCommerce plugins do not need to run unless WooCommerce is already active. You can wrap your plugin in a check to see if WooCommerce is installed:
|
||||
|
||||
|
|
@ -44,25 +44,25 @@ in_array( $plugin_path, wp_get_active_and_valid_plugins() )
|
|||
|
||||
Note that this check will fail if the WC plugin folder is named anything other than woocommerce.
|
||||
|
||||
## [Main file naming](https://woo.com/document/create-a-plugin/#section-2)
|
||||
## Main file naming
|
||||
|
||||
The main plugin file should adopt the name of the plugin, e.g., A plugin with the directory name plugin-name would have its main file named plugin-name.php.
|
||||
|
||||
## [Text domains](https://woo.com/document/create-a-plugin/#section-3)
|
||||
## Text domains
|
||||
|
||||
Follow guidelines for [Internationalization for WordPress Developers](https://codex.wordpress.org/I18n_for_WordPress_Developers), the text domain should match your plugin directory name, e.g., A plugin with a directory name of plugin-name would have the text domain plugin-name. Do not use underscores.
|
||||
|
||||
## [Localization](https://woo.com/document/create-a-plugin/#section-4)
|
||||
## Localization
|
||||
|
||||
All text strings within the plugin code should be in English. This is the WordPress default locale, and English should always be the first language. If your plugin is intended for a specific market (e.g., Spain or Italy), include appropriate translation files for those languages within your plugin package. Learn more at [Using Makepot to translate your plugin](https://codex.wordpress.org/I18n_for_WordPress_Developers#Translating_Plugins_and_Themes).
|
||||
|
||||
## [Follow WordPress PHP Guidelines](https://woo.com/document/create-a-plugin/#section-5)
|
||||
## Follow WordPress PHP Guidelines
|
||||
|
||||
WordPress has a [set of guidelines](http://make.wordpress.org/core/handbook/coding-standards/php/) to keep all WordPress code consistent and easy to read. This includes quotes, indentation, brace style, shorthand php tags, yoda conditions, naming conventions, and more. Please review the guidelines.
|
||||
|
||||
Code conventions also prevent basic mistakes, as [Apple made with iOS 7.0.6](https://www.imperialviolet.org/2014/02/22/applebug.html).
|
||||
|
||||
## [Custom Database Tables & Data Storage](https://woo.com/document/create-a-plugin/#section-6)
|
||||
## Custom Database Tables & Data Storage
|
||||
|
||||
Avoid creating custom database tables. Whenever possible, use WordPress [post types](http://codex.wordpress.org/Post_Types#Custom_Post_Types), [taxonomies](http://codex.wordpress.org/Taxonomies), and [options](http://codex.wordpress.org/Creating_Options_Pages).
|
||||
|
||||
|
|
@ -76,7 +76,7 @@ Consider the permanence of your data. Here's a quick primer:
|
|||
|
||||
Logs should be written to a file using the [WC_Logger](https://woo.com/wc-apidocs/class-WC_Logger.html) class.
|
||||
|
||||
## [Prevent Data Leaks](https://woo.com/document/create-a-plugin/#section-7)
|
||||
## Prevent Data Leaks
|
||||
|
||||
Try to prevent direct access data leaks. Add this line of code after the opening PHP tag in each PHP file:
|
||||
|
||||
|
|
@ -86,11 +86,11 @@ exit; // Exit if accessed directly
|
|||
}
|
||||
```
|
||||
|
||||
## [Readme](https://woo.com/document/create-a-plugin/#section-8)
|
||||
## README
|
||||
|
||||
All plugins need a [standard WordPress readme](http://wordpress.org/plugins/about/readme.txt).
|
||||
All plugins need a [standard WordPress README](http://wordpress.org/plugins/about/readme.txt).
|
||||
|
||||
Your readme might look something like this:
|
||||
Your README might look something like this:
|
||||
|
||||
```php
|
||||
=== Plugin Name ===
|
||||
|
|
@ -104,7 +104,7 @@ License: GPLv3 or later License
|
|||
URI: http://www.gnu.org/licenses/gpl-3.0.html
|
||||
```
|
||||
|
||||
## [Plugin Author Name](https://woo.com/document/create-a-plugin/#section-9)
|
||||
## Plugin Author Name
|
||||
|
||||
To ensure a consistent experience for all WooCommerce users,including finding information on who to contact with queries, the following plugin headers should be in place:
|
||||
|
||||
|
|
@ -135,18 +135,18 @@ For example:
|
|||
*/
|
||||
```
|
||||
|
||||
## [Declaring required and supported WooCommerce version](https://woo.com/document/create-a-plugin/#section-10)
|
||||
## Declaring required and supported WooCommerce version
|
||||
|
||||
Use the follow headers to declare "required" and "tested up to" versions:
|
||||
|
||||
- WC requires at least
|
||||
- WC tested up to
|
||||
|
||||
## [Plugin URI](https://woo.com/document/create-a-plugin/#section-11)
|
||||
## Plugin URI
|
||||
|
||||
Ensure that the Plugin URI line of the above plugin header is provided. This line should contain the URL of the plugin's product/sale page or to a dedicated page for the plugin on your website.
|
||||
|
||||
## [Make it Extensible](https://woo.com/document/create-a-plugin/#section-13)
|
||||
## Make it Extensible
|
||||
|
||||
Developers should use WordPress actions and filters to allow for modification/customization without requiring users to touch the plugin's core code base.
|
||||
|
||||
|
|
@ -154,23 +154,23 @@ If your plugin creates a front-end output, we recommend to having a templating e
|
|||
|
||||
For more information, check out Pippin's post on [Writing Extensible Plugins with Actions and Filters](http://code.tutsplus.com/tutorials/writing-extensible-plugins-with-actions-and-filters--wp-26759).
|
||||
|
||||
## [Use of External Libraries](https://woo.com/document/create-a-plugin/#section-14)
|
||||
## Use of External Libraries
|
||||
|
||||
The use of entire external libraries is typically not suggested as this can open up the product to security vulnerabilities. If an external library is absolutely necessary, developers should be thoughtful about the code used and assume ownership as well as of responsibility for it. Try to only include the strictly necessary part of the library, or use a WordPress-friendly version or opt to build your own version. For example, if needing to use a text editor such as TinyMCE, we recommend using the WordPress-friendly version, TinyMCE Advanced.
|
||||
|
||||
## [Remove Unused Code](https://woo.com/document/create-a-plugin/#section-15)
|
||||
## Remove Unused Code
|
||||
|
||||
With version control, there's no reason to leave commented-out code; it's annoying to scroll through and read. Remove it and add it back later if needed.
|
||||
|
||||
## [Comment](https://woo.com/document/create-a-plugin/#section-16)
|
||||
## Comment
|
||||
|
||||
If you have a function, what does the function do? There should be comments for most if not all functions in your code. Someone/You may want to modify the plugin, and comments are helpful for that. We recommend using [PHP Doc Blocks](http://en.wikipedia.org/wiki/PHPDoc) similar to [WooCommerce](https://github.com/woocommerce/woocommerce/).
|
||||
|
||||
## [Avoid God Objects](https://woo.com/document/create-a-plugin/#section-17)
|
||||
## Avoid God Objects
|
||||
|
||||
[God Objects](http://en.wikipedia.org/wiki/God_object) are objects that know or do too much. The point of object-oriented programming is to take a large problem and break it into smaller parts. When functions do too much, it's hard to follow their logic, making bugs harder to fix. Instead of having massive functions, break them down into smaller pieces.
|
||||
|
||||
## [Test Extension Quality & Security with Quality Insights Tool](https://woo.com/document/create-a-plugin/#section-18)
|
||||
## Test Extension Quality & Security with Quality Insights Tool
|
||||
|
||||
Integrate the [Quality Insights Toolkit (QIT)](https://woocommerce.github.io/qit-documentation/) into your development workflow to ensure your extension adheres to WordPress / WooCommerce quality and security standards. The QIT allows the ability to test your extensions against new releases of PHP, WooCommerce, and WordPress, as well as other active extensions, at the same time. The following tests are available today:
|
||||
|
||||
|
|
@ -180,19 +180,19 @@ Integrate the [Quality Insights Toolkit (QIT)](https://woocommerce.github.io/qit
|
|||
- [PHPStan](https://woocommerce.github.io/qit-documentation/#/test-types/phpstan)
|
||||
- [API](https://woocommerce.github.io/qit-documentation/#/test-types/api)
|
||||
|
||||
## [Test Your Code with WP_DEBUG](https://woo.com/document/create-a-plugin/#section-19)
|
||||
## Test Your Code with WP_DEBUG
|
||||
|
||||
Always develop with [WP_DEBUG](http://codex.wordpress.org/Debugging_in_WordPress) mode on, so you can see all PHP warnings sent to the screen. This will flag things like making sure a variable is set before checking the value.
|
||||
|
||||
## [Separate Business Logic & Presentation Logic](https://woo.com/document/create-a-plugin/#section-20)
|
||||
## Separate Business Logic & Presentation Logic
|
||||
|
||||
It's a good practice to separate business logic (i.e., how the plugin works) from [presentation logic](http://en.wikipedia.org/wiki/Presentation_logic) (i.e., how it looks). Two separate pieces of logic are more easily maintained and swapped if necessary. An example is to have two different classes - one for displaying the end results, and one for the admin settings page.
|
||||
|
||||
## [Use Transients to Store Offsite Information](https://woo.com/document/create-a-plugin/#section-21)
|
||||
## Use Transients to Store Offsite Information
|
||||
|
||||
If you provide a service via an API, it's best to store that information so future queries can be done faster and the load on your service is lessened. [WordPress transients](http://codex.wordpress.org/Transients_API) can be used to store data for a certain amount of time.
|
||||
|
||||
## [Logging Data](https://woo.com/document/create-a-plugin/#section-22)
|
||||
## Logging Data
|
||||
|
||||
You may want to log data that can be useful for debugging purposes. This is great with two conditions:
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ In January 2022, we published the [initial plan for the Custom Order Tables feat
|
|||
|
||||
From WooCommerce 8.2, released on October 2023, [High-Performance Order Storage (HPOS)](https://developer.woo.com/2022/09/14/high-performance-order-storage-progress-report/) is officially released under the stable flag and will be enabled by default for new installations.
|
||||
|
||||
## [What's New with High-Performance Order Storage?](https://github.com/woocommerce/woocommerce/blob/trunk/docs/high-performance-order-storage/#section-1)
|
||||
## What's New with High-Performance Order Storage?
|
||||
|
||||
Bringing High-Performance Order Storage (HPOS) to WooCommerce improves these three essential properties for eCommerce stores.
|
||||
|
||||
|
|
@ -32,7 +32,7 @@ You no longer have to go through a single huge database to locate underlying dat
|
|||
|
||||
With High-Performance Order Storage, you can easily browse through the separate tables and easy-to-handle entries, independent of the table `_posts`, to find data or understand the table structure. It also lets you easily develop new plugins, implement designs for shops and products, and modify WooCommerce with more flexibility.
|
||||
|
||||
## [Background](https://github.com/woocommerce/woocommerce/blob/trunk/docs/high-performance-order-storage/#section-2)
|
||||
## Background
|
||||
|
||||
Before the release of version 8.2, WooCommerce relied on the `_post` and `_postmeta` table structures to store order information, which has served well over the years.
|
||||
|
||||
|
|
@ -46,15 +46,15 @@ The order data is synced from `_posts` and `_postmeta` table to four custom orde
|
|||
4. `_wc_orders_meta`
|
||||
|
||||
|
||||
## [Enabling the feature](https://github.com/woocommerce/woocommerce/blob/trunk/docs/high-performance-order-storage/#section-3)
|
||||
## Enabling the feature
|
||||
|
||||
From WooCommerce 8.2, released on October 2023, HPOS is enabled by default for new installations. Existing stores can check [How to enable HPOS](https://github.com/woocommerce/woocommerce/blob/trunk/docs/high-performance-order-storage/enable-hpos.md)
|
||||
|
||||
## [Database tables](https://github.com/woocommerce/woocommerce/blob/trunk/docs/high-performance-order-storage/#section-4)
|
||||
## Database tables
|
||||
|
||||
A number of database tables are used to store order data by HPOS. The `get_all_table_names` method in [the OrdersTableDataStore class](https://github.com/woocommerce/woocommerce/blob/trunk/plugins/woocommerce/src/Internal/DataStores/Orders/OrdersTableDataStore.php) will return the names of all the tables.
|
||||
|
||||
## [Authoritative tables](https://github.com/woocommerce/woocommerce/blob/trunk/docs/high-performance-order-storage/#section-5)
|
||||
## Authoritative tables
|
||||
|
||||
At any given time, while the HPOS feature is enabled, there are two roles for the involved database tables: _authoritative_ and _backup_. The authoritative tables are the working tables, where order data will be stored to and retrieved from during normal operation of the store. The _backup_ tables will receive a copy of the authoritative data whenever [synchronization](#synchronization) happens.
|
||||
|
||||
|
|
@ -64,7 +64,7 @@ If the `woocommerce_custom_orders_table_enabled` options is set to true, HPOS is
|
|||
|
||||
In order to preserve data integrity, switching the authoritative tables (from the new tables to the posts table or the other way around) isn't allowed while there are orders pending synchronization.
|
||||
|
||||
## [Synchronization](https://github.com/woocommerce/woocommerce/blob/trunk/docs/high-performance-order-storage/#section-6)
|
||||
## Synchronization
|
||||
|
||||
_Synchronization_ is the process of applying all the pending changes in the authoritative tables to the backup tables. _Orders pending synchronization_ are orders that have been modified in the authoritative tables but the changes haven't been applied to the backup tables yet.
|
||||
|
||||
|
|
@ -113,7 +113,7 @@ When the "**High-Performance Order Storage**" and "**Compatibility mode**" are e
|
|||
|
||||
> You can find a deeper explanation about the synchronization between the tables in [this document about high-performance-order-storage-backward-compatibility-and-synchronization](https://developer.woo.com/2022/09/29/high-performance-order-storage-backward-compatibility-and-synchronization/#synchronization).
|
||||
|
||||
## [Placeholder records](https://github.com/woocommerce/woocommerce/blob/trunk/docs/high-performance-order-storage/#section-7)
|
||||
## Placeholder records
|
||||
|
||||
Order IDs must match in both the authoritative tables and the backup tables, otherwise synchronization wouldn't be possible. The order IDs that are compared for order identification and synchronization purposes are the ones from the `id` field in both the `wp_wc_orders` table and the posts table.
|
||||
|
||||
|
|
@ -122,7 +122,7 @@ If the posts table is authoritative, achieving an order ID match is easy: the re
|
|||
To solve this, _placeholder records_ are used. Whenever the new orders tables are authoritative and immediate synchronization is disabled, creating a new order will cause a record with post type `shop_order_placehold` and the same ID as the order to be created in the posts table; this effectively "reserves" the order ID in the posts table. Then, at synchronization time, the record is filled appropriately and its post type is changed to `shop_order`.
|
||||
|
||||
|
||||
## [Order Data Storage](https://github.com/woocommerce/woocommerce/blob/trunk/docs/high-performance-order-storage/#section-8)
|
||||
## Order Data Storage
|
||||
|
||||
You can switch between data stores freely to sync the data between the tables.
|
||||
|
||||
|
|
@ -139,7 +139,7 @@ You can switch between data stores freely to sync the data between the tables.
|
|||
|
||||
|
||||
|
||||
## [Incompatible Plugins](https://github.com/woocommerce/woocommerce/blob/trunk/docs/high-performance-order-storage/#section-9)
|
||||
## Incompatible Plugins
|
||||
|
||||
If you are using a plugin that is not compatible with High-Performance Order Storage, then the HPOS option will be disabled under **WooCommerce > Settings > Advanced > Features**.
|
||||
|
||||
|
|
@ -153,7 +153,7 @@ If you are using a plugin that is not compatible with High-Performance Order Sto
|
|||
> **Note:** If you are using a third-party extension that isn't working properly with High-Performance Order Storage then please notify the developers of the extension and ask them to update their extension to add support for HPOS. It's up to the extension developers to add support for HPOS. We have [developer resources and documentation](https://developer.woo.com/2022/09/14/high-performance-order-storage-progress-report/) available to help with their integration efforts.
|
||||
|
||||
|
||||
## [Disabling HPOS](https://github.com/woocommerce/woocommerce/blob/trunk/docs/high-performance-order-storage/#section-10)
|
||||
## Disabling HPOS
|
||||
|
||||
If you encounter problems or if you need to continue working with plugins that are not yet compatible with HPOS, then we recommend temporarily switching back to **WordPress posts storage**.
|
||||
|
||||
|
|
|
|||
|
|
@ -4,11 +4,11 @@ menu_title: Risks of removing URL bases
|
|||
tags: reference
|
||||
---
|
||||
|
||||
## [In sum](https://github.com/woocommerce/woocommerce/blob/trunk/docs/quality-and-best-practices/removing-product-product-category-or-shop-from-the-urls.md#section-1)
|
||||
## In sum
|
||||
|
||||
Removing `/product/`, `/product-category/`, or `/shop/` from the URLs is not advisable due to the way WordPress resolves its URLs. It uses the `product-category` (or any other text for that matter) base of a URL to detect that it is a URL leading to a product category. There are SEO plugins that allow you to remove this base, but that can lead to a number of problems with performance and duplicate URLs.
|
||||
|
||||
## [Better to avoid](https://github.com/woocommerce/woocommerce/blob/trunk/docs/quality-and-best-practices/removing-product-product-category-or-shop-from-the-urls.md#section-2)
|
||||
## Better to avoid
|
||||
|
||||
You will make it harder for WordPress to detect what page you are trying to reach when you type in a product category URL. Also, understand that the standard "Page" in WordPress always has no base text in the URL. For example:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +1,12 @@
|
|||
# Webhooks
|
||||
|
||||
## [What are Webhooks?](https://github.com/woocommerce/woocommerce/blob/trunk/docs/webhooks#what-are-webhooks)
|
||||
## What are Webhooks?
|
||||
|
||||
A [Webhook](http://en.wikipedia.org/wiki/Webhook) is an event notification sent to a URL of your choice. Users can configure them to trigger events on one site to invoke behavior on another.
|
||||
|
||||
Webhooks are useful for integrating with third-party services and other external API that support them.
|
||||
|
||||
## [Webhooks in WooCommerce](https://github.com/woocommerce/woocommerce/blob/trunk/docs/webhooks#webhooks-in-woocommerce)
|
||||
## Webhooks in WooCommerce
|
||||
|
||||
Webhooks were introduced in WooCommerce 2.2 and can trigger events each time you add, edit or delete orders, products, coupons or customers.
|
||||
|
||||
|
|
@ -14,7 +14,7 @@ It's also possible to use webhooks with WooCommerce actions, e.g., Create a webh
|
|||
|
||||
Webhooks also make it easier for third-party apps to integrate with WooCommerce.
|
||||
|
||||
## [Creating webhooks](https://github.com/woocommerce/woocommerce/blob/trunk/docs/webhooks#creating-webhooks)
|
||||
## Creating webhooks
|
||||
|
||||
|
||||
|
||||
|
|
@ -45,7 +45,7 @@ Webhooks are disabled after 5 retries by default if the delivery URL returns an
|
|||
|
||||
To increase the number of retries, you can use the `woocommerce_max_webhook_delivery_failures` filter function.
|
||||
|
||||
## [Editing and deleting webhooks](https://github.com/woocommerce/woocommerce/blob/trunk/docs/webhooks#editing-and-deleting-webhooks)
|
||||
## Editing and deleting webhooks
|
||||
|
||||
Webhooks are listed the same way as posts or products.
|
||||
|
||||
|
|
@ -55,7 +55,7 @@ Webhooks are listed the same way as posts or products.
|
|||
|
||||
|
||||
|
||||
## [Webhook logs](https://github.com/woocommerce/woocommerce/blob/trunk/docs/webhooks#webhook-logs)
|
||||
## Webhook logs
|
||||
|
||||
WooCommerce saves logs of all events triggering a webhook. Webhook logs are found at: **WooCommerce > Status > Logs**.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue