I am trying to get an open search definition to work on subdomains.
I have added the correct line in the <head> of the html.
Example:
<link rel="search" type="application/opensearchdescription+xml" title="Example" href="http://www.example.org/opensearch.xml" />
In opensearch.xml:
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/" xmlns:moz="http://www.mozilla.org/2006/browser/search/">
<ShortName>Example</ShortName>
<LongName>Example Search</LongName>
<Description>Example Description</Description>
<InputEncoding>UTF-8</InputEncoding>
<Image width="16" height="16" type="image/x-icon">http://www.example.org/favicon.ico</Image>
<Url type="text/html" method="get" template="http://www.example.org/search/{searchTerms}" />
</OpenSearchDescription>
The search is correctly added to the omnibox settings in Google Chrome, when I visit http://www.example.org. The trigger keyword becomes "example.org".
However, when I visit http://subdomain.example.org, which has the same line in the <head>, the search is added with trigger keyword "subdomain.example.org" instead of "example.org".
Is there a way around this?
I have not found any information on how to set the trigger keyword in the documentation at http://www.opensearch.org/Specifications/OpenSearch/1.1 .
Related
I'm working on a content element created with flux. Editors using this element can use some markers in some fields (e.g. ###region###). Therefore I would like to give information about the markers that can be used.
I checked CSH and the Flux documentation but couldn't find any solution. Does someone have an idea how to solve this?
My code:
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://typo3.org/ns/TYPO3/Fluid/ViewHelpers"
xmlns:flux="http://typo3.org/ns/FluidTYPO3/Flux/ViewHelpers"
xmlns:v="http://typo3.org/ns/FluidTYPO3/Vhs/ViewHelpers"
data-namespace-typo3-fluid="true">
<f:layout name="Content"/>
<f:section name="Configuration">
<flux:form id="tt-teaser">
<flux:field.input label="Stoerer" name="stoerer"/>
<flux:field.input label="Title" name="title"/>
<flux:field.text label="Text" name="text" enableRichText="1"/>
<flux:field.input label="Button Text" name="buttonText"/>
</flux:form>
</f:section>
I'm using TYPO3 v10.4.13 and Flux v9.4.2.
You can add LL references for TCA descriptions, the tx_news extension uses this approach as well.
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addLLrefForTCAdescr('tt_content.pi_flexform.[extkey-with-no-lower-dash]_[CE-name]', 'EXT:your_ext/Resources/Private/Language/locallang_csh.xlf');.
As you can see you have to add this for each CE, also the id in the language file is "[field-ID].description".
We have a XML file that is on somewebsite and looks in a way like this (confidential parts stripped)
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<feed xml:base="https://somewebsite.com/crm/" xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata" xmlns="http://www.w3.org/2005/Atom">
<title type="text">Accounts</title>
<id></id>
<updated>2016-02-04T08:36:56Z</updated>
<link rel="self" title="Accounts" href="Accounts" />
<entry>
<title type="text"></title>
<updated>2016-02-04T08:36:56Z</updated>
<author>
<name />
</author>
<content type="application/xml">
<m:properties>
<d:Type>A</d:Type>
<d:UniqueTaxpayerReference m:null="true" />
<d:VATLiability m:null="true" />
<d:VATNumber m:null="true" />
<d:Website m:null="true" />
</m:properties>
</content>
</entry>
<link rel="next" href="https://somewebsite.com/Accounts?$skiptoken=guid'ee6bc390-a8ac-4bbd-8a4d-0a1f04ab9bd3'" />
</feed>
We use the new Rest connector to get the data out of this XML file.
The XML has pagination and every 60 entries you can load the next 60 with the link at the bottom of this xml file.
The problem i have is when, in the REST connector, we want to enable pagination with these setting:
Pagination Type: Next URL
Next URL field path:
/*[name()="feed"]/*[name()="link"][contains(#rel,"next")]/#href
It doesn't seem to work...
side note: the XML file has namespaces so i need to target the elements this way instead of /feed/link/...
I'm using Xpath syntax to target the link href, but maybe this is not the way to go? Or maybe the REST connector isn't using Xpath syntax?
Really hope someone can help me!
Actually it turns out that this seems to be due to a "bug" in the "Qlik REST Connector 1.0" so the pagination doesn't work.
But there is a fix for it:
1) Make sure that the Qlik REST Connector 1.0 connect dialog box has the NextUrl set to:
feed/link/attr:href
2) When the SQL has been generated after using the SELECT-button and going through the wizard you have to modify the sub-SELECT that reads like this:
.....
(SELECT
"attr:rel" AS "rel",
"attr:title" AS "title",
"attr:href" AS href,
"__FK_link"
FROM "link" FK "__FK_link"),
.....
On line 05 you will have to remove the text AS href.
So it should look like this:
.....
(SELECT
"attr:rel" AS "rel",
"attr:title" AS "title",
"attr:href",
"__FK_link"
FROM "link" FK "__FK_link"),
....
3) Find the LOAD statement that loads from this sub-select with a RESIDENT [MasterREST further down in the load script and make sure that the reference to href is changed to [attr:href] - or else you will get an error message while loading.
Should look like this after the change:
[link]:
LOAD [rel],
[title],
[attr:href],
[__FK_link] AS [__KEY_feed]
RESIDENT RestConnectorMasterTable
WHERE NOT IsNull([__FK_link]);
This worked for me:
/*[name()='feed']/*[name()='link'][#rel='next']/#href
Yours should also work actually, maybe whatever you are using does not agree with double quotes instead of single quotes.
I have sling mappings setup that rewrite outgoing paths to the external URL. An example of this rewrite:
/content/www-sitename/home.html would be rewritten to http://www.sitename.com/home.html
I have also configured the LinkCheckerTransformerFactory: linkcheckertransformer.rewriteElements=["a:href","area:href","form:action","link:href","meta:content"]
Some HTML on a page component:
<head>
<link rel="canonical" href="/content/www-sitename/home.html" />
<meta name="canonical" content="/content/www-sitename/home.html" />
</head>
When visited, only the link:href has been rewritten, meta:content is unchanged:
<head>
<link rel="canonical" href="http://www.sitename.com/home.html" />
<meta name="canonical" content="/content/www-sitename/home.html" />
</head>
Worth noting is that the link:href was not rewritten prior to configuring the linkcheckertransformer.rewriteElements to include it. Why did this change work for link:href, but not meta:content. Aside from creating a custom rewrite filter, what can be done to get links in meta:content attributes to be rewritten?
nerd answer is correct, by default the internal Sling mechanism responsible for parsing HTML (htmlparser) supports only following tags: a, area, form, base, link, script, body, so even if you add meta:content to the LinkChecker configuration, CQ won't recognize the <meta> as a tag which needs processing.
In order to reconfigure htmlparser, create a node named generator-htmlparser under /libs/cq/config/rewriter/default with following properties:
jcr:primaryType = nt:unstructured
includeTags = [A, AREA, FORM, BASE, LINK, SCRIPT, BODY, META]
The includeTags property should be multivalued, so you can add other tags in the future.
If you don't want to override the content under /libs, create your own rewriter configuration:
Copy /libs/cq/config/rewriter/default and its children to /apps/YOURAPP/config/rewriter/my-rewriter.
Set order property on the my-rewriter to 1.
Create generator-htmlparser under the my-rewriter as above.
I think you have to add meta tag to the htmplparser generator.
see my question and answer: How to add additional element to htmlparser generator
i am building a thunderbird extension and enabled the options popup by adding following to the install.rdf
<em:optionsURL>chrome://content/options.xul</em:optionsURL>
this enables the button but on clicking it nothing happens. the options.xul looks like as below
<?xml version="1.0"?>
<prefwindow id="EmailToOSN-prefs"
title="StockWatcher 2 Options"
xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
<prefpane id="sw2-stock-pane" label="Stock Settings">
<preferences>
<preference id="pref_symbol" name="extensions.stockwatcher2.symbol" type="string"/>
</preferences>
<hbox align="center">
<label control="symbol" value="Stock to watch: "/>
<textbox preference="pref_symbol" id="symbol" maxlength="4"/>
</hbox>
</prefpane>
</prefwindow>
Assuming that you have a folder content where you have placed your code files
(including options.xul)
First you have to declare this "content" folder in your
chrome.manifest file by adding this line:
content extension_name content/
Second in your install.rdf file you must write this:
<em:optionsURL>chrome://extension_name/content/options.xul</em:optionsURL>
Third add this line in your options.xul file inside the prefwindow tab:
<script type="application/x-javascript" src="chrome://extension_name/content/options.js" />
where options.js will be your javascript code you will use for
this options window
Hope I helped...
I have a representation that contains a list of items. This could easily contain several hundred items.
<List>
<ListItem>...</ListItem>
<ListItem>...</ListItem>
...
<ListItem>...</ListItem>
<ListItem>...</ListItem>
</List>
For each item I want to provide a set of links that are available. Of the set of links, each item may only be allowed to access a subset of those links depending on some condition.
The following example demonstrates a brute force way of doing it.
<List>
<ListItem Id="345">
<Link rel="foo" href="http://example.org/List/Items/345/foo"/>
<Link rel="bar" href="http://example.org/List/Items/345/bar"/>
</ListItem>
<ListItem Id="346">
<Link rel="bar" href="http://example.org/List/Items/346/bar"/>
</ListItem>
<ListItem Id="347">
<Link rel="foo" href="http://example.org/List/Items/347/foo"/>
</ListItem>
...
</List>
Here is an alternative way
<List>
<ListItem Id="345" AvailableRels="foo bar"/>
<ListItem Id="346" AvailableRels="foo"/>
<ListItem Id="347" AvailableRels="bar"/>
...
<Link rel="foo" href="http://example.org/List/Items/{Id}/foo"/>
<Link rel="bar" href="http://example.org/List/Items/{Id}/bar"/>
</List>
The second approach looks much cleaner, it requires more intelligence on the client to deal with the URI template. The second is obviously much smaller to transfer over the wire, however, I am doing HTTP compression, so should I really care?
Thoughts? Are there other issues that I am missing? Is the AvailableRels idea a bit too non-standard? Is there anything like that in other media types?
If you're simply looking to reduce the size, consider including a 'self' link to the representation as a whole (which must be absolute), and declaring that all relative links are relative to it in your media type or protocol spec. (This is how Shoji does it) Then your example shrinks to:
<Link rel="self" href="http://example.org/List/Items/"/>
<List>
<ListItem Id="345">
<Link rel="foo" href="345/foo"/>
<Link rel="bar" href="345/bar"/>
</ListItem>
<ListItem Id="346">
<Link rel="bar" href="346/bar"/>
</ListItem>
<ListItem Id="347">
<Link rel="foo" href="347/foo"/>
</ListItem>
...
</List>
Both of these are in some new media type, so I guess that you get to define the processing models for both of these. The natural instinct is to go with the first one, since it doesn't add the invisible coupling between an attribute in one area of the XML and a URI template in some other place.
Prior art to guide us would be e.g. atompub or sun cloud API, both of which expose an enormous number of links, often repeating. I's just want to point out that OpenSearch could be handed as evidence for the URI template approach, since it exposes URI templates and special <Url> and <Query> elements that have element names matching the braces of the URI template. I personally consider OpenSearch templates very RESTful. Also plain HTML forms do something of the same, and can't not be considered RESTful in their base form.
The downside of providing URI templates is that you can't easily partition half of your items to have a href that goes to server A, and another that goes to server B, or that the different halves actually have different places. You're actually leaking something about the underlying data structure to your clients, and the clients therefore become dependent on all items having the same(ish) URI scheme for accessing foo or bar, making it all less flexible (perhaps depending on how you document the media type in question).
Looking at your representation I am finding very striking resemblance to Atom Syndication Format, which does this using atom:entry and atom:link. To be honest I am at an awe with Atom Syndication Format (ASF).
The RFC for ASF https://www.rfc-editor.org/rfc/rfc4287
The pagination of entries within ASF - rfc5005
If the RFCs are used your feed would look like -
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title>Example Feed</title>
<link href="http://example.org/" rel="self" />
<link href="http://example.org/before/345" rel="next" type="application/atom+xml" />
<link href="http://example.org/after/987" rel="previous" type="application/atom+xml"/>
<updated>2003-12-13T18:30:02Z</updated>
<author>
<name>Darrel Miller</name>
</author>
<id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>
<entry>
<title>Item 987</title>
<link href="http://example.org/List/Items/987/foo" rel="foo" />
<link href="http://example.org/List/Items/987/bar" rel="bar" />
<id>987</id>
<updated>2003-12-13T18:30:02Z</updated>
<summary>Some text.</summary>
</entry>
...
<entry>
<title>Item 345</title>
<link href="http://example.org/List/Items/345/foo" rel="foo" />
<id>345</id>
<updated>2003-12-13T18:30:02Z</updated>
<summary>Some text.</summary>
</entry>
</feed>
I suggest using this as would give power to the client to leverage standard clients to consume your representation. I personally prefer pagination in accordance with what mogsie mentioned above with ASF. Once pagination is in place I would suggest the standard HTTP stuff to improve performance:
Set HTTP Cache related headers in the response so that clients can use them to cache responses
Use a Cache server (Squid, Varnish) in front of the Application Server to reduce generating feed everytime.
Support compression, i.e., support both plain and compressed content depending on client capabilities.
What about just introducing pagination, if you're worried about raw resource size?
<List>
<Previous href="http://example.org/List/before/345"/>
<Next href="http://example.org/List/after/987"/>
<ListItem Id="345">
<Link rel="foo" href="http://example.org/List/Items/345/foo"/>
<Link rel="bar" href="http://example.org/List/Items/345/bar"/>
</ListItem>
...
<ListItem Id="987"> ... </ListItem>
<List>