DEV Community: Prateek Saxena

How to find date and time in text?

Prateek Saxena — Mon, 04 Jan 2021 12:54:52 +0000

Date and time, and other named entities can be extracted from a document using winkNLP. To do this, we’ll load a document and ask for its entities. We’ll then filter down to just the ones we need. If we want to get the Unix time from the text we can look at the shape and check if the text can directly be sent to the Date object to be parsed. Here is how we would find the date and time entities in a text using winkNLP:

// Load wink-nlp package & helpers.
const winkNLP = require( 'wink-nlp' );
const its = require( 'wink-nlp/src/its.js' );
const model = require( 'wink-eng-lite-model' );
const nlp = winkNLP( model );

const text = `The release happened on 21 August 2020 at 4:32 pm`;
var doc = nlp.readDoc(text);

doc.entities().filter( e => {
  if ( e.out( its.type ) === 'DATE' ) {
    console.log( e.out(), new Date( e.out() ) );
    // -> 21 August 2020
    // -> Fri Aug 21 2020 00:00:00 GMT+0530 (India Standard Time)
  }

  if ( e.out( its.type ) === 'TIME' ) {
    console.log( 'Time:', e.out() );
    // -> Time:
    // -> 4:32pm
  }
});

This would give you all the strings that contain dates or times, and the Unix time corresponding to it if the format allows it. You can now use the usual JavaScript functions like sort on this data structure to get the insights you need. For example our Wikipedia Timeline showcase uses it to create visualizations of articles.

Raw texts may contain many named entities like time, money, and hashtags. The English language lite model for winkNLP finds entities spanning multiple tokens by employing pre-trained finite state machine.

Todo applications that automatically add due dates based on the text that was entered, or email clients that add events to your calendar based on time and location do this by using this form of named entity extraction. It can also be used to create a timeline of events based on raw text.

Using gitattributes to make releasing WordPress themes easier

Prateek Saxena — Fri, 24 Jul 2020 12:01:10 +0000

Zuari releases have been few and far apart in the last year. While I work on Zuari often, I cut a release only when I know I’ll have time to fix things in case they break for someone. This has meant that I haven’t paid much thought to the release process. Till now, I would create a copy of the directory, go through my list of files to delete, delete them and create an archive to upload to WordPress.org. As you can see this process is manual and error prone.

While looking at David’s syndication-links repository I saw a .gitattributes file. I had seen it before but never looked into it. Turns out, that among other things, you can use it to define a list of files to ignore when creating a git archive!

So, I setup the following .gitattributes file for my WordPress themes:

# Git
.gitignore export-ignore
.gitattributes export-ignore

# Styles
.sass-cache export-ignore
*.css.map export-ignore
**/*.scss export-ignore
.stylelintrc.json export-ignore

# Scripts
Gruntfile.js export-ignore
package.json export-ignore
package-lock.json export-ignore
node_modules export-ignore
.storybook export-ignore
.babelrc export-ignore

# Github
README.md export-ignore
.github export-ignore

# Composer
composer.json export-ignore
composer.lock export-ignore
vendor export-ignore
phpcs.xml.dist export-ignore

And now, to create the zip file for uploading on WordPress.org I simply run:

git archive master -o theme-name.zip

No more manual work, no more slips and mistakes.

Releasing a theme (or any other package for that matter) requires quite a few steps. And if you don’t release often it’s easy to forget and miss something. For this reason, the most important thing in Zuari’s otherwise inadequate README are the release steps. Documentation is as important for our future-selves as it is for others.

Cover photo by Catarina Carvalho on Unsplash
This post was originally published at prtksxna.com.

Gutenberg editor color palettes for WordPress themes

Prateek Saxena — Fri, 26 Jun 2020 09:11:25 +0000

One of my favorite features of the Gutenberg block editor is the editor color palette. It allows themes to register a color palette that is shown in the block editor whenever a block needs to choose a color.

Allowing the theme to have a say in the styling of the content of the post is a powerful idea. It helps guide the user’s design choices while still allowing them freedom to make changes. When working on Zuari, it was important for me to get this right since the theme is otherwise just black and gray.

Once we have the colors picked and named (This can be tricky. What is ecru?) we need to let WordPress know that our theme would like to register a palette, and add our colors to it:

add_theme_support( 'editor-color-palette', array(
            array(
                'name' => __('Brick', 'zuari'),
                'slug' => 'brick',
                'color' => '#825A58'
            ),
            array(
                'name' => __('Baby Pink', 'zuari'),
                'slug' => 'baby-pink',
                'color' => '#E0BAC0'
            ),
            array(
                'name' => __('Ecru', 'zuari'),
                'slug' => 'ecru',
                'color' => '#E1D9D3'
            )
) );

Next, we’ll need to add two CSS classes for each of these colors so that they can be used on the different blocks as background and foreground colors. The naming convention for these classes is has-{slug}-color and has-{slug}-background-color:

.has-brick-color { color: #825a58; }
.has-baby-pink-color { color: #e0bac0; }
.has-ecru-color { color: #e1d9d3; }

.has-brick-background-color { background-color: #825a58; }
.has-baby-pink-background-color { background-color: #e0bac0; }
.has-ecru-background-color { background-color: #e1d9d3; }

That’s it! This will add the color palette to the block inspector for any blocks that need color, and show the right colors in the website once they’re selected.

I hope that WordPress adds these colors as options in the Customizer panels as well, allowing for more design guidance coming from the theme. I’ve been thinking about WordPress themes as design patterns and guidelines rather than skeletons for a website. I’ll be writing about this soon.

Cover image by Carisse Weiser on Unsplash

This post was originally published on prtksxna.com

Setting up WordPress’s PHP coding standards for your theme

Prateek Saxena — Fri, 05 Jun 2020 12:28:06 +0000

Setting up coding standards for your project is always a good idea. While it is ideal to start with one from the beginning, sometimes you have to do it after you’ve already written quite a bit of code (looks at Zuari 👀). Here is a quick guide on setting up the WordPress PHP Coding Standards for your theme or plugin:

For the purpose of this guide you’d need PHP and Composer installed locally, even if you are using docker for local development. We start by running composer init. This sets up the composer.json file and adds it to .gitignore. Next to get the phpcs and the WordPress coding standards, we run:

composer require squizlabs/php_codesniffer --dev
composer require wp-coding-standards/wpcs --dev
composer require dealerdirect/phpcodesniffer-composer-installer --dev
composer require phpcompatibility/php-compatibility --dev

Now, to make sure that things are set up correctly on a fresh install we’ll create scripts that’ll run automatically post install. You can read more about this in the PHP_CodeSniffer standards composer installer plugin documentation. We’ll also add a script to actually run phpcs from inside of ./vendor/bin, this will serve as a shorthand when we need it later. So in composer.json we’ll add a new key called scripts:

"scripts": {
  "lint": "phpcs",
  "install-codestandards": ["Dealerdirect\\Composer\\Plugin\\Installers\\PHPCodeSniffer\\Plugin::run"],
  "post-install-cmd": [
    "@install-codestandards"
  ]
}

If we try to run composer run-script lint now it will start showing us a ton of linting errors. These might be a bit more than we actually need to resolve though, and that is because we haven’t yet defined which coding standard we’ll be following. To do this we’ll create a phpcs.xml.dist file and copy over the contents from the sample config file that the WordPress Coding Standards provides:

<?xml version="1.0"?>
<ruleset xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Your Project" xsi:noNamespaceSchemaLocation="https://raw.githubusercontent.com/squizlabs/PHP_CodeSniffer/master/phpcs.xsd">
    <description>A custom set of rules to check for a WPized WordPress project</description>
    <exclude-pattern>/docroot/wp-admin/*</exclude-pattern>
    <exclude-pattern>/docroot/wp-includes/*</exclude-pattern>
    <exclude-pattern>/docroot/wp-*.php</exclude-pattern>
    <exclude-pattern>/docroot/index.php</exclude-pattern>
    <exclude-pattern>/docroot/xmlrpc.php</exclude-pattern>
    <exclude-pattern>/docroot/wp-content/plugins/*</exclude-pattern>
    <exclude-pattern>/vendor/*</exclude-pattern>
    <exclude-pattern>/node_modules/*</exclude-pattern>
    <exclude-pattern>*.min.js</exclude-pattern>

    <rule ref="WordPress-Docs"/>
    <rule ref="Generic.CodeAnalysis.UnusedFunctionParameter"/>
    <rule ref="Generic.Commenting.Todo"/>

    <config name="minimum_supported_wp_version" value="4.9"/>
    <rule ref="WordPress.WP.I18n">
        <properties>
        <property name="text_domain" type="array">
        <element value="my-textdomain"/>
        </property>
        </properties>
    </rule>

    <rule ref="WordPress.NamingConventions.PrefixAllGlobals">
        <properties>
        <property name="prefixes" type="array">
        <element value="my_prefix"/>
        </property>
        </properties>
    </rule>

</ruleset>

Now we just need to make some adjustments to this file based on our theme and preferences. Look at the exclude-patterns, is there anything else that we should be excluding? Next, let’s make sure that the minimum_supported_wp_version is set correctly. Finally, we’ll fix the prefixes and text_domain to use your theme name. Make sure you use “-” for the text_domain and “_” for the prefixes.

And that’s it 🎉 You should be ready to go! Running composer lint will show you all the places where you aren’t following WordPress’s coding standards. Take some time to clean up all the errors and warnings and ignore the ones that you think aren’t appropriate. Marvel at your clean and beautiful code 😍

The only thing left to do is to make sure that things stay nice and clean over time. Atom has a package to see linting issues in the editor itself, and you can find and set one up for the editor of your choice. I would like to set this up on CI too, making sure something is looking at these errors even when I am not.

(Photo by Anas Alshanti on Unsplash)