Blair Williams

This shouldn’t be happening in this way … Google should be able to follow redirects. If you’re having problems with this you should check the no follow option on your pretty links though … it will pass a noindex in the http header to googlebot when it crawls your site.

So you entered: https://website.com/category/podcast/feed into your Target URL and podcast/feed as your Pretty Link slug? And it didn’t work for you?

Pretty Link should support slashes in slugs (I just tested it in my development environment and it worked fine).

Is this what’s happening?

If you have a doubt you should just use init … if you use template_redirect then WordPress has the opportunity to resolve urls before pretty link can redirect. We’ve found that sometimes — even if there’s no actual slug for something in the URL that WordPress will actually guess a post or page that the link should go to and redirect before Pretty Link can even run. So, the option for using ‘template_redirect’ is mainly for advanced users who need it hooked there for a specific purpose.

Hope that helps,

Blair

If you upgrade to Pretty Link Pro you’ll be able to enable editors to use it as well.

There’s currently no way to add a quick pretty link from the post edit screen … but in Pretty Link Pro there is an option to automatically convert links in your post to Pretty Links.

Hope that helps,

Blair

Sure … just email me from the contact form on my blog at:

https://blairwilliams.com/contact

We haven’t yet tested this with domain mapping enabled yet. I just put this into our issue tracking system and hopefully we’ll have a chance to get it working soon.

This can depend on the capacity of your web server but trimming links like this can help if you have a resource intensive server. Also, we recommend that you switch to “count” only click tracking if you have issues with this.

Status 301 means that the resource (page) is moved permanently to a new location. The client/browser should not attempt to request the original location but use the new location from now on.

Status 307 (or 302) means that the resource is temporarily located somewhere else, and the client/browser should continue requesting the original url.

Pretty Link doesn’t create the html for a link, just the url (except for keyword replacements in pro which does have an option to open those links in a new window) … so its just up to you to add the target.

For instance … if you created this url in pretty link:

https://example.com/beans

Then in your website here’s an example of how you’d embed that url in an html link that will open up in a new window:

<a href="https://example.com/beans" target="_blank">Beans</a>

Pro already integrates with standard GA page tracking currently but we haven’t considered event tracking before … but we’ll definitely think about how we’d integrate it in with Pretty Link and if it makes sense we’ll put it on our new features list.

Currently social maven relies on the post id of the link to generate the correct url so it can’t be used all that well outside of the loop. This is a really good idea though, perhaps we’ll add this feature to a future release.

Look at this file if you’re wanting to modify the order of the buttons:

https://github.com/Caseproof/social-maven/blob/master/app/views/buttons/buttons.php

And the files in the following directory if you want to actually alter the individual button code:

https://github.com/Caseproof/social-maven/tree/master/app/views/buttons

Hope that helps.

B.

It looks like this is working on that page … is this working for you now?

As for posts.js — I think I did have some code in there earlier but apparently it’s still being enqueued. I’ll have to go in and get rid of that. It should really affect you negatively in any way until I get an update out though.

We’re working on a fix for this now.

Well, it will be difficult to load these in excerpts since html is stripped from excerpts. I’ll push a fix for this soon … but the buttons will just be removed from excerpts.