Installed the short profile plugin for Known to shorten my profile page
https:/
Updated the plugin that allows me to post from my own website to Mastodon.
https:/
Support for Read posts? (Core or Plugin?) · Issue #1703 · idno/Known https:/
From what I can tell the current master version now supports bookmarks, likes, replies, and reposts from within the core "Like" plugin while earlier versions (0.9.2 and prior) would require the KnownReactions plugin to support all of these.
I was considering making a "Read" plugin to better differentiate (from bookmarks) as posts which I've actually read the content of. To most users bookmark implies one will come back to and read something at a later date.
In an educational setting, I can see it would be useful to be able to indicate implicitly that one has actually read a particular article/assignment/other along with a field of notes one may have taken on the assignment--very similar to a current bookmark post, but with a slightly different connotation and slightly different mf2 markup (u-read-of perhaps?)
I'm happy to take a shot at a PR the the core "Like" plugin since it appears that it'd only need a handful of lines of code (and would be a bit more DRY than yet another full blown plugin especially for the portion of the tabbed UI which allows one to easily switch between the multiple types after starting a post), but thought I'd see what the thoughts were with regard to core since the company version has an academic focus which this would certainly dovetail with well.
In a similar vein, I could also imagine Watch and Listen post types as well. I'll note that there's already a more entertainment focused version of a plugin called `[Known-Watching](https:/
Cross-posting this to the Google Group as well.
Thrilled to be able to POSSE posts from @WithKnown to Mastodon now courtesy of @nxd4n using https:/
Replies not working · Issue #4 · dg01d/KnownPnut https:/
When trying to reply to a pnut post and syndicating to pnut, the post not only doesn't thread, but doesn't even post to pnut, nor does it return the permalink of the post.
Example:
Original: http:/
Manual POSSE: https:/
New silo: pnut.io · Issue #736 · snarfed/bridgy https:/
@dg01d has created a [Known plugin](https:/
He and @jeremycherfas were chatting on https:/
Instructions for adding a new silo: https:/
Testing the ability to POSSE posts to pnut.io via @WithKnown courtesy of @dgold.
#client71 https:/
UX/UI Suggestion: Meta box in the admin UI with PressForward metadata and comments · Issue #902 · PressForward/pressforward https:/
I'd suggest that it would be worthwhile and convenient to have a meta box in the admin UI for editing the final draft that contained all of the pre-existing PressForward metadata.
Bits and pieces of it appear in other portions of the PressForward UI throughout the vetting (reading, nominating) process (typically hidden under the "info" button which pops up the details), but having portions of it while actually editing the draft of the post would be very handy/useful. In particular, it would be nice to have access to the comments which are added to the particular piece in the earlier parts of the process.
Example instance · Issue #1 · terminalpixel/postrchildbot https:/
You should add a readme page with a link to the working instance http:/
Congrats on this btw!
Bookmarklet chopping out NYTimes text · Issue #900 · PressForward/pressforward https:/
When nominating/drafting from NYTimes stories, typically the first several graphs are excised or not copied over into the post.
Based on some quick experiments it appears that the portion of stories that appears before </div><!-- close story-body --> (typically followed by some advertising before the story resumes) are the ones being left out for some reason. From the bookmarklet's point of view NYT articles seem to begin with the portion <p id="story-continues-2" class="story-body-text story-content" rather than the true start of the article.
Given that the Mercury browser plugin doesn't exhibit this behavior, I suspect it's something to do with the bookmarklet's JS?
This is occurring in 4.2.2 and earlier versions of the bookmarklet. I'm seeing it in Chrome as well as Firefox, so it doesn't seem to be browser dependent.
If pre-highlighting text in the browser, one does get the typical blockquoted portion of a Press This bookmarklet output.
Old posts with no value set for `pf_forward_to_origin` are automatically forwarded · Issue #899 · PressForward/pressforward https:/
This has probably been present for a while, but I just noticed after turning on forwarding posts to the canonical URL by setting a time >0 in the forward settings: all the old posts in my database (prior to having PressForward) auto forward as a default back to their own URLs. This means that every X seconds (as set in the setting) pages on my site automatically reload (or are redirected to themselves) and this makes the site relatively useless to attempt to read. (This seems to be a follow on error not noticed in https:/
Users adding PressForward on preexisting sites are going to have a tremendous shock if this is the default.
A better option is that all old posts (prior to installation) should default to no-forward (or at least not forward if there is no value set for `pf_forward_to_origin` in the database. PressForward should, in my mind, ideally default to no-forward in all new future posts with the possible exception of posts generated specifically by PressForward's nomination/draft workflow to default to `forward`/`no-forward` based on a possible new setting option in addition to the time setting.
It would be nice if the portion for null/non-existent values of `pf_forward_to_origin` was fixed before 4.2.2 rolled out into the WordPress repository if it hasn't been pushed already.
Running 4.2.2 on WP 4.7.2
Congratulations again to everyone, as always, on what I think is surely one of the most valuable plug-ins in the entire WordPress repository.
OPML link not working · Issue #898 · PressForward/pressforward https:/
## What I tried/expected:
From the page `/wp-admin/admin.php?page=pf-tools` under the `OPML Link` tab, the instructions indicate:
You can share your subscription list as an OPML file by linking people to http:/
## What happened:
Visiting the indicated link throws the following error:
`Warning: Creating default object from empty value in /htdocs/example/wp-content/plugins/pressforward-4.2.2/includes/opml/object.php on line 48
1`
## Additional information:
I've got a handful of feeds, so I should expect something to appear. Is there a setting I'm missing somewhere? I know that there's a setting for the /feedforward RSS functionality/plugin, is there a similar one for OPML that I'm missing?
Running GitHub version 4.2.2, WordPress 4.7.2
Text Before Links text should have stylable class · Issue #47 · dshanske/syndication-links https:/
In tweaking/changing the CSS for the multiple sizes (around v3.1.1), you removed the class from the "Text Before Links" portion, so it's not easily accessible for theming.
It might also be worth putting the entire output into a div with a class as well for better CSS control.
cross reference: https:/
Duplication of links upon update · Issue #45 · dshanske/syndication-links https:/
With v3.1.1 and relying on SNAP for POSSE, I'm noticing that after publishing and syndicating, if one comes back and edits a post and then updates it, Syndication Links regrabs the URL's and duplicates the links.
The first unedited version that is shown seems to be a plain http link and after editing/updating, the second duplicated link that is added automatically is an https version.
Manually deleting either of the included links from the Syndication Links box doesn't get rid of the links.
This duplication of the links only happens on posts which have been later edited/updated.
example: http:/
Here the Twitter and Facebook links, which are generated from SNAP, are duplicated, first as http and then again as https. As a test, the two other syndication links are non-SNAP generated links: huffduffer was manually inserted, and the WordPress one was generated from the WordPress Cross Post plugin, so I'm guessing it's an issue caused by the storage of SNAP links (which are https) versus Syndications Links' storage.