I want to have hreflang tags in the source code of a website, created in DNN
I have a website that is multilingual. In order to get a correct mapping for each language a correct hreflang should be present in the head (https://support.google.com/webmasters/answer/189077?hl=en). As you can/have to appoint localized versions of the DNN to a language, I expect that the appropriate hreflang tags are placed. But in the code there is nothing.
I can not imagine that I am the first one encountering the problem. So...how did you solve it? Code or setting?
Tycho,
I agree, there should be a hreflang tag, as it could be easily automated. At the moment I only see the possibility to add a page setting (Advanced :: S.E.O. :: Page header tags).
Maybe opening an issue or delivering a pull request could solve the problem - but it seems you have already done this.
Happy DNNing!
Michael
Related
First off I would like to say your product is amazing! Has made the job of inheriting an old DNN instance a much more intuitive experience.
Apologies if this is really simple thing I'm missing but I'm at a dead end after scouring the docs and internet.
I'm using Evoq content and up until the start of the week the publishing workflow had been working fine rich text WISIWIG fields but it seems something has changed. Now when publishing changes any apps that are embedded in rich content fields display the demo item when not logged in.
I've recreated the issue on a smaller scale to illustrate the problem:
When logged in it looks as expected - on the left is a button that's placed directly onto the page, on the right is a button inside a rich text field:
logged in
And when logged out:
logged out
As you can see the button that is embedded as a rich text field is displaying the demo item.
I've gone through all of the content items and ensured that they are set to publish and not draft or hide and ensured the page is set to published in DNN.
Aldo I've double checked how the fields are setup but as this was working previously, I'm doubtful that this is the issue but for clarity here is how the fields look in the model:
Rich text field model
And it's rendered to the page using:
#{
var renderSvc = GetService<IRenderService>();
}
#renderSvc.All(Content, field: "BodyContentBlocks", merge: Content.Body)
I've been scouring the docs and internet for hints of what might be going on but the closest I could find was this thread on github but it doesn't seem to be quite the same issue.
Any help would be massively apricated as this issue has cropped up just before moving to our production server (as they always do!) after working as expected for a couple of months. Let me know if you need any more info from me and thanks for your time.
Evoq has a page-workflow feature which is technically undocumented. 2sxc got a sponsor a few years ago who paid for the implementation but there are limitations to it. Some background:
Some data in 2sxc can be clearly assigned to a module or page - such as content added directly
Other data cannot be assigned to a page - such as a blog post
Because of this, the logic is to first determine if something is partOfPage and if yes - and workflow is active - then it will be set to be a draft. This way the end users don't see it.
Upon page-publish, everything that is partOfPage will be published, so the draft will become the live data.
I assume the detection of this was never implemented for inner content - I think inner-content was actually developed later. Because of this, I assume the toolbars for the inner-content-item tell the UI it's part of the page (resulting in draft), but the publish cycle doesn't know about this, since it's internally a sub-entity (which is just like a tag on a blog - not part of a page).
This is difficult to fix. A proper fix would require 2sxc to be modified to make sure that inner-content is never seen as part-of-page, OR that it's taken into account when publishing. Both of these options would probably take ca. 3 days of dev on 2sxc side and would only happen if we have a sponsor.
A workaround is to disable the Evoq-integration so the page publishing wouldn't happen. I believe there is a feature for this - and AFAIK you don't even have to become a Patron (which I highly recommend to support our thousands of hours of work):
Or you could manually try to publish it, but that will be difficult. Note that most of us will be on x-mas vacation so we won't be answering questions till mid Jan.
Summary of options
Avoid inner content for now
Disable Evoq Page Workflow in 2sxc
Manually publish the items (very difficult, needs super-user permissions because it's an unusual thing to publish)
Get some budget ca. 3 days to sponsor the feature https://2sxc.org/contact but wait till end of January
A mix of short-term solution + sponsoring
Sorry for the delay on this, I've been waiting for a decision. I'm going to close the question as we have been able to work around the issue for now with the help of your last comment. Avoiding inner content is working well enough for our use case. Thanks for your time and help and for making an amazing product!
On my Joomla site (www.schoolofthaimassage.com) is see a strange string >>>>> turning up above the top bar.
In firebug I see it shows in body tag
<body id="jsn-master" class="jsn-textstyle-custom jsn-color-grey jsn-direction-ltr jsn-responsive jsn-mobile jsn-joomla-30 jsn-com-content jsn-view-featured jsn-itemid-107 jsn-homepage" data-gr-c-s-loaded="true" style="">
> > > > >
<noscript><iframe src='//www.googletagmanager.com/ns.html?id=GTM-XXXX' height='0' width='0' style='display:none;visibility:hidden'></iframe></noscript>
I can't understand where it is coming from? Can someone help me?
It's hard to say just from looking at the source code.
I recommend trying some or all of the following:
run a back up and upgrade Joomla and all third party extensions to the latest versions
temporarily switch to an alternative site template to see if the issue is related to the currently selected template (maybe a template override is causing the issue?)
temporarily disable third party modules to see if this makes any difference
temporarily disable third party plugins to see if this makes any difference
check the template index.php file to see if it has been manually edited for some reason
scan the website for malware if no other explanation can be found
Whenever i create a contact form in my Joomla! 3.3.6, some script appears in the the page's HTML code that contains many words Joomla in it. I'd like to change those Joomla words and replace them with another words (i.e. Foo) for some security issue. I'd like to know whether or not i'm able to do so and how.
That script is:
<script>(function(){var strings={"JLIB_FORM_FIELD_INVALID":"\u0641\u06cc\u0644\u062f \u0646\u0627\u0645\u0639\u062a\u0628\u0631: "};if(typeof Joomla=='undefined'){Joomla={};Joomla.JText=strings;}
else{Joomla.JText.load(strings);}})();</script>
I have no idea whether a plugin or an extension creates it or not.
Thank you
Regards
This script seems to be translating some text required for the form to use in its javascript, eg validation messages. It does this using a javascript version of JText, which is part of core Joomla. There is some info on how that works here. Weirdly, there seems to be little information in the official Joomla documentation about it.
The main JText function it is calling appears here: media/system/js/core.js
I'm sure it would be possible to write a plug-in to remove this script before the page is rendered and then to translate any untranslated text with your own scripts. However, I'm not sure I see any security benefit in doing this so it seems a waste of time.
Ultimately, someone sniffing a site for what it is built in is far more likely to see if core files exist by going direct to places like media/system/js/core.js, rather than to scan the code for the word "Joomla" - which would trigger a lot of false-positives (any site which just mentions Joomla) and negatives (any page which doesn't have a form on it). It also does not reveal the version of Joomla, which is the info a hacker would more likely be after.
I think you have to search for the script (i.e via Notepad++) in the whole directory. It must be a plugin for the contact form that has some inline script in it.
also do you use any special third party plugin or so? that might be the source of it.
PS: also i had some similar experience, i don't know exactly how i got rid of those words, but like you, i wanted to do that to hide the fact that i'm using joomla for security.
Its actually Joomla who add this, from the file: Joomlainstall/libraries/joomla/document/html/renderer/head.php
And load it globaly from:
Joomlainstall/libraries/cms/html/formbehavior.php
The developer ad that code by using the function, JText, for an example:
JText::_( 'COM_CONTACT_EMAIL_FORM' )
In my case it was the plugin ContactUs Form who add the javascript. If JText is not used, it is not loaded. If I disabled the plugin, the javascript was then not loaded. If you have that plugin enabled, my be try an other contact form?
For security reson it is bad programming by the developer off Joomla, for sure.
I currently have a website i'm working on that I have taken over from another individual, I dumped his SQL file into my database and everything seems to be ok apart from one thing. Whenever I try to log in to the back end or if I try to go elsewhere, it will add an additional .co.uk to the address bar, making it like so:
From: www.domain.co.uk to www.domain.co.uk.co.uk
I've had a dig in the database but I really can't find anything and i've never faced this issue before, could anyone shed some light on this for me? Maybe just let me know where I could look within the database to identify the problem, many thanks.
Take a look at the .htaccess file in the root folder, which is hidden and may contain rewrite rules.
Also, I recommend you use this plugin for migrations:
http://wordpress.org/extend/plugins/wp-migrate-db/
I use it whenever I move from localhost to a live site and vice versa. It will also ensure your widgets are preserved, since doing a find replace will cause the object serialisation syntax WordPress uses to break.
After migrating, you need to visit Settings > Permalinks so the .htaccess file can be updated according to the new URL for rewrites.
I set up an older Rails 2 project on a brand new Apache#Debian#squeeze. The project itself could be a single pager, using links to scroll page up and down. My links look like that:
http://mydomain.com/en/#home
These links do fine as long as JavaScript intercepts the click event and simply scrolls to the intended section. In case the user leaves the single page and opens one where these links (still the same) cannot be followed via JavaScript, I only receive an:
Forbidden
You don't have permission to access /en/ on this server.
If I change the link to:
http://mydomain.com/en#home
everything works fine and as expected. But I do not want to change my link structure. It already worked well at an older Debian5 box.
I expect that to be an Apache2 configuration issue, but do not find anything useful in the net.
Looking forward to any kind of enlightenment.
Thx
Felix
I don't know how or where you are working with javascript related to this problem, but let me tell you this.
Everything after the hashtag # is never passed to the server. Its HTTP standardization, it is just not passed to the server.
It is only intended to navigate to anchor within the webpage, and today used for a lot of new techniques including, but not limited to, xss scripting, javascript hooks, etc
It is possible that links are prohibited to load with an onclick event and some javascript does something instead, but it is not possible that you end up on this page http://mydomain.com/en/#home if http://mydomain.com/en/ does not work.
However to solve your problem you probably have to adjust your your apache rewriting rule (or enable mod_rewrite at all?) to also capture links with trailing slashes.
The link http://mydomain.com/en/ http://mydomain.com/en is something different and could serve a completely different page.
I would strongly recommend not to get a mess here and do a strict permanent redirect from one to the other. Which you choose for primary usage is up to you.
I prefer a trailing slash and can also supply arguments for that, but they can be invalidated easily and replaced by some to suggest the opposite. You should find plenty on discussion on that if you search for trailing slash here.
To solve your problem please try to find the according RewriteRule, copy it and add it one more time with a trailing slash. See whether it works and make a redirect to the url without trailign slash.
You may also edit your answer and post your server config to get help with that.