codesign2 / gutenberg-shortcode-preview-block Goto Github PK

README.md instructions for building are now incorrect.

Affects #1

The project filesystem structure makes it non-obvious to work with. composer install works on root, but you have to be in the src folder to npm install. Building also requires / makes use of block lists and globs instead of a build folder for output.

• composer install and npm install from repo folder
• dedicated build process
• non-runtime assets organised around root of project
  • media
  • storybook
• investigate separating jest tests

More than the two people mentioned were in 4710 PR on Gutenberg repo. It'd be nice if they left a comment with their WordPress.org username and GitHub username.

Also it'd be nice to find a prominent way to display that information to repo users. This is a repack of derivative works done that would not be possible without Gutenberg, WordPress and all involved in 4710. Specifically @niranjan-uma-shankar @aduth @notnownikki @youknowriad @ehd @westonruter

Do you think you will be able to update this for WP5.0? One issue I spotted is that withInstanceId is no longer in wp-components, it's moved to wp-compose.

Some themes or plugins (looking at you Envato), cause arbitrary HTML in the header and footer and it bleeds into the sandboxed iframe...

Where possible, just test your themes and plugins and then fix (if necessary, then in a child-theme)

Whilst it is possible to strip incoming HTML tags not whitelisted, it seems a waste of time and effort for me (by all means PR something that handles this).

Whitelisted items

• <script> tags
• <link> tags
• <meta> tags
• <style> tags

Anything else is likely noise.

What documentation would be good for this?

It seems pretty intuitive but would be nice to meet needs of users.

I'm getting this error using WordPress 4.9.6 RC1 on a localhost install:

filemtime(): stat failed for C:\Users\webma\Downloads\Websites\WordPress\wordpress-4.9.6-RC1\wordpress\wp-content\plugins\gutenberg-shortcode-preview-block-master/block.build.js | 1 | wp-content/plugins/gutenberg-shortcode-preview-block-master/index.php:30

Thanks for this, it's really timely, I've done some limited testing and it seems to work well. One suggestion though is that you might like to create it using a RichText block. I've two reasons for this:

1. Some plugins (mine - BP Profile Shortcodes Extra, for example) add a tinyMCE menu item to insert their shortcode, so having richtext would allow users to select those shortcodes from the richtext menu.
2. Some shortcodes are designed to be inserted in the middle of sentences, to display (in my own case) for example the username of the person viewing the post.

Adding this to travis might be a good start

cache:
  directories:
    - vendor
    - src/node_modules

Would be nice to take the time to ensure code meets WP coding standards, passes same tests as the new-shoes branch it was forked from.

PHP tests & JS tests needed

Arbitrary HTML could be removed frontend before sending to sandbox by creating a fragment from the css and js segments and disallowing any visible content.

This would make the plugin compatible with a wider range of themes and plugins, assisting in reducing the prevalence of themes and plugins in #7

1. Upon successful response body
2. Create a fragment with a wrapper element we can address from (reduces false positives from nested elements)
3. create iterable discover list querySelectorAll within the fragment using wrapper as namespace with only direct decedents on any non script, link, style, template (block visible elements)
4. remove all these direct descendents
5. get innerHTML of the fragment wrapper
6. send this to sandbox

Technically this means after receiving a response, parsing and modifying that response.

The reason I think this is best done Frontend is because it has a Real DOM to work with avoiding PHP, libxml and other parsing framework issues.

Drawbacks are additional complexity and iteration.

I've tested this without Gutenberg, it doesn't seem to damage anything. However it would be nice to warn users and link to the gutenberg plugin (if possible in a way that it can be installed and activated)