aaroneaton / better-yourls Goto Github PK

Being that this plugin hasn't been updated in a few years, does this plugin still work with the current version of WP and Yourls?

Not all YOURLS installations are restricted to one shorturl -> longurl mapping. It's a setting, and some people do want the ability to create different short URLs pointing to the same long URL for use in different channels.

Using create_yourls_url() in getter methods like filter_get_shortlink() and filter_sharing_permalink() assumes that the YOURLS instance in use is configured to generate only one shortlink per longurl—which isn't necessarily true.

This looked like a good candidate for refactoring, to have only one method that deals with checking whether a shortlink exists for the post in question. First it would check the postmeta field, and then query the YOURLS API. Unfortunately it seems the YOURLS API doesn't have a method to fetch the shorturl for a given link without (attempting) to create one…

So maybe it's better to do the refactor, but instead make the getter check the postmeta always, and then call create_yourls_url() iff there is no shortlink stored in the database.

It's tough, because the YOURLS API really should allow asking for a shorturl without making one… Thoughts?

I get that a big selling point, as it were, of this plugin is that it has only two options. But I'd like to propose adding an option for when to create shortlinks:

• on save
• on publish (manual or scheduled)
• manually (with a button in the edit screen metabox)

Those are just my ideas for the set of options, and I'd love to discuss alternatives. I'm not always the best at coming up with these things. But I do think that on publish should be the default, so the creation is delayed until the last possible moment, to give users the chance to think of a custom keyword if they want to. I really like the idea of having a "Create YOURLS link" button in the metabox to specifically create the shorturl independent of saving or publishing, too.

The reasoning goes like this: Adding a plugin like this to a site with lots of historical posts, like mine, means that a huge number of posts probably won't have shorturls stored. In that case, when one starts editing old posts to fix the odd broken link, embed, or what-have-you, suddenly shorturls get generated. They probably won't get used in my case, because once posts are announced to social media I rarely use the shortlink again. So they're unnecessary clutter in both the WordPress and YOURLS databases.

Additionally, often I don't think about the shortlink until after I've already saved a draft or two. By then, the plugin's already created one with a YOURLS-chosen keyword and I've lost the opportunity to pick a custom one—unless I want to edit it in YOURLS and then manually edit the WordPress database. (The plugin's postmeta field doesn't seem to be visible from anywhere that allows editing, so ssh + mysql is the only way I've found.) And the default YOURLS API doesn't offer a way for the plugin to change the keyword automatically—nor would one want to, necessarily, because the shortlink might have been used inadvertently and editing the keyword would then break it.

My plugin is https://github.com/Benunc/better-click-to-tweet

On line 44 of the main plugin php file (better-click-to-tweet.php) in trunk, I've called wp_get_shortlink(). Other plugins (I tested the WP bit.ly plugin at https://wordpress.org/plugins/wp-bitly/ ) work with my plugin, but Better YOURLS seems to not work.

My best guess after poring over the code is that the pre_get_shortlink() function in your plugin is somehow firing after my plugin has already built the shortcode that includes the wp_get_shortlink() call.

I don't know if the issue is on my plugin or yours, but since the WP bitly plugin works as expected, I thought I'd reach out to you.

Hey Chris, it looks like this is still not fixed even after the latest update (and the discussion in #13). We are noticing ?id=123456 urls again used by our Twitter plugin for scheduled posts :(

Hi Chris, thanks for the great plugin.

Unfortunately I've encountered a severe problem with Better YOURLS in conjunction with Elegant Themes' Divi theme, where after the theme was activated, any attempt to edit a page or post, or access the Customizer or Appearance -> Themes page was met with a blank "Security Error" page from Wordpress.

I have had to disable the plugin due to my site not functioning as a result.

I'm also using the GeoDirectory suite of plugins (which seem to work very well with Better YOURLS, thank you). It was Divi that caused everything to go crazy.

Steps to replicate:

1. install EDD or GIveWP
2. create a test donation (in Give, use the "Test Donation" Payment Gateway at Donations--> Settings --> Payment Gateways (tab))
3. On completing the donation, it will go through, but the donor is thrown to a page that says "Security Error"

I had a report of it with two recent EDD purchases, and I just replicated in a live environment.

Possible solution.

Give creates a hidden post type of "give_payment" used to show transactions. Better Yourls needs to be able to exclude those hidden post types.

I've deactivated for now, but look forward to helping find a solution. I still have it active in a staging environment for testing.

It's easy for users to put in only the YOURLS domain, but API requests do use a secret token that should not be revealed in cleartext if it can be avoided. My YOURLS installation is available over HTTPS, and I'd like to eliminate insecure requests to it as much as possible.

I propose the following:

• Better YOURLS continues to accept just the domain as a setting
• Internally it's now treated as base_url instead of domain
• On save, prepend http:// to the option if it is missing
• Users can use an https:// value if they want
• The option is validated by something like the regex https?:\/\/.+(\..+)+\.?(\/.*)*\/?
  ** This pattern allows for YOURLS installations accessed over HTTP or HTTPS, at the domain root or in subdirectories

I have a lot of CamelCase link titles in my YOURLS database now.

For example, the post title "New Version of WOT Released" becomes "NewVersionofWOTReleased" when submitted to YOURLS by this plugin.

Oddly enough, some have spaces in rare cases, e.g. "Gdrive Rumors Surface Again" becomes "GdriveRumorsSurface Again".

I want to say this is a result of using sanitize_title(), but I haven't been able to definitively trace it to anything.

Seems most likely to happen when adding a new item to a nav-menu and saving it. Haven't looked too far into this, but it probably has something to do with how menus are stored internally.

The shortened URLs look like, for me (with the /yyyy/mm/slug-here/ permalink structure), http://domain.tld/2016/01/1234/, where 1234 appears to be a revision ID or something like that.

If I try to use the Bulk Edit tool on a published post with Better YOURLS activated, I get a Security Error.

See https://youtu.be/qf-R3Y7lrHw for a demonstration from a test site with no other activated plugins and using the Twenty Fifteen theme. Better YOURLS settings were the default ('Use https' and 'Allow Self-signed https Certificate' disabled, no post types excluded.)

If it might be helpful in diagnosing the problem, I also noticed that if I hid the Better YOURLS metabox from the post editor with WPAUIC and tried to update a post I saw the same error.

Many thanks!

On my installation (WP 4.3.1 with Better YOURLS 2.0), old posts without shortlinks have /?p=1234 in the shortlink header tag. I've manually edited the postmeta table to move existing shorturls from old posts that had them generated by other plugins, but there are still several hundred that don't have YOURLS links.

I propose that Better YOURLS generate or retrieve a shortlink from the configured YOURLS instance if a post is viewed but doesn't have a shortlink.

Obviously this introduces the potential for the YOURLS instance delaying page load while the plugin waits for an API response. One mitigation option is to have the plugin only wait a couple seconds at most for YOURLS to return a shortlink. Ideally it would complete the request no matter what, even if it lets the page continue to load—but WordPress might not be able to do that. At worst, the plugin can simply try again the next time the post is requested.

The main alternative I can think of is to backfill shortlinks in a background job, the way, say, Broken Link Checker processes URLs—but that sounds a LOT more complicated to program. Since each post only needs to have a shortlink fetched/generated once, it's probably not worth the effort to code up background workers or wp-cron jobs.

Thoughts?