parsely / wp-parsely Goto Github PK

@arhine got a request about this recently

We're more than a little bit text heavy on the settings page. Much of the information is good, but we don't need it in everyone's faces all the time and some of the copy is probably too verbose. We should migrate to using something like https://jqueryui.com/tooltip/ to show information on demand maybe.

We frequently encourage publishers who face consistent discrepancies to move our tracking code closer to GA (or similar). They can modify this in their WP instance, but every new release would undo it.

Can we please make it an option to keep this (and other) modifications?

It would be super handy if we could filter $parselyPage right before output. I'm specifically interested in being able to add the metadata field outlined here https://www.parsely.com/help/integration/jsonld/ but a general filter would be ok by me.

WordPress actually has an example using Parse.ly of how to hook into their amp_post_template_analytics filter: https://github.com/Automattic/amp-wp/blob/master/readme.md#analytics

cc: @hbbtstar

More context from them:

"You could pretty easily integrate this into the existing Parsely plugin to make it even more seamless for both VIP and self-hosted users (warning: code is untested)":

add_action( 'pre_amp_render_post', 'parsely_amp_add_actions' );
function parsely_add_amp_actions() {
    add_filter( 'amp_post_template_analytics', 'parsely_amp_add_analytics' );
}

function parsely_amp_add_analytics( $analytics ) {
    global $parsely;
    $parsely_options = $parsely->get_options();

    if ( empty( $parsely_options['apikey'] ) ) {
        return $analytics;
    }

    $analytics['wp-parsely'] = array(
        'type' => 'parsely',
        'attributes' => array(),
        'config_data' => array(
            'vars' => array(
                'apikey' => $parsely_options['apikey'],
            )
        ),
    );

    return $analytics;
}

The WordPress recommendations widget currently comes in a vertical flavor, good for sidebars.

Might we get a horizontal version, something that could be used on index pages and at the bottom of article columns, similar to the Outbrains and Taboolas of the world?

Currently, when implemented, the Parse.ly tracker is set for all post types in the publisher's database. A user has suggested that we allow users to whitelist custom post types.

As the user noted, "If you have a site with multiple post types, you probably only want analytics on one or two."

Parse.ly customers have the ability to display personalized or contextual content recommendations on their site with the Parse.ly API. We should enable this maybe via a sidebar widget?

From the 2018-05-02 WordPress VIP feedback:

I noticed a number of escaped static strings. Escaping is unnecessary for hardcoded strings, e.g.:

echo 'hello'; // this does not need escaping
echo esc_html( 'hello' ); // not a blocker, but unnecessary

It's only when variables are used that escaping is required. Static hardcoded primitives are fine.

I couldn't find any examples of this. @jtotoole or @richeymichael do you see what the referrer is talking about?

As an author/admin of a WordPress blog, I'd like to be able to easily add a widget to my blog that shows the top posts so that users can easily see popular content and (hopefully) remain on my site.

I'd be able to configure this widget to limit to a specific time range and style it to my needs.

Got this email today -- new WordPress version comes out August 16th, so I guess we can test locally at that point and then update our ReadME? The field guide they link to will be a solid resource to peruse to gauge whether there are any changes that could affect this plugin.

WordPress 4.6 is scheduled to be released on 16 August 2016. Are your plugins ready?

After testing your plugins and ensuring compatibility, it only takes a few moments to change the readme "Tested up to:" value to 4.6. This information provides peace of mind to users and helps encourage them to update to the latest version.

Here are the current "Tested up to:" values for each of your plugins:

• https://wordpress.org/plugins/wp-parsely/ (tested up to 4.5)

For each plugin that is compatible, you don't need to release a new version -- just change the stable version's readme value.

Looking to get more familiar with 4.6? Read this roundup post on the core development blog to check out the changes made to register_meta(), native fonts, persistent comment cache, Customizer APIs, WP_HTTP API, and much, much more: https://make.wordpress.org/core/2016/07/26/wordpress-4-6-field-guide/

Should look similar to:

We've gotten reports that we aren't fetching author name properly in parsely-page values. Need to revisit the logic there and ensure we're pulling author name correctly.

Some users have reported that the admin WordPress toolbar will not show unless Track Logged-in Users is set to Yes.

If a post has a the following tags: ['something', '"another thing"'], it'll be converted to:

{
  ...
  "tags": ""another thing"",
  ...
}

which Parse.ly crawlers read as "tags": ""another thing"" which is invalid JSON.

We should follow escaping instructions outlined here until we move to JSON-LD.

A Parse.ly customer asked if we could use "channels" for parsely-page sections. I'm currently unfamiliar with channels, but sounds like something we should investigate.

Per Wordpress:

"We've added a couple of compat layers into the FBIA plugin for some common plugins, but we can also do this outside of the plugin. That'd probably be better for you, as you can maintain that code yourselves without relying on us and it can sit alongside the AMP integration.

The Google Analytics code is a good example: https://github.com/Automattic/facebook-instant-articles-wp/blob/master/compat/class-instant-articles-google-analytics-for-wordpress.php

In the Parse.ly plugin, you could add a class with a similar structure.

The key bit is to hook into instant_articles_compat_registry_analytics to register your compatibility layer with the FBIA plugin.

Then, get_raw_embed_code() simply returns the HTML. This HTML is then put through the Facebook Instant Article SDK to produce FBIA-compatible markup.

In the GA example you can see that get_raw_embed_code() goes elsewhere to fetch the code, but you can do that however works best for you."

Parse.ly recently introduced multiple author support via parsely-meta, the plugin should support this at the same time we look at our author grabbing logic in #13.

On vanilla WP installs, the WebPage JSON is not schema compliant according to Google's structured data tool. We should make sure that all the JSON the plugin outputs has no errors in the structured data tool, for index pages or for post pages.

Noticed on the printCheckboxTag() function some logic for getting checked values. You can get some more concise code using the checked function.

http://codex.wordpress.org/Function_Reference/checked

The New Yorker is using our WP Plugin and have recently run into an issue where some posts are not surfacing in the dashboard. Upon inspection, these posts are being discarded due to improperly escaped quotes. However, the quotes that are not properly escaped are the unicode equivalent of a double quote. ( " )

I've copied a few of the missing posts below:

http://www.newyorker.com/tech/elements/holocene-anthropocene-human-epoch

http://www.newyorker.com/culture/cultural-comment/possessed-james-brown-eighteen-minutes

http://www.newyorker.com/culture/cultural-comment/invisibilia-evolving-art-radio

In the first URL above, here is the part of the metadata tag that is breaking the tag.

tags; magazine","anthropocene","extinction","fossils","geologists","geology","holocene","jan zalasiewicz","nuclear weapons","stratigraphy","the european discovery of america","post_type: post"]}'

The first of the above tags has the unicode double quote and it is not escaped. Do we need to apply a change to our WP plugin? Or is this something that is happening on the New Yorker's end?

In wp-parsely.php, the fallback if a post doesn't have a featured image is just "" (set here).

Since a lot of blogs don't set featured images, has_post_thumbnail() will return false a lot. It looks like a lot of people work around this by searching for the first image in the blog post using this code: https://css-tricks.com/snippets/wordpress/get-the-first-image-from-a-post/

^thx @meniltiac!

We could use a more extended explanation that includes how to set up the callback that needs to be passed when you add the filter

for better branding and legitimacy

@jtotoole

Look at adding unit/integration testing via WP-CLI and VIP Quickstart

see here for details on the publish_post action hook:

https://codex.wordpress.org/Plugin_API/Action_Reference/publish_post

Lack of logo field throws validation error.

Similar thread in amp-wp. ampproject/amp-wp#552

Port 443 is default for https, the same as 80 for http.

In the line here: https://github.com/Parsely/wp-parsely/blob/master/wp-parsely.php#L861

Can we have:
if ( $_SERVER['SERVER_PORT'] != '80' || $_SERVER['SERVER_PORT'] != '443' ) {

Thanks.

Not 100% sure if I wanna do this as the Parse.ly Analytics Extension currently provides a better experience, but it may still make some sense for a tighter integration into the publishing workflow.

Some publishers want to use the plugin only for metadata, and use Tealium / Segment or other tag managers to manage the JS. There should be an option in settings to use our plugin just for metadata and not for JS

Once this is implemented we can roll back the changes made in this PR: #36

From 2018-05-02 VIP review:

the main plugin file and class Parsely is 1300 lines long, which is rather large. For future reviews it would reduce churn to break this into smaller files.

See proposal in #83

Example validation error.

wpcom-vip_get_term_by is the cached version of get_term_by, though it's not part of the Wordpress core. We should make a new function to check for the existence of the former before falling back to the latter. That would look something like:

public function parsely_get_term_by(args) {
    if( function_exists('wpcom_vip_get_term_by') ) {
        wpcom_vip_get_term_by(args);
    } else {
       get_term_by(args);
    }
}

Lines to be changed:
https://github.com/Parsely/wp-parsely/blob/master/wp-parsely.php#L670
https://github.com/Parsely/wp-parsely/blob/master/wp-parsely.php#L672
https://github.com/Parsely/wp-parsely/blob/master/wp-parsely.php#L700
https://github.com/Parsely/wp-parsely/blob/master/wp-parsely.php#L707

Some publishers use custom variables instead of Section; unfortunately this means that their "section" keys are null when passed as is through the wp plugin.

Could we add a feature kind of like "use sections as tags" that allows publishers to specify what field they're using as their section?

We can clean up some of the complex logic for "clean parsely-page values" by moving over to Parse.ly's new support of JSON-LD.

• http://www.parsely.com/docs/integration/metadata/jsonld.html
• http://json-ld.org/

Main benefit is that we no longer have to worry about escaping of quotes inside of these documents.

To encourage a wider range of users to contribute to wp-parsely, we should develop and maintain a roadmap document hosted here on github that allows users to understand various ways they can contribute to the future of the plugin.

I'll put forward some initial ideas, but will look to others to improve on / curate the list.

Assuming that a customer follows the standard wp/fbia instructions here: https://developers.facebook.com/docs/instant-articles/wordpress-quickstart

It seems at least potentially possible for us to add the tracking tag to the template and verify the canonical.

Once we do so (smoke test with Elevated Today should suffice), we just need to change the stable version's readme.txt value.

When I have debug mode turned on in WordPress, I get a notice saying "Strict standards: Redefining already defined constructor for class Parsely in .../wp-parsely.php on line 64".

This creates a headers already sent notice right after causing my site to stop loading. The only way around is to disable debug mode which the results in bugs in my code because I can't receive errors and the like.

Any idea of what the fix is exactly?

Since Parsely groups on canonical URL, canonical URL needs to stay the same whether it's http or https.

These two URLs are the same post:

https://blog.parsely.com/post/3827/readers-feeling-bern/
http://blog.parsely.com/post/3827/readers-feeling-bern/

but because of the logic in get_current_url one has a canonical of https and the other http so they get duplicated. Need to resolve that so it stays stable (either http or https).