Hi
I have a number of links on my menu (using Moodle 2.02+) that I would like to open in a new window as they are external links. Some I don't want to open in a new window as they are part of Moodle.
Is there anyway I can do this?
J.
Ignore me - solved it.....
<mod - delete thread if you wish>
What was your solution? I'm trying to do the same thing.
Hi,
You can force a menu link in the custom menu to open in a new window by adding the following when editing the menu in theme settings page.
EXAMPLE:
Moodle|http://moodle.org" target="_blank
Mary
Hi Mary,
That solution worked fine for the top level of menu items but any links in dropdowns open in new windows under the original. Have you any suggestions how to prevent this?
Cheers
Dave P
Moodle|http://moodle.org" target="_blank
-Moodle|http://moodle.org" target="_blank
--Moodle|http://moodle.org" target="_blank
Thanks Mary,
The problem seems to be in IE (surprise surprise) as Firefox opens the links in new tabs. I haven't tried Chrome yet. Using IE8,
Moodle|http://moodle.org" target="_blank works fine
-Moodle|http://moodle.org" target="_blank opens a new window but beneath the parent window
--Moodle|http://moodle.org" target="_blank opens a new window but beneath the parent window
Addendum: Interestingly, right clicking and selecting open in new window produces the same results ... its obviously an ie8 problem!
Cheers
Dave/Mary,
FF is also opening in a New Tab instead of a new window. I upgraded FF a short while ago, perhaps it is a function of the newer versions.
- John
Hi,
Isn't this governed by how you set your browser up?
You have to tell your browser how to work. So if you have set it to open links in new tab it will do that regardless of whether or not you declare it to open in a new window in your HTML code, which is what you are doing in the menu.
I may be wrong...but I personnaly think that things like this are not an important issue, as every one can set up their browser to work differently, so I don't really see the need to make more work for yourself.
Cheers
Mary
Hi Mary,
I am using email as an extension to Moodle. I don't want to make students leave their course in Moodle (and their current location/progress) to view or send email.
Sure, a new tab vs a new window isn't perfect, but the new tab works quite well and allows users to have their email open in a separate tab while working in Moodle and vice-versa.
Here is the change to profileblock.php under /theme/aardvark_postit/layout
<li><a href="<?php {
if ($hasemailurl)
echo $PAGE->theme->settings->emailurl;
} ?>" target="_blank">
<img src="<?php echo $OUTPUT->pix_url('profile/email', 'theme')?>" /> <?php echo get_string('email','theme_aardvark_postit');?></a>
</li>
The actual change is on line 102, bold and red above for emphasis. Be sure to include the space after the quotes and before target. Placement and spaces are critical, so be careful. I've included a few lines before and after for context.
When uploading the file, be sure to upload as BINARY, not ASCII or your Moodle will crash ;)
Simple. Now users don't have to lose their place by leaving a course to check their email.
- John
Why not just educate them to right click on their link and select New Tab/New Window if they want to - some users may be finished on their course before going to their email and not need to keep it open. By forcing the issue you remove the user choice which they had previously?
Just my 2p worth
Hi John,
I left you to fathom this out...and sure enough you got it correct.
My FTP is very old but it knows the dif between ASCII & BINARY thank goodness...some you have to tell.
Thanks for the patch...
Cheers
Mary
Glad to contribute, even in this very small way.
FYI. The latest version of Filezilla (which I don't like, but needed recursive deletes and permissions functions) DEFAULTS php files as ASCII (!) so 'auto' didn't upload it correctly.
It can be changed in the settings, as can the Transfer method be manually set to BINARY.
- John
HI JC,
For my benefit, can you tell me what the problem is with the uploads? My Filezilla (on a Linux system) is just set to the normal defaults and i have never had any problem with any uploads crashing Moodle, or any other site. I have never had to reset the transfer method manually to Binary.
Just checked, and as you say, php, html etc. files are transfered as ASCII, but this seems to make sense to me as they are not executable binary files anyway.
Thanks,
Richard
Hi John,
Just to put you straight about this John. PHP files should be treated as TEXT and therefore should be uploaded via FTP as an ASCII file.
Binary files are for images and media, not text.
Are you sure you have this the right way round?
Cheers
Mary
Hi Mary,
Thanks for the question. When the file is uploaded as ASCII, while the theme is installed and active, and the file is simply uploaded in-place, Moodle generates a parsing error if a Moodle page is opened or refreshed.
It *may* be related to how the server is treating php files as executable only (otherwise visitors could view and download your php files). I don't have a way to distinguish between them.
It may be possible that if a theme is deactivated (switch to another theme), the file can be uploaded as ASCII, then re-selected.
About ASCII vs BINARY for FTP. Generally speaking, both can be uploaded as BINARY and will be okay. But you can't normally upload an executable file as ASCII.
"When in doubt, use BINARY"
The most notable exception I know is .htaccess files, which must be ASCII.
And now that I've said all that, I'll qualify the statements with "it depends" Some server and some ftp servers and even some clients handle file differently, YMMV
You're more than welcome to check it on your server. I'd be curious of your results. Just be sure to have a backup file handy- just in case
- John
Hi John,
I think my server (a standard linux/Apache/MySQL/PHP local host) - and my hosted webserver, must be setup differently to yours in some way.
Although I am not in anyway an expert on these technical issues, I am frequently, when developing work on themes, uploading and working directly on php files through FileZilla on the active theme (because I need it there on screen to check the changes being made) I simply upload files (as ASCII/default), refresh my browser and the changes are there. Sometimes I do this by using the view/edit directly in FileZilla, but sometimes, particularly with bigger changes by downloading the file to my local pc making the edits and then re-uploading it. I've never experienced a parse error through moodle or any other website by working in this way.
My workflow does not involve having to change theme away from the one I am working on while uploading edits and then changing back to see them. Neither have I changed any default settings in my FTP (FileZilla) which as you have previously noted treats php,css and html files all as ASCII transfers.
But reading your comment, it would seem that in developing a theme, I would need to upload my theme, check it. If there are edits to be made to a php file, I would then need to go to theme selector to choose another theme, making the one I am working on 'inactive', make my edits, reupload the necessary files, go back to theme selector and reselect my theme. Alternatively I would have to set up my ftp program in a different way to normal/default for working with moodle?
I have to say, this is NOT my experience and I believe would be considered a major bug/flaw by any developer trying to work on themes if that were the case. It would surely also affect the whole of moodle development as so much is built on php and would therefore be 'active' when making edits and changes? I would like to hear from any other developers who have found this error when uploading php files to an active theme - do I have my server setup differently to standard somehow that makes this work? As far as I am aware, I have always installed my local host and everything associated with it, simply with the standard default settings. Or, John, can you provide some specifics of the error you have come across when working this way. And please, take this from the point of someone who is doing his best to learn more about the systems and development and not from someone who is being critical in any way
Again, I am asking for my own benefit and learning - but I was under the impression that a php file is not an executable file as such (e.g. a program .exe file or similar, and it certainly isn't an image/media file as Mary rightly points out)- I don't have the executable bit set in file permissions of Read/Write/Execute, in fact for most users, the files are set to read only- but is a text file which is read and parsed by the server into the html which creates the page itself. Although as these files then become the html viewed by visitors to the site, I cannot see how the php files are downloadable by site users if they are not set as executable? If I visit my own site as a user, then what I see, even by viewing the page source, is the html for the page and not the original php file.
Richard
I think FF has been doing that (opening in a tab) for a while - unless you specifically right click and tell it to open in a new window - but as Mary said, I don't think this is a problem (IE opening under existing windows might be, but that's an IE issue not a website coding one - moodle or otherwise).
Richard