We don't have a solution for Sessions yet, we could still use predis for that if we wanted.

I think that may be required for WooCommerce support?

I have the original Whimsical doc if we want to change this but I don't think we really need to change the diagram itself. We should link the page though for sure.

For .well-known? It's not that commonly used for the stuff we're doing (I was implementing ActivityPub), so I'd say only the general docs are needed.

Fixes #139

IE is now gone, and Edge supports SSE, closing.

IE10, IE11 and Edge do not implement EventSource, hence the ServeSentEvents logger doesn't work in those browsers...and hence, those browsers can't be used for interactive imports.

IE is now gone, and Edge supports SSE, closing.

How to reproduce the issue?

1. I have create the page with Elementor.
2. Added the markup in widget like - <h3 class="elementor-heading-title elementor-size-default elementor-inline-editingpen " contenteditable="true "data-elementor-setting-key=.
3. I have exported the XML from - Tools > Export.
4. Trying to import it with the WordPress Importer v2.

It skip the page. Because the post meta is not unserialize. Line 1167

Sample page post meta while I have debugging.

{
    "id": "4b41ce4",
    "elType": "widget",
    "settings":
    {
    	"editor": "<h3 class="elementor-heading-title elementor-size-default elementor-inline-editingpen " contenteditable="true "data-elementor-setting-key="..

Quick Fix

I have used below filters to quick fix the issue and created this PR.

add_filter('wp_import_post_data_processed', function( $postdata, $data ) {
	return wp_slash( $postdata );
}, 99, 2 );

add_filter('wxr_importer.pre_process.post_meta', function( $meta_item, $post_id ) {
	return wp_slash( $meta_item );
}, 99, 2 );

Why this PR?

Because, If I imported the XML with the OLD WordPoress Importer it import the XML which DOES NOT imported with the NEW WordPoress Importer 2.

After debugging I found that the $postdata have not added wp_slash() which is added in old importer $postdata. It is missing from the $meta_item too. I have added both in this patch.

Thanks! Closing in favour of #174 for a best practice approach.

In content created with Gutenberg editor, some characters (used in block attribute) are encoded into unicode character codes that start with a backslash, e.g.

<!-- wp:plugin/custom-block {"data":"Some text and \u003ca href=\u0022https://example.com/\u0022\u003esome-link\u003c/a\u003e."} /-->

Before inserting into database, wp_insert_post() function runs the post object through wp_unslash() function which strips all backslashes. This breaks unicode character codes (and content). To mitigate that, we should run the post object through wp_slash() functions before passing it to wp_insert_post(). The original WordPress Importer does this.

Thanks! Closing in favour of #174 for a best practice approach.

Obsoletes #161 and #172.

Unlike the previous PRs, implements slashing as late as possible per best practice.

Update PHP 8 info

Merge pull request #473 from humanmade/backport-471-to-master

[Backport master] Update PHP 8 info

Backport #471.

Backport #471.

Update PHP 8 info

Merge pull request #471 from humanmade/php8

Update PHP 8 info

Brings this information into the current tense instead of future.

Problem

Cargo passes over features one-by-one in CARGO_FEATURE_... environment variables:

https://github.com/rust-lang/cargo/blob/524231f43f602a553216548a81e4ae22be8dd905/src/cargo/core/compiler/custom_build.rs#L224-L228

However, there's no way to get a list of all of these variables, without iterating over every environment variable.

I'd like to be able to display the list of enabled features in the version information, and right now that requires testing each variable (via #[cfg(feature=)]).

Proposed Solution

A new environment variable ala CARGO_FEATURES with a comma-separated list of enabled features would allow grabbing this information easily. (Comma-separated would match the --features flag to cargo)

Notes

One potential downside of this is that it adds redundant information, and might make it a bit worse for users invoking the toolchain directly without using the cargo tool specifically.

I'm replacing an existing gettext implementation which supports splitting strings across multiple mo files, and merging multiple catalogs together.

To support this, I've added Catalog::merge which accepts another Catalog, and which extends the strings with those of the other catalog.

Plural forms are allowed in gettext for negative numbers as well; the signature of ngettext et al is

char * ngettext (const char * msgid, const char * msgid_plural, unsigned long int n);

This PR changes Catalog::ngettext and Catalog::npgettext to accept a i64 instead of a u64 to match this behaviour.