migrating images out of docs folder (#42851)
* migrating images out of docs folder Migrating images from '_media' folders to developer.woo.com/docs media folder and removing media folders and image files from docs folder. * Delete 73 results - 16 files.md
This commit is contained in:
Brent MacKinnon
GitHub
parent
10f6109982
commit
b36bacf531
|
|
@ -205,7 +205,7 @@ The priority argument is set during the [add_action](https://developer.wordpress
|
|||
|
||||
In the example below, blue text is the name of the hook we're modifying, green text is the name of our custom function, and red is the priority we set.
|
||||
|
||||
|
||||
|
||||
|
||||
## Examples
|
||||
|
||||
|
|
@ -294,7 +294,7 @@ function my_custom_checkout_field_display_admin_order_meta($order){
|
|||
}
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
It's alive!
|
||||
|
||||
|
|
@ -332,7 +332,7 @@ function my_custom_checkout_field( $checkout ) {
|
|||
|
||||
This gives us:
|
||||
|
||||
|
||||
|
||||
|
||||
Next we need to validate the field when the checkout form is posted. For this example the field is required and not optional:
|
||||
|
||||
|
|
@ -352,7 +352,7 @@ function my_custom_checkout_field_process() {
|
|||
|
||||
A checkout error is displayed if the field is blank:
|
||||
|
||||
|
||||
|
||||
|
||||
Finally, let's save the new field to order custom fields using the following code:
|
||||
|
||||
|
|
@ -386,7 +386,7 @@ function my_custom_checkout_field_display_admin_order_meta( $order ){
|
|||
|
||||
This is the result:
|
||||
|
||||
[](https://woo.com/wp-content/uploads/2012/04/checkout_field_custom_field_admin.png)
|
||||
|
||||
|
||||
### Make phone number not required
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ post_title: WooCommerce Git flow
|
|||
|
||||
For core development, we use the following structure and flow.
|
||||
|
||||
|
||||
|
||||
|
||||
## Branches
|
||||
|
||||
|
|
|
|||
|
|
@ -72,4 +72,4 @@ addFilter(
|
|||
|
||||
Here's a screen shot using our new custom store management link:
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ The following endpoints are used for account-related functionality and are appe
|
|||
|
||||
The URL for each endpoint can be customized in **WooCommerce > Settings > Advanced** in the Page setup section.
|
||||
|
||||
|
||||
|
||||
|
||||
Ensure that they are unique to avoid conflicts. If you encounter issues with 404s, go to **Settings > Permalinks** and save to flush the rewrite rules.
|
||||
|
||||
|
|
@ -47,7 +47,7 @@ Ensure that they are unique to avoid conflicts. If you encounter issues with 404
|
|||
|
||||
If you want to include an endpoint in your menus, you need to use the Links section:
|
||||
|
||||
|
||||
|
||||
|
||||
Enter the full URL to the endpoint and then insert that into your menu.
|
||||
|
||||
|
|
@ -105,4 +105,4 @@ Landing on the wrong page when clicking an endpoint URL is typically caused by i
|
|||
|
||||
Sometimes the “Downloads” endpoint on the “My account” page does not need to be displayed. This can be removed by going to **WooCommerce → Settings → Advanced → Account endpoints** and clearing the Downloads endpoint field.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -126,27 +126,27 @@ You can switch between data stores freely to sync the data between the tables.
|
|||
|
||||
- If you select **“WordPress Post Tables”**, the system will save the order data within `_post` and `_postmeta` tables. The order tables are not utilized in this scenario.
|
||||
|
||||
|
||||
|
||||
|
||||
- If you select **“High-Performance Order Storage”**, the system will save the order data within the new WooCommerce order tables
|
||||
|
||||
|
||||
|
||||
|
||||
- If you select **“WordPress Post Tables”** and **“Enable compatibility mode”**, the system will sync the order data between the posts/postmeta and the WooCommerce order tables.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## [Incompatible Plugins](https://github.com/woocommerce/woocommerce/blob/trunk/docs/high-performance-order-storage/#section-9)
|
||||
|
||||
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**.
|
||||
|
||||
|
||||
|
||||
|
||||
- You can click on “**View and manage**” to review the list of incompatible plugins
|
||||
- Or you can visit `https://example.com/wp-admin/plugins.php?plugin_status=incompatible_with_feature&feature_id=custom_order_tables` to review the list of incompatible plugins (please replace `example.com` with your site domain)
|
||||
|
||||
|
||||
|
||||
|
||||
> **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.
|
||||
|
||||
|
|
@ -157,7 +157,7 @@ If you encounter problems or if you need to continue working with plugins that a
|
|||
|
||||
To do this, navigate to **WooCommerce ▸ Settings ▸ Advanced ▸ Features** and start by making sure that **compatibility mode** is enabled. If it was not already enabled, you may find you need to wait for some time while order data is synchronized across data-stores.
|
||||
|
||||
|
||||
|
||||
|
||||
Once synchronization has completed, you can select **WordPress posts storage (legacy)** as your preferred option. You can also disable compatibility mode at this point. Once you are ready to re-enable HPOS, simply follow the instructions posted at the [start of this doc](https://github.com/woocommerce/woocommerce/blob/trunk/docs/high-performance-order-storage/#section-3). Finally, remember to save this page between changes!
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ To activate High-Performance Order Storage, existing stores will first need to g
|
|||
1/ Navigate to **WooCommerce > Settings > Advanced > Features**
|
||||
2/ Turn on the **“Enable compatibility mode (synchronizes orders to the posts table)”** setting.
|
||||
|
||||
|
||||
|
||||
|
||||
3/ Once this setting is activated, background actions will be scheduled.
|
||||
|
||||
|
|
@ -18,8 +18,8 @@ To activate High-Performance Order Storage, existing stores will first need to g
|
|||
- You can either wait for these actions to run on their own, which should be quite soon, or you can go to **WooCommerce > Status > Scheduled Actions**, find the actions and click on the run button.
|
||||
- The action will backfill 25 orders at a time, if there are more orders to be synced, then more actions will be scheduled as soon as the previous actions are completed.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
4/ After both tables are successfully synchronized, you'll be able to select the option to switch to High-Performance Order Storage (HPOS).
|
||||
|
||||
|
|
|
|||
|
|
@ -32,19 +32,17 @@ If you're new to translating, check out the [translators handbook](https://make.
|
|||
1. Go to [translate.wordpress.org](https://translate.wordpress.org/projects/wp-plugins/woocommerce) and look for your language in the list.
|
||||
2. Click the title to be taken to the section for that language.
|
||||
|
||||
|
||||
|
||||
|
||||
3. Click the heading under `Set/Sub Project` to view and download a Stable version.
|
||||
|
||||
|
||||
|
||||
|
||||
4. Scroll to the bottom for export options. Export a `.mo` file for use on your site.
|
||||
|
||||
|
||||
|
||||
5. Rename this file to `woocommerce-YOURLANG.mo` (e.g., Great Britain English should be `en_GB`). The corresponding language code can be found by going to [https://translate.wordpress.org/projects/wp-plugins/woocommerce/](https://translate.wordpress.org/projects/wp-plugins/woocommerce/) and opening the desired language. The language code is visible in the upper-right corner.
|
||||
|
||||
|
||||
|
||||
|
||||
6. Upload to your site under `wp-content/languages/woocommerce/`. Once uploaded, this translation file may be used.
|
||||
|
||||
|
|
@ -61,12 +59,12 @@ To get started:
|
|||
1. Open PoEdit and select `Create new translation from POT template`.
|
||||
2. Choose `woocommerce.pot` and PoEdit will show the catalog properties window.
|
||||
|
||||
|
||||
|
||||
|
||||
3. Enter your name and details, so other translators know who you are, and click `OK`.
|
||||
4. Save your `.po` file. Name it based on what you are translating to, i.e., a GB translation is saved as `woocommerce-en_GB.po`. Now the strings are listed.
|
||||
|
||||
|
||||
|
||||
|
||||
5. Save after translating strings. The `.mo` file is generated automatically.
|
||||
6. Update your `.po` file by opening it and then go to `Catalog » Update from POT file`.
|
||||
|
|
@ -118,7 +116,7 @@ There are some other third-party tools that can help with translations. The foll
|
|||
|
||||
You may see that some of the strings are not being translated on the Checkout page. For example, in the screenshot below, `Local pickup` shipping method, `Cash on delivery` payment method and a message related to Privacy Policy are not being translated to Russian while the rest of the form is indeed translated:
|
||||
|
||||
|
||||
|
||||
|
||||
This usually happens when you first install WooCommerce and select default site language (English) and later change the site language to another one. In WooCommerce, the strings that have not been translated in the screenshot, are stored in the database after the initial WooCommerce installation. Therefore, if the site language is changed to another one, there is no way for WooCommerce to detect a translatable string since these are database entries.
|
||||
|
||||
|
|
@ -155,8 +153,8 @@ If some of your translated strings don't show up as expected on your WooCommerce
|
|||
|
||||
This screenshot shows that the Singular translation is available:
|
||||
|
||||
|
||||
|
||||
|
||||
While this screenshot shows that the Plural translation is not available:
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ This handbook is a guide for extension developers looking to add support for the
|
|||
|
||||
The product editor's UI consists of Groups (currently rendered as tabs), Sections, and Fields, which are all blocks. For guidelines on how to extend the product editor (e.g. where to add blocks), please refer to the [Product Editor Extensibility Guidelines](./product-editor-extensibility-guidelines.md).
|
||||
|
||||
|
||||
|
||||
|
||||
The form's structure is defined in PHP using a Template, which is a tree structure of blocks. The template can be modified by using the Template API to add new Groups, Sections, and Fields as well as remove existing ones.
|
||||
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ Like everything in the new product form, each extension point is a separate bloc
|
|||
|
||||
The new product form consists of groups currently displayed as tabs. Each is a separate view and may contain any number of sections and subsections. All areas serve a specific purpose, allowing merchants to quickly find the information they're looking for (both in default Woo features and extensions).
|
||||
|
||||
|
||||
|
||||
|
||||
If a tab doesn't contain any sections, it won't be shown to merchants.
|
||||
|
||||
|
|
@ -97,7 +97,7 @@ With so much advanced functionality, the plugin would best register a new produc
|
|||
|
||||
### Fields
|
||||
|
||||
|
||||
|
||||
|
||||
Fields are the simplest type of extension. They let users add extra product information, replace or manage the visibility of other fields assigned to a specific product type, and control the contents of other fields.
|
||||
|
||||
|
|
@ -122,7 +122,7 @@ Field extensions should always be logically related to the form area they are in
|
|||
|
||||
### Subsections
|
||||
|
||||
|
||||
|
||||
|
||||
Subsections add extra fields to existing form groups. They are small forms with a low to medium level of complexity. This interface location works best for extensions that add extra features that build off an existing Woo functionality.
|
||||
|
||||
|
|
@ -150,7 +150,7 @@ If you're developing an extension that allows merchants to upload 360 images or
|
|||
|
||||
### Sections
|
||||
|
||||
|
||||
|
||||
|
||||
Sections are significant parts of the form that may consist of multiple subsections and fields. They should be used sparsely throughout the form, so merchants are not overwhelmed with options while filling out the information about their products.
|
||||
|
||||
|
|
@ -178,7 +178,7 @@ If you're working on an extension that allows merchants to offer discounts based
|
|||
|
||||
### Top bar (header) *(future feature)*
|
||||
|
||||
|
||||
|
||||
|
||||
Top bar extensions offer supplementary experiences **not vital** to the critical product creation flows. They're secondary, meaning that they shouldn't contain information that may impact the product's overall quality or completeness.
|
||||
|
||||
|
|
@ -194,7 +194,7 @@ Depending on their roles, top bar extensions can be displayed in either a **popo
|
|||
|
||||
### Dialog extensions *(future feature)*
|
||||
|
||||
|
||||
|
||||
|
||||
Dialog extensions differ from other extensions as they are unrelated to any section or functionality within the product form. They can connect to third-party systems or come with complex interfaces that require a separate, focused experience.
|
||||
|
||||
|
|
|
|||
|
|
@ -81,11 +81,11 @@ Therefore, a PR could have testing instructions for multiple scenarios, in fact,
|
|||
|
||||
#### Example 1
|
||||
|
||||
|
||||
|
||||
|
||||
#### Example 2
|
||||
|
||||
|
||||
|
||||
|
||||
### Improving real testing instructions
|
||||
|
||||
|
|
@ -93,48 +93,48 @@ In this section, you will see some real examples of testing instructions that ha
|
|||
|
||||
Before:
|
||||
|
||||
|
||||
|
||||
|
||||
After:
|
||||
|
||||
|
||||
|
||||
|
||||
Improvements:
|
||||
|
||||
|
||||
|
||||
|
||||
Before:
|
||||
|
||||
|
||||
|
||||
|
||||
After:
|
||||
|
||||
|
||||
|
||||
|
||||
Improvements:
|
||||
|
||||
|
||||
|
||||
|
||||
Before:
|
||||
|
||||
|
||||
|
||||
|
||||
After:
|
||||
|
||||
|
||||
|
||||
|
||||
Improvements:
|
||||
|
||||
|
||||
|
||||
|
||||
Before:
|
||||
|
||||
|
||||
|
||||
|
||||
After:
|
||||
|
||||
|
||||
|
||||
|
||||
Improvements:
|
||||
|
||||
|
||||
|
||||
|
|
@ -43,7 +43,7 @@ Next, set up some orders to have sample data. Using WooCommerce > Settings > Cur
|
|||
|
||||
After doing so, check out WC-Admin to make sure the orders are showing up by going to `/wp-admin/admin.php?page=wc-admin&period=today&path=%2Fanalytics%2Forders&compare=previous_year`. Note that without any modification currency figures show according to what I have currently in WooCommerce settings, which is New Zealand Dollar in this case.
|
||||
|
||||
|
||||
|
||||
|
||||
We can confirm each order's currency by running the following query on the `wp_posts` table and joining `wp_postmeta` to gather currency meta values. Results show an order in NZD, USD, and MXN. This query is similar to the one we'll implement later in the guide to gather and display currency values.
|
||||
|
||||
|
|
@ -60,7 +60,7 @@ ORDER BY wp_posts.post_date DESC
|
|||
LIMIT 3
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
## Add a UI dropdown
|
||||
|
||||
|
|
@ -97,7 +97,7 @@ add_action( 'init', 'add_currency_settings' );
|
|||
|
||||
In the console, you can confirm the data has safely made its way to the client.
|
||||
|
||||
|
||||
|
||||
|
||||
In `index.js` create the custom currency filter and add it the Orders Report.
|
||||
|
||||
|
|
@ -128,7 +128,7 @@ addFilter(
|
|||
|
||||
If we check out the Orders Report, we can see our new dropdown. Play around with it and you'll notice the currency query parameter gets added to the url. If you check out the Network tab, you'll also see this value included in requests for data used to populate the report. For example, see the requests to orders stats endpoint, `/wp-json/wc-analytics/reports/orders/stats`. Next we'll use that query parameter to adjust report results.
|
||||
|
||||
|
||||
|
||||
|
||||
## Handle currency parameters on the server
|
||||
|
||||
|
|
@ -205,7 +205,7 @@ add_filter( 'woocommerce_analytics_clauses_select_orders_stats_interval', 'add_s
|
|||
|
||||
Lets head back to the Orders Report and see if it works. You can manipulate the dropdown and see the relevant order reflected in the table.
|
||||
|
||||
|
||||
|
||||
|
||||
## Finishing touches
|
||||
|
||||
|
|
@ -245,15 +245,15 @@ const addTableColumn = (reportTableData) => {
|
|||
addFilter("woocommerce_admin_report_table", "dev-blog-example", addTableColumn);
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
While adding a column is certainly helpful, currency figures in the table and chart only reflect the store currency.
|
||||
|
||||
|
||||
|
||||
|
||||
In order to change a Report's currency and number formatting, we can make use of the `woocommerce_admin_report_currency` JS hook. You can see the store's default sent to the client in `wcSettings.currency`, but we'll need to change these depending on the currency being viewed and designated by the query parameter `?currency=NZD`.
|
||||
|
||||
|
||||
|
||||
|
||||
First, lets create some configs in index.js.
|
||||
|
||||
|
|
@ -297,7 +297,7 @@ addFilter(
|
|||
|
||||
🎉 We can now view our Orders Report and see the currency reflected in monetary values throughout the report.
|
||||
|
||||
|
||||
|
||||
|
||||
## Conclusion
|
||||
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 50 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 154 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 53 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 12 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 126 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 133 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 50 KiB |
|
|
@ -8,7 +8,7 @@ The REST API is a powerful part of WooCommerce which lets you read and write var
|
|||
|
||||
In order to access the REST API using the standard endpoint URI structure (e.g. `wc/v3/products`), you must have your WordPress permalinks configured to something other than "Plain". Go to **Settings > Permalinks** and choose an option.
|
||||
|
||||
|
||||
|
||||
|
||||
## API reference
|
||||
|
||||
|
|
@ -32,7 +32,7 @@ To start using REST API, you first need to generate API keys.
|
|||
4. Click *Generate api key*.
|
||||
5. Your keys will be shown - do not close this tab yet, the secret will be hidden if you try to view the key again.
|
||||
|
||||
|
||||
|
||||
|
||||
## Make a basic request
|
||||
|
||||
|
|
@ -42,11 +42,11 @@ In Postman, you need to set the fields for request type, request URL, and the se
|
|||
|
||||
Once done, hit send and you'll see the JSON response from the API if all worked well. You should see something like this:
|
||||
|
||||
|
||||
|
||||
|
||||
Insomnia is almost identical to Postman; fill in the same fields and again use basic auth.
|
||||
|
||||
|
||||
|
||||
|
||||
Thats it! The API is working.
|
||||
|
||||
|
|
@ -58,15 +58,15 @@ If you have problems connecting, you may need to disable SSL verification - see
|
|||
|
||||
If you're having problems connecting to the REST API on your localhost and seeing errors like this:
|
||||
|
||||
|
||||
|
||||
|
||||
You need to disable SSL verification. In Postman you can find this in the settings:
|
||||
|
||||
|
||||
|
||||
|
||||
Insomnia also has this setting the preferences area:
|
||||
|
||||
|
||||
|
||||
|
||||
### 401 Unauthorized
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ Alternatively, you can select and use a different theme that already uses curren
|
|||
You need to determine what templates to update, make a backup of the old templates, and then restore any customizations.
|
||||
|
||||
1. Go to WooCommerce > Status > System Status. Scroll to the end of the page where there is a list of templates overridden by your theme/child theme and a warning message that they need to be updated. In the example below, the templates `form-pay.php` and `form-login.php` are outdated:
|
||||
|
||||
|
||||
2. Save a backup of the outdated template.
|
||||
3. Copy the default template from `wp-content/plugins/woocommerce/templates/[path-to-the-template]` and paste it in your theme folder found at `wp-content/themes/[path-to-theme]`.
|
||||
4. Open the template you pasted into the theme folder with a text editor, such as Sublime, Visual Code, BBEdit, Notepad++, and replicate any changes that you had to the previous template in your new, updated template file.
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ Use short but meaningful messages that communicate what is happening. Ensure tha
|
|||
|
||||
The placement of feedback is vital so the user notices it. For example, when validation messages are needed to prompt the user to enter data, get the user's attention by displaying a message close to the inputs where data needs to be revised.
|
||||
|
||||
|
||||
|
||||
|
||||
**Success** message: When the user performs an action that is executed successfully.
|
||||
|
||||
|
|
@ -32,4 +32,4 @@ The placement of feedback is vital so the user notices it. For example, when val
|
|||
|
||||
### Examples
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ Use the Task List and Inbox sparingly. Messages should be clear, concise, and ma
|
|||
|
||||
### Task List
|
||||
|
||||
|
||||
|
||||
|
||||
Anything that **requires** action should go in the task list.
|
||||
|
||||
|
|
@ -27,13 +27,13 @@ Anything that **requires** action should go in the task list.
|
|||
|
||||
Examples:
|
||||
|
||||
|
||||
|
||||
|
||||
### Inbox
|
||||
|
||||
The Inbox provides informational, useful, and supplemental content to the user, while important notices and setup tasks have their separate and relevant locations.
|
||||
|
||||
|
||||
|
||||
|
||||
- *What appears in the Inbox*:
|
||||
- Informational notices such as non-critical reminders.
|
||||
|
|
@ -47,4 +47,4 @@ The Inbox provides informational, useful, and supplemental content to the user,
|
|||
|
||||
Examples:
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 212 KiB |
|
|
@ -8,7 +8,7 @@ WooCommerce has its own robust system for logging, which can be used for debuggi
|
|||
|
||||
Depending on the log handler(s) used, you can view the entries created by the logger by going to **WooCommerce > Status > Logs**.
|
||||
|
||||
|
||||
|
||||
|
||||
## Log levels
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue