How do you do relative links within text editor component? Adobe AEM doesn't like when I use relative links to external pages by default. It strips them out and shows the broken link symbol.
I strongly recommend you to uncheck Disable Checking in Day CQ Link Checker Transformer.
Be aware that It's your responsibility to ensure all links are valid:
Completly disable all link checking. All links are handled as valid.
This is something you want to check with your team (Devs, TAs...). It may work on your local environment and it will fail in QA, UAT and PROD as this option is not checked.
Disabling the link checker might not be a good idea as Content Authors may add broken links, which It'll break user navigation throughout the site if this is not picked during testing and regression testing.
Regarding paths, relative paths are those within the environment you're in. For instance,
/content/dam/geometrixx/banners/banner-mono.png
is a relative path, however path to Stack Overflow is outside you environment therefore is external. In order to be valid, you need to provide the full URL including the scheme, either http, https, ftp, ftps and so on. A valid external URL would be:
http://www.stackoverflow.com
More info about URLs can be found here.
While disabling the link checker will work, I'm not sure how you are referencing external websites by relative link. Relative links are on the same domain by their nature. Can you give us an example of what you mean?
The other problem with disabling the link checker is that the production deployment will likely have the link checker turned on. In this case your code will break again. You probably don't want your client/boss/whatever upset about that.
Relative links can be made to work just fine with the linkchecker. Can you post some example links? I can help you make things work properly.
This issue is quite common, if you have URL's (paths) in your domain that are NOT served by AEM. This can be files directly served by the Apache (e.g. robots.txt), Servlets creating dynamic redirects (e.g. language switcher) or another application (e.g. web shop under /shop).
First solution is to mark an individual link for the link checker as valid. Therefore you can add the following attribute to the link tag.
x-cq-linkchecker="valid" - link is marked as valid, without any
check
x-cq-linkchecker="skip"- link is ignored by the link
checker, and remains as is
e.g. Shopping Basket
Second solution is to configure special-threated link patterns in the OSGi config of the “Day CQ Link Checker Service”. In case you have a second application in the same domain, then you can specify regex-patterns matching the links to this second application. User either “Link Check Override Patterns” (not checked, but rewritten) or “Special Link Patterns” (not checked and not rewritten).
Example configuration that only links to /content/* are verified. Links that not matching ^/content/.*$ are threated as valid:
<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0"
jcr:primaryType="sling:OsgiConfig"
service.special_link_prefix="[javascript:,data:,mailto:,#,<!--,${,tel:]"
service.check_override_patterns="[^system/,^(?!/content/).*$]"
/>
Fixed my issue in /system/console/configMgr# > Day CQ Link Checker Transformer > Check "Disable Checking" box.
Relative paths now work.
Related
Below is some info to have context about the problem I am looking for solution:
"I only want to have a prod environment for contentful. the preview url is being used for UAT and Dev environments. So if the content is in the draft it will be reflected in Dev and UAT and when published it will be reflected in both environments as well as Prod".
Now the issue is there are some links in content that has a prod domain like www.[prod-domain]/blah blah, I need those URLs domain to be replaced with UAT or Dev domains in the draft (depending on environment) like www.[UAT-domain].blah blah
Is there any middleware for this? if not, what's the best way to achieve this in-app?
Salma from Contentful here!
If you use relative links in the content (e.g. /blahblah), they would automatically resolve to the current domain when navigated to on the front end.
If you're using Rich Text and outputting links in the flow of the text, you could get around the protocol requirement in the usual link formatter by creating a custom 'internal link' entry content type, which you can embed as an inline entry. For this content type, you could ask editors to provide a path to a page without the https protocol and domain, and ensure there is validation for that in the web app (using the pattern validation).
Another option would be to remove the protocol and domain from the urls when rendering on the front end to avoid the editors having to create extra entries when adding content to the Rich Text field.
Whilst in development on a temporary subdomain I had robots set to No Index, No Follow in the Joomla 3.6.4 Global Configuration.
After moving the site to its permanent home I changed the settings to Index, Follow but, all the pages are fine, except the home page, which is still showing (when source is viewed) meta name="robots" content="noindex, nofollow"
I have changed the menu item to 'Index, Follow' rather than 'use global' and, when that made no difference, also did the same for the single article which is assigned to that page. Still no change. It doesn't change on the original development site version, either.
This is a template that I have used many times before: I keep a basic copy with some global tweaks that I have made and then adapt it for each new site. I can change the robots meta tags on this original template with no problem.
I have no SEF plugins. The only SEF tool is the System - SEF.
I have checked all the template files over and over and I am now about to tear my hair out.
Any suggestions gratefully received.
(p.s. can someone with a better reputation than me please add a Joomla3.6.4 forum tag?)
I want to stress test a system based on Apache Wicket, using grinder.
So what I did was that I used grinder's TCP Proxy tool to record a test session in my Application and then fed the generated test script to grinder to stress test the system; but we found out the tests aren't carried out successfully.
After a lot of tweaking and debugging, we found out that the problem was within the wicket's URL generation system, where it mixes the page version number into its URLs.
So I searched and found solutions for removing that page version number from the URLs (Like this), and used them and they worked and removed those version numbers from the URLs used in the browser. But then again, the tests didn't work.
So I inspected more and found out that even though the URLs are clean now, the action attribute of forms still use URLs mixed with page version number like this one : ./?4-1.[wicket-path of the form]
So is there anyway to remove these version numbers from form URLs as well? If not, is there any other way to overcome this problem and be able to stress test a wicket web application?
Thanks in advance
I have not used grinder, but I have successfully load-tested my wicket application using JMeter Proxy; without changing Wicket's default version mechanism.
Here is the JMeter step-by-step link for your reference:
https://jmeter.apache.org/usermanual/jmeter_proxy_step_by_step.pdf
Basically, all I did was running proxy server to accept web requests from the browser to capture the test scenarios. Once done collecting the samples, then change the target host url to whichever server you want to point to (other than your localhost).
Alternatively, there is another load testing tool BlazeMeter (compatible with JMeter). You could add the chrome browser plugin for quick understanding.
Also, you might want to consider mounting your packages to individual urls for 'cleaner' urls. That way, you have set of known urls generated for pages within same package (for example, /reports for all the reports pages within reports package).
Hope this helps!
-Mihir.
You should not ignore/remove the pageId from the urls. If you remove them then you will request a completely new instance of the page, i.e. you will lose any state from the original page.
Instead of using the href when recording you need to use the attribute set (by you!) with org.apache.wicket.settings.DebugSettings#setComponentPathAttributeName(String).
So Grinder/JMeter/Gatling/... should keep track of this special attribute instead of 'href' and later find the link to click by using CSS/XSLT selector.
P.S. If you are not afraid of writing some Scala code then you can take a look at https://github.com/vanillasource/wicket-gatling.
It seems to be quite basic problem, but I still cannot find a nice solution.
I made a component that uses a dialog property.
How could I avoid setting this property for every single page if this component is used also in template?
What I already have tried:
I set name attribute in dialog.xml to absolute path - Component stops working as standalone (dropped into parsys).
Move it to design_dialog.xml - First of all it's conceptually content, so I do not like such move, and again it doeas not make much sense for standalone versions.
Change resource path to absolute, while including in template:
<cq:include path="/content/site/somepage" resourceType="/apps/portal/components/myComponent" />
For the first look it was almost it. Instances included via parsys has it's own path, and Content for template is fetched from single resource... But where to store it, to make template code independent from pages tree structure?
Is there any other nice way to do so? or at least way to improve 3.?
To the original poster, the functionality you are looking for is now supported by Shared Component Properties in ACS AEM Commons (http://adobe-consulting-services.github.io/acs-aem-commons/features/shared-component-properties.html)
Compared to your suggested solutions:
No need for absolute property path required for SCP
Agreed these are "content" properties, so they should be stored as "content" instead of "design". SCP stores these values under the homepage node of a site, making them as genuine of content as any other piece of content.
Agreed that it is bad to have a template hard-coded to a content path of a single site, especially since this makes a multi-site implementation impossible without creating a bunch of templates. SCP does not have this problem, because each site has its own homepage under which the properties are stored.
If I understand correctly, you have a component which may work in two modes:
it may be included statically in the main page renderer via <cq:include>
it may be also dropped into some parsys.
In the first mode component should have some common configuration for all pages and in the second mode it should be configured separately per-instance. The problem is how to create such common configuration.
I think your 3rd solution is perfectly fine assuming that the component configuration is shared by all sites in your CQ instance. At some point it may be too strong assumption, eg. you may have a 3 language branches under /content/site-en, /content/site-fr and /content/site-de and you'd like to make a separate configuration for each branch.
I'd suggest following improvement to the 3rd solution: you may create the shared component under some relative path which will be the same for all pages, like /content/.../configuration/shared-component (where ... may be site1, site2 or site3). Then take first two parts of the current page path, add the /configuration/shared-component suffix and use <cq:include> to include path created in such way.
You may also take a different approach and create a common configuration page referenced by all statically included components. These components may try to find their configuration automatically (via the relative path as above) or they may have a single pathfield that references configuration page.
If you don't like these options (as they assume some site structure or they need some minimal configuration for each component), consider using HierarchyNodeInheritanceValueMap. It allows you to get property from the current resource and if there is no such property, it'll look into the same resource on ancestor pages. Using this you could configure your component just once, in the site root page and inherit configuration across the whole site.
I'm pretty new to TYPO3 and currently stuck with the following issue:
I copied the templates from another webpage that is currently in business.
When I'm on the startpage of my homepage (www.domain.com) and click on one of the links it contains I always get an error 404. The link that is generated looks like this.
http://www.domain.com/testpage.440.0.html
So I guess something like RealUrl was in use on the webpage that I copied from? Do I understand this right? I don't see that RealUrl is installed though.
However If i manually change this link to
http://www.domain.com/?id=440.0.html
the site is being created.
How does Typo3 know to generate a page when it receives the first version of these two links?
Does not really look like a standard out-of-the-box REAL URL url. That would rather have been /testpage-404.html . So maybe the problem is somewhere else, could be:
simulate static (check if that extension is running). A common mistake is to run real url an simulate static at the same time. If you do not need speaking urls for the moment, just uninstall simulate static.
make sure you add a domain to your shortcut. Use the the list modul and select the root shortcut. Then click create new record, select domain. and enter your domain there. Flush all the caches and try again.
If you'd post your TS Code (of the root shortcut page) here, I could probably tell what's going wrong.
real url configuration typically use .htaccess files.. maybe that file still contains information from the original destination.
check if the root ts contains some baseUrl statement
Which version of TYPO3 are you using?
HTH, but feel free to post more infos.
If your typoscript template is expecting to find realurl and its not installed as a plugin, that could be the cause. You'll need to either install it, or find the settings in the TS template and remove them.
Try the template object browser to look for it (use the template tool, click to the site root, then use the drop down menu in the r/h pane to choose the Template Obect Browser.)
How does Typo3 know to generate a page when
it receives the first version of these two links?
Any page request that it doesn't understand will give a 404 error.