On Hippo Site I am doing a business logic to persist a bean.
I want to convert the following human readable string to SEO friendly URL
Human readable string:
To get - developers # up to speed with Hippo CMS quickly
SEO friendly URL:
to-get---developers-up-to-speed-with-hippo-cms-quickly
What is the Hippo utility method to do this conversion?
Internally Hippo does something like:
ISettingsService settingsService = getPluginContext().getService(ISettingsService.SERVICE_ID,
ISettingsService.class);
StringCodecFactory stringCodecFactory = settingsService.getStringCodecFactory();
return stringCodecFactory.getStringCodec("encoding.node");
You should be able to use that.
edit: Looking at Ilja Murasko's answer, I just realized I left out an important part. What I described gets you the proper StringCodec instance. You still have to call encode on that with the string. It is in practice the same class that Ilja is instantiating.
import org.hippoecm.repository.api.StringCodecFactory.UriEncoding;
new UriEncoding().encode("To get - developers # up to speed with Hippo CMS quickly");
the above line returns: "to-get---developers--at--up-to-speed-with-hippo-cms-quickly"
Related
This question isn't specific to any particular library, framework, or programming langauge, because I expect this to be a sort of generalized rule that has a standard answer across all, or most, programming disciplines.
Imagine I'm writing a class to interact with some Rest api. The rest api has endpoints like this:
POST www.rest.com/item/create
POST www.rest.com/item/delete
POST www.rest.com/schedule/add
GET www.rest.com/schedule/{user-id}
Now, in my class to interact with this api, naturally I'm going to have a base url
private string baseUrl = "www.rest.com/";
And when I want to make a request, I'm going to append the rest of the route to that base URL.
string url = this.baseUrl + "item/delete";
My question is, is it standard to include the slash at the end of rest.com, or is it standard to leave base url without the slash, baseUrl = "www.rest.com", and put the slash at the start of the route, this.baseUrl + "/item/delete"?
I have a feeling there's a universally preferred way, but I can't find it documented anywhere.
#Actito we have our Developers Portal hosted as a Docusaurus v2 website.
We start to work more and more on content, and for consistency/better structure aspects we regularly rework the pages structures/hierarchy
What is the right way to handle those moves without our users facing broken pages (bookmarked) ?
Can we setup something to do with routing so as to store redirections from former links to new ones ?
I would be happy to hear about that
Thanks a lot for your help !
KR,
Marc
You can use the plugin-client-redirect plugin to create redirects. The syntax is straightforward:
type RedirectRule = {
to: string;
from: string | string[];
};
I'm using this and it works OK. The problem is that list of redirects can get quite big over time. You also must take special care of the page that have custom slugs.
If you can do server-side redirects, it would be better to use them.
Well the title is tricky. I was not sure if this has been already there and how to put it.
Example:
Lets suppose my site is accessible:
http://mysite.com
if mysite does additions: with 2 inputs
Now If the end user need to pass an argument to site like this (so i load the page like this):
http://mysite.com/argument1/argument2
so it should be able to thus go to the result directly: arg1+arg2
This brings to the question:when user types this, how can i retreive argument1 and argument2 and load my site according to that? Is it possible? If yes, Any client site programming solutions?
Thanks in advance.
Found the solution after searching a lot. The correct term for this process is URL-routing. We can overcome this by using #.
www.mysite.com/#/argu1/argu2
Then in the document.ready() we can read the url in the following manner:
var url = window.location;
More sophisticated way is to use the "backbone.js" for the routing. The documentation on the link explains everything
Backbone.js routing
I'm trying to achieve urls in the form of http://localhost:9294/users instead of http://localhost:9294/#/users
This seems possible according to the documentation but I haven't been able to get this working for "bookmarkable" urls.
To clarify, browsing directly to http://localhost:9294/users gives a 404 "Not found: /users"
You can turn on HTML5 History support in Spine like this:
Spine.Route.setup(history: true)
By passing the history: true argument to Spine.Route.setup() that will enable the fancy URLs without hash.
The documentation for this is actually buried a bit, but it's here (second to last section): http://spinejs.com/docs/routing
EDIT:
In order to have urls that can be navigated to directly, you will have to do this "server" side. For example, with Rails, you would have to build a way to take the parameter of the url (in this case "/users"), and pass it to Spine accordingly. Here is an excerpt from the Spine docs:
However, there are some things you need to be aware of when using the
History API. Firstly, every URL you send to navigate() needs to have a
real HTML representation. Although the browser won't request the new
URL at that point, it will be requested if the page is subsequently
reloaded. In other words you can't make up arbitrary URLs, like you
can with hash fragments; every URL passed to the API needs to exist.
One way of implementing this is with server side support.
When browsers request a URL (expecting a HTML response) you first make
sure on server-side that the endpoint exists and is valid. Then you
can just serve up the main application, which will read the URL,
invoking the appropriate routes. For example, let's say your user
navigates to http://example.com/users/1. On the server-side, you check
that the URL /users/1 is valid, and that the User record with an ID of
1 exists. Then you can go ahead and just serve up the JavaScript
application.
The caveat to this approach is that it doesn't give search engine
crawlers any real content. If you want your application to be
crawl-able, you'll have to detect crawler bot requests, and serve them
a 'parallel universe of content'. That is beyond the scope of this
documentation though.
It's definitely a good bit of effort to get this working properly, but it CAN be done. It's not possible to give you a specific answer without knowing the stack you're working with.
I used the following rewrites as explained in this article.
http://www.josscrowcroft.com/2012/code/htaccess-for-html5-history-pushstate-url-routing/
I have an existing journal website with the following url structure
http://example.com/dbtable_id/
(eg. http://example.com/89348/)
where 89348 is the primary key id of the journal article.
I want to add the title of the article to the url for SEO purposes like
http://example.com/dbtable_id/article-title
(eg. http://example.com/89348/hello-world)
I like this approach because I don't need to change the PHP code since it will still look up the article by dbtable_id. All I have to do is append url friendly titles to relevant links in template files and add one more rule to a .htaccess file.
Is there anything I should be concerned about? Am I following best practices? Will the possibility for mismatch between "dbtable_id" and "article-title" affect SEO?
There are some that argue that shallow paths are better than deeper paths, but I don't put too much stock in this. A semantic page with a screwed up URL will always do better than an unsemantic page with a "perfect" URL.
So i say, go for it. As long as it doesn't have any querystring parameters, you should be fine.