Can I Create a reblog link programatically?
Is it against the terms of service? I can't tell...
Anatomy of a tumblr reblog link: (unique numbers made up)
http://www.tumblr.com/reblog/85728493821/7vu4jf89
In my RSS feed I have:
myblog.tumblr.com/post/85728493821
So its safe to say the 85... number is a unique post id
But what is the other code? (7vu4jf89)
The 2nd value differs for each reblog link, so its not just my unique identifier.
Arbitrary values do not work either.
I was thinking maybe its something Tumblr implemented specifically to prevent people from doing the sort of thing I'm attempting? Maybe its some sort of hash value combining my account identifier and the post?
Any insight is appreciated.
Tumblr Reblogs
Ignoring the RSS part for the moment, I believe there are two official methods to achieve a working reblog link.
Use the template variable {ReblogButton} (http://www.tumblr.com/docs/en/custom_themes#like_and_reblog_buttons)
Use the Tumblr API (http://www.tumblr.com/docs/en/api/v2#reblogging)
In reply to your question about other code. I believe this is a unique, randomly generated key, the make up of which I am not 100% sure on. The key seems be unique per post and per site.
For example, if the original reblog key is 12345678 and the post is reblogged, a new key is generated for the site that reblogged the post.
Back to the RSS part, sadly as you have probably gathered, getting the reblog key inside the RSS feed by default is impossible. My advice would be to find the permalink in the RSS feed and use an API call to return the corresponding key for a reblog.
There is a way to construct the reblog URL manually, if you have access to the post’s HTML page:
search for rk= in the HTML source code (it's in the block opened by <!-- BEGIN TUMBLR CODE -->)
copy the value of this parameter (e.g. "1234" if you find rk=1234)
now manipulate the URL:
append this value at the URL (add a slash before it, if there is none) (you can replace the slug with the value, if available)
replace "post" with "reblog"
remove the subdomain
call this crafted URL
This rk value (maybe "reblog key"?) doesn’t seem to be included in the feed.
Related
I am faced with a LinkedIn sharing issue.
This issue probably reproducible from March 1st 2019.
I share some url e.g. https://www.linkedin.com/sharing/share-offsite/?url=SHARE_URL#HASH
Worked before: link in post(href) - SHARE_URL#HASH
Works now: link in post(href) - value of og:url meta tag from SHARE_URL#HASH page
So we lose request parameters in SHARE_URL and #HASH
How we can pass link for LinkedIn post into request?
You need to do URL-encoding with parameters you are feeding to another URL. So, this is what you should want...
https://www.linkedin.com/sharing/share-offsite/?url=SHARE_URL%23HASH
Remember, URL's use things like ? and # to indicate a special argument occurring after this character. So, for instance, example.com/share.php?title=thisistitleright?&..., how would the browser know that the first ? indicates the GET param and the second ? is a part of the title argument? Easy: URL encoding.
In case you want to know more: Official LinkedIn Share Documentation
I'm trying to migrate my ASPX site to Kentico, and as part of my task I'm migrating URLs. I need to preserve my URL structure, so I need to keep URLs which look like : "foo.com/bar.aspx?pageid=1".
I checked page's "URLs" property tried to use wildcards, some patterns like /bar/{pageid}- /bar/{?pageid?}-, etc but Kentico always replaces question marks.
Is there a way to achieve that via the admin interface?
You don't need to do anything in order to use "foo.com/bar.aspx?pageid=1" url.
Create a page under the root and call it bar, so you'll get a page # foo.com/bar.aspx. Kentico and/or .net does not care what you add to a url after question mark, so foo.com/bar.aspx?pageid=1 will work as well as foo.com/bar.aspx?someparam=sdf, or foo.com/bar.aspx?id=1&p=3&t=3.
You may (or may not) implement some functionality based on query string (e.g. paging), so it will parse query string and act in appropriate way.
By default Kentico UI does not handle adding URL aliases with URL parameters like you show. There is an article on the DevNet for a URL Redirection module which has code you can import into your site to allow you to perform these redirects within the Kentico UI. I'd suggest using this approach.
Unfortunately, I can't share a code sample since it's an article but it also has a link to download the code too. This appears to only be coded for Kentico 8.2 right now but I'm guessing you could do some work to make it work for other versions if you needed.
I think there are few concepts that you are clubbing here. I will start with your line code here
/bar/{pageid} - {pageid} is a positional parameter in Kentico's language if you choose to use dynamic URLS based on patterns. SO if you have a code that relies on pageid parameter to fetch some data then Kentico will pass that value. E.g in case of /bar/420, it will pass pageid as 420 different web parts on your template
/bar/{?pageid?} - This will search for query string parameter "pageid" on the request URL and replace its value here. So if you passed foo.com/bar.aspx?pageid=366, the resulting URL will be /bar/366
The #1 is positional parameter and #2 is the way in which Kentico resolves query string macros.
I hope this clarifies.
I wrote an RSS2 feed on WordPress a while back, but for some reason, some of the URLs aren't working anymore. The current version of WP is 4.7.2.
For example, https://justhoodsbyawdis.com/product/jh001/feed/ works, but https://justhoodsbyawdis.com/brands/feed/ does not.
Note that https://justhoodsbyawdis.com/product/jh001/ is a valid page on the site, but that https://justhoodsbyawdis.com/brands/ is not, because it is only valid for feeds. The latter results in an "ERROR: This is not a valid feed." message.
Is there a way to make an URL for a RSS2 feed, even without an associated WP page (i.e. without the "/feed/" at the end).
Thanks!
Rob
EDIT 1:
I added a post called "brands", which fixed the problem. The only thing is that the dummy post is viewable by anyone. Any ideas how to block it, but not the feed?
Another problem is that query strings break the feed, for instance:
https://justhoodsbyawdis.com/products/feed/?name=hoodies
doesn't work, although it does without the "?name=hoodies".
How would I make that work?
EDIT 2:
It would appear that the name query string parameter is now causing problems - see:
https://codex.wordpress.org/Function_Reference/register_taxonomy#Reserved_Terms
Is there a way to make it backwards compatible? Otherwise, the existing app that calls the feed will also have to be changed...
I wound up creating dummy pages to fix the invalid feed error.
I had to change the "name" query string parameter to "prod_name" so as to not conflict with reserved terms.
Rob
is it possible to replace the word search?
For example:
http://domain.com/search/helloWordl
to
http://domain.com/test/helloWordl
i think you just need to create a new page template and save as searchpage.php, add the correct code.
Change the form action to redirect to the page you just to create and that's it.
Read this to better understanding, you will find the correct loop and all the steps to do that.
I'm trying to finalise on a restful url structure for the wishlist section of a site I'm working on. It's a pretty simple model, a user can have many wishlists and each wishlist can contain many products.
Currently I have the obvious CRUD URLs to manipulate the wishlist itself :
GET account/wishlists.json
GET account/wishlists/{id}.json
POST account/wishlists.json?name=My%20Wishlist
POST account/wishlists/{id}.json?name=My%20New%20Name
DELETE account/wishlists/{id}.json
However, I don't think I know how to structure the URLs that would add/remove a product to a wishlist :(
Here are my current choices :
1) Have the product to add as part of the URL and use the HTTP verb to define my action
POST account/wishlist/{id}/product/{product_id}.json
DELETE account/wishlist/{id}/product/{product_id}.json
or
2) Have the action as part of the URL and the product id as part of the payload
POST account/wishlist/{id}/add.json?product_id={product_id}
POST account/wishlist/{id}/remove.json?product_id={product_id}
(1) is clean and, as far as I can tell it's pretty RESTful but doesn't allow things like adding multiple products easily etc.
I'm also a bit concerned about using the DELETE verb - I'm not deleting the product or the wishlist, I'm just removing one from the other.
(2) is more explicit but veers away from REST - I wouldn't be just referring to the resource in the url, I would be referring to an operation on that resource :(
Any advice on which of the above would be more correct would be very helpful! (If there's a third option that's better than mine, feel free to correct me!)
(1) is the only valid approach for REST, using HTTP verbs for actions.
(2) encodes method names into the URI which is more like RPC and of course not RESTful.
Concerning your shortcomings about the first approach:
The DELETE verb is fine, because your resource is the item inside in the wishlist, not the item itself.
You can support batch requests. For instance, you might want to allow to POST a list of items to a wishlist resource resulting in mutliple adds.
PS: Prefer HTTP content negotiation (Accept and Content-Type headers) over representation formats encoded in the URI.
I think your first option is more in line with the REST philosophy. If you want to manipulate multiple products, you could pass the ids as a list in the body, instead of using a query parameter.
As for the delete part, given that you are deleting a subresource of wishlist, I think the intention is clear (i.e. remove the connection from the wishlist to the product). If you wanted to globally remove a product, the URL should be something like
DELETE /products/{id}
As noted by other responses, the first option is clearly the RESTful approach. The approach to deleting products from the wishlist looks fine - after all you would be doing a DELETE on product/{product_id} to remove the product itself.
For adding products, you might wish to consider a POST to account/wishlist/{id}/product/ the body of which could contain a list of product IDs.
Here's a nice article on how to think about REST URLs