In Joomla (CMS) the installation comes with a file called "robots.txt.dist". I know what robots.txt is used for, but don't know why a .dist version would exist. The install comes with a normal robots.txt which to me seems that makes the other file not needed.
.dist files are usually just an example file to get you going but aren't intended to be used as the real thing.
.dist means distribution. It's just sample of robots.txt. Normally, you should do mv robots.txt.dist robots.txt to set default robots.txt file, to make your website more search engines friendly. But text dist were added to not overwrite your current robots.txt.
Related
I found that there is no plugin for automatic language detection, how to add it?
Can this function be integrated into VuePress to automatically detect the client language and jump to the corresponding multilingual site.
There is an official plugin for it, it's just incredibly hidden and also took me quite some time to find:
https://vuepress.github.io/en/plugins/redirect/
Set "locales: true" and then make sure all files are placed in a language directory inside of the docs directory. So your docs/ directory should only contain .vuepress/ and then more folders for all languages with the same structure:
/docs/.vuepress/
/docs/en/
/docs/de/
/docs/pt/
/docs/zh/
[...]
I'm using a shared 1and1 package for a Magento website and it seems I can't use the standard approach of compressing css and js files via htaccess. I came across this http://mrrena.blogspot.co.uk/2009/01/how-to-compress-php-and-other-text.html which gave an interesting approach which seems to work. However, I need to put a php.ini file in every directory that has css or js files that I want compressed. For something like Magento, this is quite a pain. Is there any way I can use a hierarchical approach such as with htaccess?
I discovered the .user.ini file which does precisely what I want. So now I have a single .user.ini file in my root folder and I've removed all of the php.ini files.
See here for some detail: http://php.net/manual/en/configuration.file.per-user.php (none of the online documentation I could find on .user.ini was particularly good).
The tutorial http://sinnerinc22.blogspot.de/2010/07/adding-syntax-highlighter-to-jamwiki.html describes how to enable syntax highlighting in JAMWiki.
My problem is that in the recent version of JAMWiki v1.2 the two files to be modified WEB-INF/jsp/top.jsp and WEB-INF/jsp/close-document.jsp do not exist any longer...
There is a third-party syntax highlighting tag extension available with JAMWiki 1.2 link that may work for you
I have added SHJS to my installation just following SHJS instructions rather than JAMWiki instructions. Simply edit JAMWiki JSP pages to add content as documented here. To see how does it work, look into the source code of this HTML document.
You even do not need to compile anything after you edit JSP, the server does this for you automatically.
Following up on Audrius's answer, here's exactly what you need to modify.
./jamwiki.war/WEB-INF/jsp/topic.jsp Modify it to look like this
Download the SHJS zip and copy all of the individual files from ./css/, ./lang/, ./sh_main.js, and ./sh_style.css from the zip to JamWiki.war/shjs/. (This will flatten the directory structure so everything is now in ./shjs/. Flattening the structure is optional but it makes for easier paths when referencing them in the jsp.)
You can modify the .war with 7zip or dig into your web app container file system and place the JSP and shjs folder directly.
Redeploy or refresh as needed depending on your preferred edit method.
The system folder, img folder, css folder and js folder contain codes that unrelate to the content of the website. Should we disallow them in the robots.text ?
Disallowing directories using a robots.txt file means that :
Their content will not be indexed by major search-engines
If those file have content that's not related to your website, and/or should not be returned in searches, you can do that.
But their content will still be available to users
robots.txt is just an indication to crawlers -- and absolutely not a way to forbid access to anyone.
First, it's robots.txt, not robots.text.
Second, CSS files and Javascripts won't ever be indexed anyway, and images are usually not indexed directly, they are indexed when they are found in a page, and the system folder shouldn't even be accessible via the internet.
Finally, as Martin said, the robots.txt file is only a recommendation to search engines, they need not follow it (though typically the big ones do).
By default, the system folder in Codeigniter is not accessible to the users so you should't worry about that.
Just as Andrew wrote, the contents of the img, css and js folders will not be indexed by search engines so you should't worry about that either.
However, if you have any reason to block the contents of the above files for the search engines, you can do that without any worries that your site's rankings and visibility will be affected by this.
Here's a SEO recommendation that Google gives: Seo Fact no. 19.
I am currently developing a joomla 1.5 based site in a temp subdomain (which points to a subfolder on ther sever where all joomla stuff is installed). Currently I am using plugins joomgallery an kunene 1.0.9 (legacy mode).
Once the development is done I would like to move the whole site into the root directory and delete the whole subdomain. How would this ideally be done? Can I just move the files or is there more to it? Any common pitfalls to watch out for? E.g. Are there absolute paths referenced somehwere?
In your configuration.php file, the base path might be defined, something like this:
var $live_site = 'http://temp.mysite.com/';
...though I think by default now, it automatically detects this value for you.
Check in the configuration of your custom components to see if they have got the paths "hardcoded" in there too.
Another thing you could do is set up a .htaccess file with some RewriteRules so that any call to http://temp.mysite.com gets redirected to http://www.mysite.com
There is a free Joomla! extension for this called Joomlapack. Just make a backup with Joomlapack, move the backup files that was created to the new site/folder and run the script that also was created in the backup. Done!
Joomlapack makes a complete backup on both the DB and site files so you can move your site anywhere if you wanted. Joomlapack can be found here: http://www.joomlapack.net/
Make sure to edit your configuration.php file as per these instructions.