Validate submitted patterns about pattern-directory

[dingo-d]

My 2 cents: If you want to have a fast validation that doesn't depend on a human being since that's slow (coming from experience with theme reviews), why not explore the option to implement machine learning algorithms for Offensive language or images?

It's not like these aren't out there (link, link (archived), link). I'm sure there are people who would be up to the task of using some of these and programing some kind of validation tool that would speed up the process.

[dd32]

It's still on my list, but I don't have anything to show for it right now..

[carolinan]

Some of the points here aligns closely with the need to validate the block markup of full site editing themes when they are submitted to the directory.

[ryelle]

I started some validation in #38, pulling out my comments so they're not lost in the PR:

Does it contain JS or inline CSS?
These should be stripped out by wp_kses for users, but we'll want to check that when we figure out permissions in general, #30

Is the markup minimally valid?
I'm not sure if we need to check for this - on the frontend, any content generated by the editor should be valid. But in PHP, GB's parser is very forgiving. So "invalid" code, ex: <pThis is content, passes as a valid paragraph via the API. When that's rendered in the frontend, it triggers the invalid content warning, so anyone looking at the block would know it's broken. Checking for this would probably require something like the block directory e2e tests.

[tellyworth]

As an alternative to e2e for markup validation, could we use kses? Create an API endpoint that basically just runs a specially configured kses and returns the sanitized output. That's not the same as validation obviously but it might eliminate the need to validate.

[ryelle]

The content should already be run through kses by core, and if we set up our own kses rules we would need to keep track of what features GB adds, in case they add support for a new attribute or something, we could unexpectedly invalidate blocks. If someone manages to save invalid HTML, it would be obvious to anyone searching the pattern directory, because the preview would be broken.

Is there a case you're thinking of where we'd want this extra sanitization?

[shaunandrews]

I think we might want to consider restricting the use of images in the pattern builder. Perhaps seeding the media library with a number of worry-free images, remove permissions to upload to the media library, and including some validation around hot linking to un-allowed images.

[ryelle]

I think the only remaining task here is to add an Akismet check over the pattern content for spam. We'll be relying on community reporting for standards checking and other issues under the "Last" list.

[ryelle]

@dd32 Are you able to look into adding a spam check step to the pattern validation?

[ryelle]

Closing this issue now that Akismet is spam-checking patterns (#406). If, as patterns are submitted, we realize we need more checks, we can create new specific issues for that.