Skip to main content
 

Feature request: Archive internal page/post links to Internet Archive on publish/update 路 Issue #23 路 ManageWP/broken-link-checker https://github.com/ManageWP/broken-link-checker/issues/23

I might suggest the following functionality could fit in well with the plugin's general purpose, particularly since the Internet Archive recommends the plugin. It could also help to "close the loop" in the plugin's overall functionality for helping to maintain data integrity and working links for WordPress sites on the web.

**Suggested Functionality**
When one initially publishes (or possibly updates) a post/page, it would be awesome if all of the URLs referenced on the page as well as that of the page itself were pinged for archiving to the Internet Archive's Wayback Machine at the day and time of their being referenced in the post. (Or perhaps within a day or two of the post so as not to overwhelm Archive.org's servers with multiple subsequent updates for typos/tweaks which invariably happen post-publication.)

With this functionality, then in the future, if (when) resources change, move, etc. one could use the primary functionality in Broken Link Checker not only to restore a link to a close or reasonable copy of the original, but restore it to the _same_ day it was originally referenced.

As I'm sure you're all too aware, this can be very handy as the average web page has a lifespan of 100 days or less. I can see this being very useful to not only the general public, but particularly for bloggers, linkbloggers, journalists, and academics.

**Implementation**
To my knowledge, there are no plugins within the WordPress repository that manage this type of functionality as a standalone plugin, though there is the heavily underused [Post Archival in the Internet Archive](https://wordpress.org/plugins/post-archival/) plugin which essentially adds one's individual post/page permalink URL to the Internet Archive as it's published, though it doesn't include the archival of any links (references) within that same post.

I'm sure that Archive.org/The Wayback Machine may provide some additional documentation for implementation, though I suspect the code in the above-referenced pluign is a very good examplar. I also recently came across this snippet: https://indieweb.org/Internet_Archive#Trigger_an_Archive after a recent conference on Saving/Archiving News Sites which may be beneficial as well. It certainly exhibits at least an interest/demand for such a functionality.

I haven't dug into WordPress core, but I'm guessing some of the functionality for parsing URLs within pages/posts for sending Trackbacks/Pingbacks would have a filter or hook for providing all of the URLs in a post/page necessary for such processing and archiving while the_permalink() or get_permalink() gives the last.

Given the popularity of this spectacular plugin, it could also potentially become one of the largest forces for archiving vast swaths of the internet to the Internet Archive, short of WordPress adding such functionality directly into core.

 

Importer "chokes" on Turkey emoji 路 Issue #27 路 jtsternberg/DsgnWrks-Instagram-Importer https://github.com/jtsternberg/DsgnWrks-Instagram-Importer/issues/27

I had recently posted the following to instagram: https://www.instagram.com/p/BM5dwNtDPnU/

When the importer came to suck in the data and import it into my WordPress install it resulted in the following error:

![error](https://cloud.githubusercontent.com/assets/5882943/20652715/378c6e50-b4b3-11e6-9e41-115c49c049bf.png)

I tried uninstalling, reinstalling, and re-authenticating to see if that was the problem with no luck. I was about to give up the whole affair in utter despair (because DsgnWrks Instagram Importer is my absolutely favorite plugin in of all time and because I didn't want to use Instagram anymore if I couldn't "own" my own photos.)

In desperation, I manually "imported" the post/photo and between that and surprisingly seeing a newer post being imported properly this morning, I'm able to take a reasonable guess as to what the problem is! I also tested on another instagram account and found the same results which "confirms" the issue.

Apparently Instagram posts with the Turkey Emoji 馃 (I'm using an Android phone ) don't work well with either the Importer or even WordPress itself. I suspect that WordPress is viewing the translated code for the Turkey emoji (see also: http://www.iemoji.com/view/emoji/1861/animals-nature/turkey) as malicious code and not allowing it to be imported into the database. When trying to use the turkey emoji in a Title field (and several others) to post the photo manually, WordPress will post properly, but it scrubs the emoji code out of the post completely.

Does anyone have any experience in properly sanitizing emoji code to prevent this type of error in the future? Has anyone noticed other emoji that cause problems? I somewhat often use them and haven't seen any issues with other emoji like this.

The quickest fix is potentially to scrub out any Turkey emoji codes in future posts prior to attempting import--particularly as WordPress doesn't seem to be able to handle it properly either.




 
 
 

Checked into Little Free Library #20838

#20838" />

This one looks like it lets water into the bottom? Some of the books have water damage.

 

Checked into Little Free Library #20030

聽

Little Free Library 20030

Continuing visits of Little Free Libraries. This one is gorgeous and idyllic.

 
 

Replied to a post on github.com :

UI suggestion: Synopsis labeled in parallel with other data 路 Issue #24 路 donnapep/book-review https://github.com/donnapep/book-review/issues/24

Given the way the standard data in "book info" (except the star rating) is scrapped based on ISBN, it would be nice if the word "Synopsis" appeared in bold in front of the synopsis to provide a similar parallelism between it and the book title, author, etc.

This tweak to the UI would help to indicate a more parallel structure for the base book data and help to separate it from the user's actual review. Without it, some readers of reviews may mistakenly assume the reviewer wrote the text rather than it more likely being scraped from the publisher's description.

Similarly it might make better UI to have the star rating separated from the rest or possibly preceded by "My rating" (in bold) to indicate it as separate from the rest of the bulk data as well? Perhaps adding fields for other User specific data like "date started" and "date completed" would aid in this separation from basic book data and user generated data.

 

Replied to a post on github.com :

WhisperFollow still supported? 路 Issue #2 路 acegiak/WhisperFollow https://github.com/acegiak/WhisperFollow/issues/2

Ashton, I'd recently installed the version from the WordPress.org repository and didn't get the result I would have expected. I'm running the WordPress 4.5.3 and noticed that the plugin says it's supported up to 3.5. Perhaps this is the issue? I'm not getting any error codes or anything, just no output with what I expect is the proper set up per the instructions.

I notice that there is some new code here on Github since then which I haven't tried yet, but thought I'd ask first to see what the status of the project is. The concept of an indiereader inside WordPress is _very_ compelling and is one of the pieces that's really missing to fill out the other end of the WordPress product.

Let me know if I can provide any additional information.

 

Replied to a post on github.com :

Parallelism of display with common Jetpack plugins 路 Issue #29 路 dshanske/syndication-links https://github.com/dshanske/syndication-links/issues/29

I was looking at some CSS and noticed a few things that could be tweaked on the output.

As I suppose is reasonably common, many people on WP will be using one or more Jetpack features in addition to Syndication-Links. (I suspect many Gen 2-4 IndieWeb users will rely on Jetpack for syndication for its ease of use.) As a result, it would be nice if Syndication Links had a (default) parallel structure and mark up to "Like", "Share" and "Related Posts" within Jetpack.

To do this I'd suggest something like the following modified structure which Jetpack uses:
```
<div class="sharedaddy">
::before
<h3 class="relsyn sd-title">Syndicated to:</h3> //or whatever the programmed option is
<ul>
<li>Syndicated names/icons, etc...</li>
<li>Syndicated names/icons, etc...</li>
</ul>
</div>
```
Naturally the styling classes should be something relsyn-related with similar (or exact default) mark up as "sharedaddy" and "sd-title". If I have the patience shortly, I'll dig through the dozens of .css files jetpack throws in to style these and do a PR if you don't suspect any issues with your current roadmap.

Making the syndicated icons the same 34x34 px of the "Share" icons would be nice, but for UX/UI reasons, keeping them smaller to encourage sharing over clicking to view syndicated versions would probably be preferable to most users. Thoughts?

Since, it's early days for indieweb, is it worth wrapping the text "Syndicated to" (as an example) with a url to indieweb.org/POSSE the way that Webmention Form plugin links to WebMention to allow for some additional publicity? Perhaps those who see this functionality on sites will be prompted to want to get it themselves?

Additionally/separately, is it possible to hook Syndication links (as a default) in above all three of these common plugins so that it appears at the top of the list? (IndieWeb > Jetpack) Alternately, providing a setting value to allow placement in this hierarchy may be nice (for the future).

![syndication layout](https://cloud.githubusercontent.com/assets/5882943/16821657/532b44a0-490c-11e6-96b8-d6501f4a5efb.PNG)

 

Replied to a post on github.com :

Potential future features 路 Issue #2 路 kshaffer/hypothesis_aggregator https://github.com/kshaffer/hypothesis_aggregator/issues/2

This plugin is spectacular by the way... Here are some thoughts on future development:

It would be great if the displayed text output from the shortcode included a permalink to the original annotation on Hypothesis. As a UI suggestion, perhaps you could place it after the title of the annotated page thusly:
URL WRAPPED TITLE | < a href="permalinkhere">#</a>

Being able to circumscribe dates for displayed annotations could be useful, particularly in cases where one wants to highlight only a handful of annotations from a particular user with a particular tag but specific ones within certain time parameters. Additionally pages with embeds could, over time, require importing huge numbers of annotations which may not be ideal, or the context may change with significant future annotations that aren't relevant to what could be a static post that's trying to highlight just a few particular annotations. Time parameters could also prevent future possible spam on unwatched embeds with only "tag" parameters that could be targeted by bad actors.

 

Replied to a post on github.com :

Issue un-authenticating while moving from one site to another 路 Issue #29 路 aaronpk/OwnYourGram https://github.com/aaronpk/OwnYourGram/issues/29

I was moving my Instagram posting target from a WordPress install to a Known install.

For my WP install, on IG I revoked access from OYG and then reauthenticated for my Known site at http://stream.boffosocko.com. However, I'm still getting micropub posts to the WP install at www.boffosocko.com. (Note that I would like to keep both sites listed in my Instagram profile/bio, if that makes a difference.)

Is there something else I need to do to deactivate ownyourgram from publishing to my WordPress install?

Is it possible that OwnYourGram holds the same authentication for two separate sites using the same Instagram account? This could mean that one would need an "off" switch through the ownyourgram interface to deauthorize one site. It could also separately be the case that Instagram didn't flush a cache which allowed my last IG post to the WP site to slip through.

 

Replied to a post on github.com :

Display Text toggle not working 路 Issue #25 路 dshanske/syndication-links https://github.com/dshanske/syndication-links/issues/25

I've updated to the most recent and everything works properly (I've toggled through most, but not necessarily all of the various combinations).

The one that doesn't seem to be working is the "Display Text", which as I recall swapped between the icons only view and the actual text (eg. "Facebook"). It doesn't seem to matter whether the "Display Text" is checked or not, it only displays the icons.

 

Replied to a post on github.com :

Call to undefined function extract_domain_name() 路 Issue #24 路 dshanske/syndication-links https://github.com/dshanske/syndication-links/issues/24

After updating IndieWeb plugin and Syndication Links I get the following:

Fatal error: Call to undefined function extract_domain_name() in /wp-content/plugins/syndication-links/includes/class-syn-meta.php on line 52

This shows up in the page display where the content is usually otherwise output, so I still get the featured image, but no content and the error appears instead.

If I check the box for "Disable Syndication Links in the Content" the error disappears, but of course then the links don't show up on the page.

 

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.