I tried to find a way to make an OpenSearch Description available in ie 11. I did find this page, but it had insufficient description.
https://msdn.microsoft.com/en-us/library/ie/dn832639(v=vs.85).aspx
Questions that arise from that are:
What is the namespace for the namespace "ie" as used in ie:NTLogo, ie:NTSearchResult, ie:NTSearchSuggestion
The pages says that the osd-xml "need to upload it to IEGallery (or another website)". Where/how can it be uploaded onto other websites.
ie:NTLogo it appears to me that the placeholders {language}, {scalefactor}, {contrast}
you can use SO's OSD as a template.
OSD for stackoverflow
the xmlns attribute values points to a public document that contains the allowed tag names for an xml document of type OSD.
see opensearch.org
Related
The idea was to be able to, as soon as a receive a mail with a PDF attached, find a way in which the PDF can be downloaded and be searched for a specific keyword (for instance, see if my name is in it) and if my name is on any of the pages of the PDF, then send another mail notifying the user that there’s a pdf in which he has been named.
This is in order to avoid having to check dozens of mails daily and PDFs just to see if your name is in it or not.
I managed to do this using Zapier but I relied on PDFco’s API for the search, and it is payware, so I’m taking a different approach.
My question is more based on what library would make that search inside the PDF and would provide a Boolean value that said if the keyword exists or not.
Thank you!
This is my first time using Ektron and i'm trying to implement Json-LD schema scripts for each page. I have 68 scripts that I need to implement that are unique for each page.
I thought I would be able to implement these scripts through meta data, but now i'm unsure. Each script is over 1000 characters, the html and meta tag types only allow 500 characters, so i'm assuming i'm in the wrong place. If anyone could shed some light it would be much appreciated.
Ektron's metadata isn't intended for large chunks of data / content. So, yes, you will find limits there.
Here are two things you might try as workarounds.
Most direct:
Use the Ektron Library. Go to the Library tab and click on the Root node and view Properties. Add an extension to allow you to upload your JSON-LD as a file. Use metadata on the content item to reference the uploaded file. Combine the two upon output.
If you want the JSON-LD to be editable within the CMS...
Gaming the platform a bit
Create a new SmartForm definition and include in it a single plain-text, multi-line field (not Rich text). This should hold your JSON-LD. Set up a folder and, if your version supports it (you didn't specify CMS version, so I will assume relatively recent), set the folder to be non-searchable so these things don't come up in site search results. Add a restriction to the folder to only allow the Smart Form definition you just created. Create your JSON-LD there using the plain-text field. You should be able to store up to 1MB.
Same as above, add your JSON-LD as text then use a reference to this item from the content you want to use it.
The metadata in this case (and possibly the library one, though I'd have to test and I don't have an Ektron environment for development anymore) will give you the Content ID for the object holding your JSON-LD. You'll have to make another API call but will give you the solution you appear to want from above.
Should the "WebSite" and "Organization" types and their properties be applied to all pages of a website or just the homepage?
I have valid JSON-LD code defining the the necessary items for Google mobile search results, but I am not sure if it should be included on all pages or just the root/home page.
It would make sense to provide it on any page where it’s relevant.
For example, if this is an organization’s website, each page is about/from the organization, so provide metadata about this organization on each of the pages.
A consumer looking for structured data on a certain page is not necessarily also visiting and checking the homepage, so it might never learn that you are providing relevant metadata.
That does not necessarily mean that you should include the full item (with all properties) on each page. It can be sufficient to provide the full item only on one page (e.g., on the site’s homepage), and link to it (for example with the property author) from each other page.
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!
I have a Search web reference (from a Search Server 2010 express install) in a vb.net application that is utilizing the QueryService Class to search a production Sharepoint foundation 2010 site.
At a previous point in time, we had created a proof of concept on an entirely test system that has since been turfed. From my recollection on this test system when documents were uploaded as a specific site content type (that inherits from document) and metadata was provided, we could search for specific metadata by making managed properties for each, and search results would be returned as documents (with the isdocument flag set to true). Viewing the document then became simple, as we could simply use the filename and path to display the stored file.
Now we are developing a production system and we have encountered a new behavior, where these results now are returned as aspx results such as
http://digitizaton/Company/Client Documents/Forms/DispForm.aspx?ID=1703
This of course makes it terribly difficult to locate and view the document, we can extract the Title which will then give us the name of the file with no extension, but that hardly helps, as the FileExtension data is aspx, not the documents file extension, so we don't have a full filename. We could display the page returned as a result, but would much prefer the document itself.
I've made a test document library, with just bare bones setup, (not using the site content type, or site columns) and uploaded some documents on the same site, and they are returned in the same fashion, so I don't believe the document library, or content type are the issue.
With a fairly limited understanding of both Sharepoint and Search Server, I don't know if this is a setup issue with the search service itself, with the site configuration, or with the querypacket I am sending. We also have a third party application (Knowledgelake) installed on the server that ties into sharepoint which could have changed configuration somewhere as well?
I don't think the query packet has changed since it was working in the proof of concept, other than the custom data column names. I will provide it here in case there is something glaringly obvious to an external reader.
<QueryPacket xmlns='urn:Microsoft.Search.Query.Document'>"
<Query>
<SupportedFormats>
<Format>urn:Microsoft.Search.Response</Format>
</SupportedFormats>
<Range>
<Count>0</Count>
</Range>
<Context>
<QueryText type='MSSQLFT'>
SELECT Filename, Title, FileExtension, IsDocument, Path from Scope() WHERE ""Scope"" = 'Department1' AND CustomData = 'X' --
</QueryText>
</Context>
Any guidance would be incredibly appreciated. If I have not provided some relevant information, please let me know and I can track it down.
Thanks everyone
So now I feel like an idiot, I've searched for hours with no luck, and literally seconds after composing this post, I find the nugget of gold I've been searching for.
It appears that our primary file type, PDF, has a known issue with Sharepoint 2010, as shown at the following site.
http://www.sharepointsharon.com/2010/03/sharepoint-2010-and-adobe-pdf/
and further to that, this registry entry setting is required to link it all together
http://www.mossgurus.com/adnan/Lists/Categories/Category.aspx?Name=SharePoint%202010%20--%20Configuration