Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
rah_bitly // Articles get Bit.ly powered short links
Rah_bitly gives articles tiny Bitly powered short links. The links are generated automatically when article is posted and stored in a custom field of your choosing.
Offline
Re: rah_bitly // Articles get Bit.ly powered short links
When the article is published for the first time with live or sticky status.
A little confusing. You mean saved to database right?
As I understand it bit.ly.publishing for old articles is only possible by saving them again from the article backend?
Edit: Oh, and don’t forget the <txp:else /> permlink construct in your code example to avoid cluttering this thread in the future :)
Last edited by merz1 (2011-07-20 07:31:06)
Get all online mentions of Textpattern via OPML subscription: TXP Info Sources: Textpattern RSS feeds as dynamic OPML
Offline
Re: rah_bitly // Articles get Bit.ly powered short links
Nice one Gocom. Haven’t tried it out yet but I just flicked through your docs and noticed this:
if by change you don’t see your new, just created (note: just created), custom field right away in the list, make sure to reload the page. That’s caused by minor Textpattern core quirk, and the way preferences are updated and reloaded.
Are you referring to the fact that $prefs is sometimes stale when you view the page immediately after you save something to the prefs table? If so, there’s an antidote: get_pref() takes an optional third argument which specifies whether to go back to the database and retrieve the value instead of relying on the (possible stale) $prefs array. viz:
get_pref('my_pref_name', 'default value if not set', 1); // 1 = force database call to get valueHope that helps. If it’s something else, then sorry for polluting your thread with unnecessary twiffle. If it’s a true quirk in the core that can be fixed, let me know what your thoughts are and I’ll see what i can do.
Last edited by Bloke (2011-07-20 08:06:56)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: rah_bitly // Articles get Bit.ly powered short links
merz1 wrote:
A little confusing. You mean saved to database right?
Depends, probably. Don’t know, neither I’m born as a writer. If an article is pulled back from live and re-published, that count as the second coming, right? Plus I go with the fact that saving and database are technical terms, wheres the button is labeled (for everything) Publish.
As I understand it bit.ly.publishing for old articles is only possible by saving them again from the article backend?
Yes. The shortened links are generated when article is saved with live or sticky status. Old articles won’t be modified without direct command executed by clicking the evil red Publish button.
Offline
Re: rah_bitly // Articles get Bit.ly powered short links
Bloke wrote:
Nice one Gocom.
Thanks Stef.
Are you referring to the fact that
$prefsis sometimes stale when you view the page immediately after you save something to the prefs table?
Yes that exactly. It doesn’t happen sometimes. Always. All changes take action after a reload. No strings that are currently in memory are updated. It’s not noticeable as with most of the strings it doesn’t effect the actual preferences page. And that’s mainly how it should be. The problem comes when something on the page should change, for example the theme.
If so, there’s an antidote:
get_pref()takes an optional third argument which specifies whether to go back to the database and retrieve the value instead of relying on the (possible stale)$prefsarray.
Yes I’m well aware of that. Unfortunately the thing is that, there is an array of values that need updating as we are talking about custom fields, which are not limited to set of preference strings.
Instead of doing my own 100% replicated code (for populating the list, which would break if anything changes in the core), I decided to go with native approach, which means that the list of custom fields won’t be updated until refresh. It’s not really an issue and going with it also avoids all extra database activity the updating would cause.
I put the line to the docs just as a notice. It’s likely that some might run into the issue and wonder why it’s happening.
Hope that helps. If it’s something else, then sorry for polluting your thread with unnecessary twiffle.
Sure thanks. No not at all. It was helpful. Earlier revisions had some extra lines of silly code to do some re-population.
I also thought about moving the preference string to different page (to standard preferences).
If it’s a true quirk in the core that can be fixed, let me know what your thoughts are and I’ll see what i can do.
No true quirk, no. Just behavior, that doesn’t always pleases everyone.
I would update the preference strings in prefs_save() using the POST data when updating the database. But with that problem is that the strings would be updated when prefs_save() is called, not globally for the whole page.
Even cooler would be if the preferences where updated globally. For example changing the theme would take action right after saving without extra reloading. Boy can dream.
Last edited by Gocom (2011-07-20 08:57:16)
Offline
Re: rah_bitly // Articles get Bit.ly powered short links
Version 0.2 released, bringing some smaller changes. Issues custom field list issue and some word styling.
I’m not entirely happy with duplicating core code for change of two lines, but it does solve the custom field issue mentioned in previous posts. I’m pleased with that. We all should thank Stef for giving me the last push ;-) (it’s your fault if it breaks, hah!).
Markus, I did add some changes to the docs. Now there is the else statement and some grammatical fixes. Thanks.
Changes in v0.2:
- Preference section’s heading now uses title case, and option labels sentence case.
- Now picks up new custom fields from POST data.
Last edited by Gocom (2011-07-21 12:20:28)
Offline
Re: rah_bitly // Articles get Bit.ly powered short links
Rah_bitly v0.3 was released yesterday. The new version adds following changes:
- Changed: Now uses Textpattern’s script_js() to output JavaScript blocks.
- Improved: Escape URLs returned by Bitly so that it can not break JavaScript string. This is to prevent potential JavaScript injections.
Offline
#8 2012-02-13 16:39:14
- karlfernandes
- New Member
- Registered: 2012-02-12
- Posts: 5
Re: rah_bitly // Articles get Bit.ly powered short links
Is there any way to output only the shortlink without the http:// or the trailing slash? eg. just j.mp/aBCxyZ
Offline
Re: rah_bitly // Articles get Bit.ly powered short links
karlfernandes wrote:
Is there any way to output only the shortlink without the http:// or the trailing slash? eg. just j.mp/aBCxyZ
Yes there is. For example by doing a simple search-and-replace operation with rah_replace plugin. E.g.
<txp:rah_replace from="http://" to="">
<txp:custom_field name="short_url" />
</txp:rah_replace>Offline
#10 2012-02-14 01:57:10
- karlfernandes
- New Member
- Registered: 2012-02-12
- Posts: 5
Re: rah_bitly // Articles get Bit.ly powered short links
Thanks Gocom! That works beautifully!
Offline
#11 2012-02-14 02:00:33
- karlfernandes
- New Member
- Registered: 2012-02-12
- Posts: 5
Re: rah_bitly // Articles get Bit.ly powered short links
Another question, will the plugin generate a fresh link if a live article is saved again, but without changing its title?
According to what your site says, it shouldn’t… Can you confirm?
Offline
Re: rah_bitly // Articles get Bit.ly powered short links
karlfernandes wrote:
According to what your site says, it shouldn’t… Can you confirm?
The URLs are, what you could call, permanent. As long as article’s URL title stays same, the short link won’t change. If the URL title is modified, or the custom field storing the URL is emptied, a new short URL is requested from Bitly.
Offline