Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add wporg/time block #414

Closed
wants to merge 12 commits into from
Closed

Conversation

adamwoodnz
Copy link
Contributor

@adamwoodnz adamwoodnz commented Jul 11, 2023

Closes #413

This PR reimplements the existing [time] shortcode as a Gutenberg format.

The block uses the Format API so that the time can be applied to a string within a parent block, eg. a paragraph.

Notable changes from the existing shortcode implementation:

  1. The reformatting is achieved by filtering and modifying the_content rather than the shortcode content
  2. The time parsing (parse_time) is separated from the dom manipulation (transform_time_blocks)
  3. The time parsing is always relative to the post date, there is no attribute support
  4. The frontend time_converter_script no longer has a jQuery dependency

Screenshots

Editor Frontend
Screenshot 2023-07-11 at 1 22 27 PM Screenshot 2023-07-11 at 5 44 40 PM

Testing

  1. Create a post, add various valid (eg. 'Tuesday, April 5th, at 15:00 UTC') and invalid datetime descriptions, and format as a Time using the option in the rich text toolbar
  2. Save and view on the frontend
  3. The date displayed should be reformatted to your timezone
  4. Test various styles
  5. Change the post date and check that the displayed time changes too
  6. Add multiple Times and check that the JS is only added to the page once
  7. Test cross browser and include Safari

@adamwoodnz adamwoodnz linked an issue Jul 11, 2023 that may be closed by this pull request
@adamwoodnz adamwoodnz self-assigned this Jul 11, 2023
@adamwoodnz adamwoodnz marked this pull request as draft July 11, 2023 01:07
@adamwoodnz adamwoodnz force-pushed the try/413-add-support-for-time-shortcode branch from 4cf22a5 to 357ef4e Compare July 11, 2023 01:13
@adamwoodnz adamwoodnz force-pushed the try/413-add-support-for-time-shortcode branch from 357ef4e to e6b167e Compare July 11, 2023 05:20
@adamwoodnz adamwoodnz force-pushed the try/413-add-support-for-time-shortcode branch from e6b167e to 93160a3 Compare July 11, 2023 05:23
@adamwoodnz adamwoodnz requested a review from ryelle July 11, 2023 05:48
@adamwoodnz adamwoodnz marked this pull request as ready for review July 11, 2023 05:48
Copy link
Contributor

@ryelle ryelle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is registering a block on the server, but the code in index.js doesn't actually create a block. While register_block_type works, it would be more correct to register the script a different way. You could try the method I used for showcase, which still uses the block.json and the generated index.asset.php.

Overall, the references to this being a block are not accurate - the parent folder & block.json are fine because those are necessary for the build process (much like the "style" block we use in the themes). For clarity though it would be best to update those references (like in the docs).

It looks like we never set up php linting on this project, but I see a few issues intime/index.php. You can run composer run lint mu-plugins/blocks/time to see them.

*/
function time_converter_script() {
?>
<script type="text/javascript" id="time_converter_script">
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add this on the frontend via a viewScript?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did try that with no success, I'll have another go

Copy link
Contributor Author

@adamwoodnz adamwoodnz Jul 17, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a viewScript entry but it isn't automatically enqueued. I've used something similar to the method you used for showcase for this also

Comment on lines 29 to 30
tagName: 'a',
className: 'wporg-time',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This creates a link that doesn't do anything — could you maybe use the time element instead? Use the PHP to add the datetime attribute, and then use that to build up the element in JS?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Comment on lines 57 to 59
$new_time_content = $dom->createElement( 'abbr', $time_content );
$new_time_content->setAttribute( 'class', 'wporg-time-date' );
$new_time_content->setAttribute( 'title', gmdate( 'c', $parsed_time ) );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you know if there has been any feedback on the accessibility of this abbr + title approach?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't, I'll ask

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I asked, feedback was that a time element would be better, and in particular the title on the abbr could be bad.

@ryelle
Copy link
Contributor

ryelle commented Jul 11, 2023

The time parsing is always relative to the post date, there is no attribute support

A quick search on make.w.org/core shows that they use the relative attribute often, so it would be good to think about how we could add support (maybe in the future).

@adamwoodnz adamwoodnz force-pushed the try/413-add-support-for-time-shortcode branch from 7e89b0d to 75d1963 Compare July 17, 2023 03:55

$metadata = get_metadata();
$time_converter_script_handle = register_block_script_handle( $metadata, 'viewScript', 0 );
wp_enqueue_script( $time_converter_script_handle, null, null, filemtime( __DIR__ . '/build/convert_times.js' ), true );
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added all the parameters so that it loads in the footer. Not sure of there is a better way.

}

$metadata = get_metadata();
$time_converter_script_handle = register_block_script_handle( $metadata, 'viewScript', 0 );
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couldn't find a nice way to register this script in init for better performance, and then only enqueue it here

@adamwoodnz
Copy link
Contributor Author

It looks like we never set up php linting on this project, but I see a few issues intime/index.php

After my MacOS upgrade to Ventura my php version went back to 8 and I had phpcs errors which blocked me seeing these in VSCode. Fixed now.

$dom = new \DOMDocument();

// Ignore warnings about htlm5 tags.
$dom->loadHTML( $content, LIBXML_NOERROR );
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Without this there can be many warnings displayed (nav, time, and many other html5 tags aren't supported).

Alternatively we could use regexp or a different dom parser...

@adamwoodnz
Copy link
Contributor Author

Feedback received elsewhere: it would be best to avoid filtering the_content on page view, especially if it involves loading a DOM parser.

Some possible solutions for this:

  • hook into the content save flow for php based DOM manipulation (probably a filter)
  • use php regexp to find and replace instead of DOM parsing
  • do all the parsing and DOM manipulation client side

@adamwoodnz
Copy link
Contributor Author

Alternative solution using client side parsing in #415

@adamwoodnz
Copy link
Contributor Author

Closing in favour of #415

@adamwoodnz adamwoodnz closed this Jul 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

Add support for [time] shortcode
3 participants