Katherine, I noticed the other day that some of your posts, like this one, is duplicating content, and was sure I’d seen something about it in one of the IW chat logs. This morning I came across a post from Davey Moloney that confirmed my suspicions about a potential bug in the Autonomie theme which I think you’re also using. He said:
The Autonomie theme had been displaying duplicate status updates on my site recently. A quick re-install of the most-up-to-date theme package seems to have fixed everything.
I know you’ve recently set up your new site, so I thought I’d mention it so you don’t waste time trying to track down the bug, which will hopefully clear up with a refresh of the theme files.
I’ll also mention in passing that your menu bar has two “About Me” links (likely introduced because you’re using your about me as your home page–this happened to me a year ago or so), and you’ve left a “Sample Page” published, so that is also hiding in your menu bar as well.
It’s threads/comments like these that make me think that using Micropub clients like Quill that allow quick and easy posting on one’s own website are so powerful. Sadly, even in a domains-centric world in which people do have their own “thought spaces“, the ease-of-use of tools like Twitter are still winning out. I suspect it’s the result of people not knowing about alternate means of quickly writing out these ideas and syndicating them to services like Twitter for additional distribution while still owning them on spaces they own and control.
I know that Greg McVerry, Aaron Davis, and I (among others) often use our websites/commonplace books for quick posts (and sometimes syndicate them to Twitter for others’ sake). We then later come back to them (and the resultant comments) and turn them into more fully fleshed out thoughts and create longer essays, articles, or blogposts like Jessica Chretien eventually did on her own website.
I wonder if it wasn’t for the nearness of time and the interaction she got from Twitter if Jessica would have otherwise eventually searched her Twitter feed and then later compiled the post she ultimately did? It’s examples like this and the prompts I have from my own website and notifications via Webmention from Twitter through Brid.gy that make me thing even more strongly that scholars really need to own even their “less formal” ideas. It’s oftentimes the small little ideas that later become linked into larger ideas that end up making bigger impacts. Sometimes the problem becomes having easy access to these little ideas.
All this is even more interesting within the frame of Jessica’s discussion of students being actively involved in their own learning. If one can collect/aggregate all their references, reading, bookmarks, comments, replies, less formal ideas, etc. on their own site where they’re easily accessed and searched, then the synthesis of them into something larger makes the learning more directly apparent.
As mentioned in the description on the plugin Post Kinds is not yet compatible with Gutenberg. If it’s something you want to use, you’ll have to install and activate the Classic Editor.
What is your favorite open source project and why?
Oh, we’re reading you Tania Rascia (@taniarascia)! Even easier for you it looks like Chris Biscardi (@chrisbiscardi) has already built out some infrastructure for webmentions on Gatsby(@gatsbyjs).
Chris has written a bit about his process as well: Building Gatsby Plugin Webmentions.
This reminds me of Nassim Nicholas Taleb’s concept of an antilibrary. It’s always nice to have some social validation for our tsundoku and issues with bibliomania.
This looks really cool. Is he talking about multiple “hands” here or is he specializing on only one or two? I’ve been tempted to work on mastering a few older variations like Spencerian or Round hand, but I haven’t yet started looking at books for it. Is this a good one?
Boy, what I wouldn’t give to have a digital, searchable copy of every book or article I’d highlighted or annotated since I was 14! Even my handwritten commonplace books from those eras are difficult to read and search through.
I, too, share this apprehension. From what I’ve read so far, it’s a tough hill to climb, but I think he’ll suggest that designers need to have larger associations like doctors, architects, lawyers, etc. to be able to create a better “standard of care.”
Presuming I’m following your question: The plugin is already using Parse This to scrape and import the “name” (aka the post title you’re bookmarking, reading, etc.) from the original website based on microformats, html, OG meta, or even schema before it posts to your site. Some sites may not provide these in which case you may have to supply something yourself. I’ve only seen a very small number of sites return nothing for these.
As I recall, if the post name comes up empty, the plugin will default to the text “a post” so that there’s something there to link to, but you can always go back and change it if necessary. If you’re using the bookmarklet, you can always manually input something as well before publishing.
Let me know if I’ve misunderstood your question and this didn’t cover your use case(s).
On first blush, it looks like the divs for the other tabs/categories aren’t nested the same way as your most recent (blog) page is.
In particular I see a div class=”ssba-classic-2 ssba ssbp-wrap left ssbp–theme-1″ that appears underneath one of the div class=”blog-desc” which may be throwing things off.
Which theme are you using and is it defining a slightly different template for your blog page than it does for the category pages? (See also: https://codex.wordpress.org/Category_Templates)
Sandy, it was great to meet you at WordCamp Orange County. I’m glad you came out and I was able to run into you. Sorry I’ve missed the meeting by a few days, but I’ll try to be around and help out in the future.
I should have outlined this originally… Likely safer (for Bridgy and the end user) would be to follow the model of posting to WordPress via email (or services like Reading.am which allow posting to it via custom email addresses). Bridgy could provide users with a private hashed email address like 123xyzABC@brid.gy which could be linked to their particular account to which they could manually (or automatically) forward the relevant Facebook notification emails. Upon receipt, Bridgy would know which account sent it and could also match it to the user’s post URL as a check before sending the appropriate webmentions.
This would leave Bridgy free from being the potential source for security leaks and put the onus on the end user. You’d naturally need to have the ability to reset/change the user’s hash in the case that they accidentally allowed their custom email address to leak, although generally this isn’t a huge issue as emails which don’t match the user’s account/endpoints would be dropped and not send webmentions in any case. (In some sense it’s roughly equivalent to my being able to visit https://brid.gy/twitter/schnarfed and clicking on the
Poll now or
Crawl now buttons. It’s doable, but doesn’t give a bad actor much. You’d probably want to rate limit incoming emails to prevent against mass spam or DDoS sort of attacks against Bridgy.)
A side benefit of all of this is that those who have kept their old email notifications could relatively easily get much of their past missing back feed as well. Or if they’re missing back feed for some reason, they could easily get it by re-sending the relevant emails instead of some of the current manual methods. Perhaps allowing preformatted emails with those same manual methods could be used to do back feed for Facebook or other providers as well?
We could also put together some forwarding filters for common platforms like gmail to help people set up autoforwarders with appropriate keywords/data to cut down on the amount of false positive or password containing emails being sent to Bridgy.
The one potential privacy issue to consider(?) is that this set up may mean that Bridgy could be sending webmentions for private messages since users get both private and public message notifications whereas the API distinguished these in the past. To remedy this, the comment URL could be tested to see if/how it renders as a test for public/private prior to sending. Separately, since Bridgy doesn’t need to store or show these messages (for long?), private messages could be sent, but potentially with a payload that allows the receiving end to mark them as private (or to be moderated to use WordPress terminology). This would allow the user’s website to receive the notifications and give them the decision to show or not show them, though this may be a potential moral gray area as they could choose to show responses that the originator meant to be private communication. The API would have prevented this in the past, but this email method could potentially route around that.