Skip to main content
 

Replied to a post on github.com :

Rich Embeds for silos like Twitter might actually be somewhat useful when using post kinds "like" and "repost" as the Twitter card would then display in the post in a nice visual fashion. The tougher question, however, is: Is the actual content of the Tweet being copied over as a blockquote with the full text (similar to what one would cut/paste from Twitter when clicking on their "embed" option within a Tweet) or is it using something like [embed]https://twitter.com/ChrisAldrich/status/707313378268618752 [/embed] which happens with the [IndieWeb Press This](https://github.com/pfefferle/wordpress-indieweb-press-this) plugin? If this is the case, then I imagine that if Twitter experienced a site-death then the proverbial "backup copy" of the plain text of the original liked/reposted tweet would be gone and the [embed] portion would be utterly useless thereafter, no?

Cross reference: http://techlifeweb.com/bookmarklets-for-indieweb-favorites-and-retweets/ and http://stream.boffosocko.com/2016/scott-i-love-the-concept-of-your-bookmarklets-and-how

 

Scott, I love the concept of your bookmarklets and how they work!! I particularly like the way that WP blockquotes the original and copies over the actual text of the tweet. Sadly after configuring it for use, when I cut and paste I don't get the actual tweet, but end up with a blockquote that literally reads "+document.title+" instead of the text of the tweet. I'm also using it in Chrome, but not sure what is going wrong that I'm seeing this quoted text instead of the actual tweet. Is there something else I need to configure?

I like the way your bookmarklet works compared to the https://github.com/pfefferle/wordpress-indieweb-press-this bookmarklets which work fine, but rather than do a full embed of the actual text in blockquote style, it puts in something like `[embed]https://twitter.com/ChrisAldrich/status/707313378268618752[/embed]` which WordPress then processes to display the tweet. I'd worry that if Twitter experienced a site death, that the content on my site would no longer show the original content of the tweet!

The third potential method of doing all this could be to use David Shanske's Post Kinds plugin https://github.com/dshanske/indieweb-post-kinds which provides the ability to create a bookmarklet that supports URL parameters using the URL http://www.YOURSITE.com/wp-admin/post-new.php?kind=like&kindurl=@url or http://www.YOURSITE.com/wp-admin/post-new.php?kind=repost&kindurl=@url where the variable "@url" is the permalink of the tweet. The post kind is then set appropriately as well as the referenced URL which then does the embed, but I suspect it's using the [embed] method, which again doesn't seem like it will work sustainably in a possible post-Twitter world.




 

Replied to a post on github.com :

Support Featured Image (and other common WordPress functionality) · Issue #24 · snarfed/wordpress-micropub https://github.com/snarfed/wordpress-micropub/issues/24

I'm not sure if it's something that would fit in here or quite how -- perhaps a setting toggle?, but for clients that push photos (OwnYourGram.com, https://ownyourcheckin.wirres.net/, Quill, et al), it would be nice on WordPress (especially for many modern themes) to have the (primary) photo from the client post as a "Featured Image" rather than in the main body of the post.

Other potential settings-based functionalities I can imagine being useful (based on experience with Twitter clients) include
* being able to set future posting times
* saving posts as draft, private, pending, etc. rather than automatically publishing
* allowing one to set Post Format (or if using the IndieWeb Post Kinds plugin: Post Kind)
Naturally supporting some of this would also depend on the posting client having support for these options as well.

 

@kraftbj already responded, but for completeness: also suggested here: http://stream.boffosocko.com/2016/this-is-hopefully-a-simple-but-useful-feature-requesti-appreciate
(This also relates to jetpack_allow_per_post_subscriptions for email and alternate posting methods to WP including via email and [micropub](https://github.com/snarfed/wordpress-micropub) with clients like [Quill](https://quill.p3k.io/)

Glad to know that JetPack is on GitHub :)

 

Congrats @raamdev for supporting microformats2 & better comments in @WordPress Independent Publisher theme https://github.com/raamdev/independent-publisher

 

For example, @WordPress might add microformats2 & schema.org options to encourage developers to fill those niches

 

Thinking about how @WordPress might drive development by adding additional categories to their Feature Filter https://wordpress.org/themes

 

Peter Woit's review of Sean Carroll's The Big Picture http://www.math.columbia.edu/~woit/wordpress/?p=8424

 

This is hopefully a simple, but useful feature request:
I appreciate that there's a filter for jetpack_allow_per_post_subscriptions, however it appears to only default to unchecked. It would be great if it could also be set (programattically or otherwise) to unchecked so that posts would always default to NOT be emailed to subscribers.

In my particular preferred use case, I'm using some advanced indiewebcamp.com related tools like micropub to allow services like Instagram (via OwnYourGram.com) and Foursquare/Swarm to post directly to my WordPress installation. In these cases, I'm posting with a remote service (perhaps similar to posting via email) and don't have access to the post interface to toggle the checkbox so that these posts don't automatically email subscribers. Conversely, when I'm using the direct posting interface, it's simple enough to toggle the checkbox manually.

To put it another way: Is there a way to add a line of code to the subscription filter [https://jetpack.com/support/subscriptions/#filters] so that the checkbox is both available AND it appears checked automatically?

For the same reason, if it doesn't already exist, it would also be nice to have the ability to toggle the checkboxes on the JetPack publicize feature as well. (If this already exists, then it's likely easy to borrow the code to accomplish the same thing for emailing subscribers).

Thanks to the entire team as always for a great product!

 

John Carlos Baez on Very Long Proofs | Azimuth https://johncarlosbaez.wordpress.com/2016/05/28/very-long-proofs

 

Congrats! That sounds awesome. I hope when you've got the Bridgy Publish tweaks fixed up, you'll try to push them back into the original as I know David is still working on them and they sound pretty useful.

I've recently been using "SNAP" https://wordpress.org/plugins/social-networks-auto-poster-facebook-twitter-g/ to syndicate out to most social networks (previously I'd been using a combination of Jetpack and manual). It adds a lot more fine tune ability about the where, when, and how of syndicating as well as allowing for re-syndicating. The Syndication Links plugin you mentioned also automatically sucks in the syndicated URL for display also.

 

WordPress › Support » Twenty Fourteen display error

I'd mentioned this <a href="https://wordpress.org/support/topic/live-preview-and-install-generally-borked?replies=1">error with Twenty Fourteen previously</a>, but just stumbled on the cause in case anyone else comes across it.

I'm not currently using Twenty Fourteen on any live sites, so <em>it's not a priority</em>, but so that everyone is aware, I'll mention that when using the standard WP Twenty Fourteen theme in conjunction with the <a href="https://github.com/pfefferle/wordpress-uf2/">uf2 plugin</a> to provide ad hoc microformats2 support (WordPress should really be more forward thinking and support mf2 out of the box), the display of the site is thrown out of whack and it only displays the left column and compacts the main content area into ~300px rather than the full ~900px. For those familiar the 3x2 grid of featured posts on the front page displays as a single 1x6 column instead, (akin to making it look like its outputting for a mobile platform rather than desktop).

I've used (and done tests with) several dozen other themes (including most of the WordPress default yearly themes) in conjunction with the uf2 plugin and haven't seen anything like this, which makes me confident that it's a small bug with the Twenty Fourteen theme rather than the plugin.

Based on what uf2 does, my strong suspicion is that the additional microformat classes that are thrown into the Twenty Fourteen theme are conflicting with the base CSS. This means that 2014 is likely going overboard and not differentiating well between classes used strictly for theming and classes which are solely meant to be used for semantic markup.

 

Replied to a post on github.com :

Theme display issue with Twenty Fourteen · Issue #15 · pfefferle/wordpress-uf2

I'm not currently using it, so it's not a priority (and it may not be uf2s fault based on my brief tests), but so everyone is aware, I'll mention that when using the standard WP Twenty Fourteen theme in conjunction with uf2, the display of the site is thrown out of whack and it only displays the left column and compacts the main content area into ~300px rather than the full ~900px. For those familiar the 3x2 grid of featured posts on the front page displays as a single 1x6 column instead, (akin to making it look like its outputting for a mobile platform rather than desktop).

I've used several dozen other themes (including most of the WordPress default yearly themes) in conjunction with uf2 and haven't seen anything like this, which makes me think it's a bug with the Twenty Fourteen theme.

I'll crosspost this to WP.org so they're aware too.

 

Replied to a post on github.com :

About/FAQ missing reference to webmention-endpoint? · Issue #673 · snarfed/bridgy

I'm always a fan of instructions being built intuitively into the UI flow, to guide new users along, especially if they have a solid idea of what they're getting into in the first place. In this particular instance, the reference to the HTML was a tad too nebulous and may confuse many -- especially those who begin reading rather than jumping right in.

Shortly the indieweb will be so big that totally tyro users with no facility with code will be on the doorstep and will need better explanations/instructions. Perhaps I'll take some time in the coming months to put together simple walk thrus for the handful of major platforms? If you think it's worthwhile, can you let me know, based on the current userbase (or even recent growth in the past 6months-year), how you'd rank them in order of priority so we can help the biggest groups first? Or perhaps it's worth starting at the lowest hurdle for the least technical users (Tumblr/Blogger?) and building toward the more technical (WordPress.com)? (I'd presume most above this level are okay with most of what exists now).

I'm presuming that Brid.gy was originally meant as a "code" bridge to connect activity on silos, but I can also see it as taking on a secondary meaning in providing the initial value and impetus to bridge users into to the bigger IndieWeb movement.

 

Replied to a post on github.com :

About/FAQ missing reference to webmention-endpoint? · Issue #673 · snarfed/bridgy

In the FAQ https://brid.gy/about#endpoint there's a line about "Why do I have to add that line of HTML to my blog?"

Am I now missing it or did the actual line of HTML that's being referred to disappear from the page in an update?

I'm presuming it's referring to:
&lt;link href="http://yourwebsite.host/webmention-endpoint" rel="webmention" /&gt; or on WordPress
&lt;a rel="webmention" href="https://www.brid.gy/webmention/wordpress"&gt;&lt;/a&gt;

I think the brid.gy interface prompts the user to include such a line when signing up for service, but it may also make sense to mention it on this page in this section somewhere for completeness? It could certainly be referenced here for those reading the "about" page prior to actually attempting to set things up.