Use case: A user can bookmark a link which contains a pdf-document for downloading or viewing it online.
The url contains a version number provided by liferay.
Is it possible to ensure that you always get the latest version of the bookmarked pdf-document even if the url was bookmarked months ago ?
The uploaded pdf-documents are versioned by Liferays document library.
Of course you can remove the version number from the pdf-link but this i guess would lead to the problem that your browser will cache the document and you are again not sure if your pdf- document is the latest one.
Does anyone can drop me a hint ?
No, you cannot do it, so the only solution is to make a hook for the method that fetches the document. In this case I think you should override some of the DLFileEntryLocalServiceUtil methods. With these two links you will have enough information:
Override a service - https://dev.liferay.com/develop/tutorials/-/knowledge_base/6-2/overriding-a-portal-service-using-a-hook
DLFileEntryLocalServiceUtil - https://docs.liferay.com/portal/6.2/javadocs/com/liferay/portlet/documentlibrary/service/DLFileEntryLocalServiceUtil.html
Good luck!
Related
Is it possible to retrieve drl ex:https://host:port /ewebtop/drl/objectId/0900a58e80970f7b of document via .net application?.So that when users clicks on this link they can be able to edit the document and when they close the document the document should be autosaved onto documentum.
First of all: a link is a link. What you decide to do with it I u to you. Default handler in browser will just redirect you to webtop application. If you have SSO you can have the document opened for edit. There are some extra arguments that can be provided (view/edit).
The object id is the only varying part of the URL, so you can easily construct this in code.
Secondly: what is your goal? There is no way to make the document upload itself into Documentum repo. You can write a plugin for every application to handle that, but it seems like a big task - especially dealing with security.
The problem is that upon check-in, user must provide some information - at least about the new version number...
If you're building a thick client in .net I would go with DFS - that's the only real option here.
Is there a way to quickly navigate to a document based on a value in a document that I'm currently viewing in Couchbase?
A few days ago a colleague was showing me something in Couch and simply held down ctrl or command or something, while clicking on a UUID in a document and was then taken to the document with that UUID.
Is there a plugin for this or hidden keybinding? I was unable to find anything by googling.. Unfortunately the aforementioned colleague is now on vacation and unreachable..
In this example I would ctrl+click or something on the deadbeaf-0011-... value (yes I know I misspelled it) and it would take me to the document with the same title.
How would I do this?
There isn't a feature like that at the moment that I know of, but it's a good idea. My guess is your colleague did some URL hacking by copying the key/id and pasting it into the URL.
I'll mention this to the tools team too so they can consider that feature. :)
I got problem with my company internal extension. They don't want to publish it, as it does gather data on external server. So I need to host it myself... but would like not to lose ability of autoupdate.
As far as I read I need to use update_url in manifest, but nothing more is said in Opera documentation...
"update_url": "http://path/to/updateInfo.xml", - as it is said in documentation page
Ok... and what should I put in that xml? Will it autoupdate or just notify users about new updates? Where do I put rest of updated files?
I tried to concat Opera itself about this question, but they don't give any contact information except something like if you have problem, ask on stackoverflow... so here I am.
If it does not work, I was thinking about really BAD method, using unsafe-eval and keeping newest version in local storage... but would rather like to avoid that.
In general the behavior is the same as for Chrome. You can base on this document: https://developer.chrome.com/extensions/autoupdate
Graph API is not returning image("picture" attribute) for objects corresponding to community pages, which used to be returned earlier. For example this https://graph.facebook.com/178790412179919 does not have picture attribute whereas the corresponding page has an image.
Also the FQL query done on the "albums" connection for some objects does not have a "cover_pid" attribute for an album corresponding to type "profile", which again used to work earlier.
Does anybody know if anything has changed in Graph API corresponding to this in last couple of weeks (I am fairly confident it used to work earlier in the expected way). I looked through Facebook API release notes but could not find any changes corresponding to this. Please let me know if this not appropriate post for this forum.
https://developers.facebook.com/docs/reference/api/page/
picture is a connection, not an attribute. So ...
https://graph.facebook.com/178790412179919/picture
And as the docs say: Returns a HTTP 302 with the URL of the user's profile picture.
Kinda goofy? Yes, but it works exactly as the docs say it does. I suspect they implemented it this way so it could easily be used in an <IMG> tag.
UPDATE:
It still works via FQL. In your case:
https://api.facebook.com/method/fql.query?query=SELECT+page_id%2C+pic+FROM+page+WHERE+page_id+%3D+178790412179919&format=json
I can confirm that this PREVIOUSLY worked, but NO LONGER works. Facebook have removed the picture connection from Community Pages.
I suspect the reason is that most of these images are pulled from Wikipedia, and there was a licensing / attribution issue.
Unfortunately, Facebook is no longer a reliable source of images for entities (e.g. bands).
Our company publishes our software product's documentation using a custom-built content management system using a dynamic URL namespace like this:
http://ourproduct.com/documentation/version/pageid
Where "version" is the version number to which the documentation applies, and "pageid" is a unique string which identifies that page in our back-end content management system. For example, if content (e.g. a page about configuration best practices) is unchanged from version 3.0 and 4.0 of our product, it'd be reachable by two different URLs:
http://ourproduct.com/documentation/3.0/configuration-best-practices
http://ourproduct.com/documentation/4.0/configuration-best-practices
This URL scheme allows us to scope Google search results to see only documentaiton for a particular product version, like this:
configuration site:ourproduct.com/documentation/4.0
But when the user is searching across all versions, we don't want Google to arbitrarily choose one of the URLs to show in results. Instead, we always want the latest version to show up. Hence our planned use of rel=canonical so we can proscriptively tell Google which URL we want to show up if multiple versions are being searched. (Users who do oddball things like searching 2 versions but not all of them are a corner case, so we don't care which version(s) show up in that case-- the primary use-cases we care about is searching one version or searching all versions)
But what will happen to scoped searches if we do this? If my rel=canonical URL points to version 4.0, but my search is scoped to 3.0, will Google return a result?
Even if you don't know the answer offhand, do you know a site which uses rel=canonical to redirect across folders in a URL namespace. If so, I could run a few Google searches and figure out the answer.
The rel=canonical link element helps search engines to determine the URL that they should index, so ultimately, by specifying it for a URL, you're telling them to drop the old version and only to index the new version. In practice, it might be that both versions are indexed for a while (depending on how they're discovered and crawled), but in the long run only the canonical will generally remain indexed. In other words, if you do this for your site, over time the site:-query results for the old versions will drop (which probably makes sense).
If you need to have both versions indexed, then I wouldn't use the rel=canonical link element, I'd just link from the old versions to the new versions (eg "The current version of this document can be found at X").
Wikia uses rel=canonical link elements fairly extensively, though I don't think they use it in folders, but you can still see the results for individual URLs.