Project

General

Profile

Actions

Feature #16972

closed

patch for typolink to allow individual windows-targets and -objects

Added by Steffen Kamper almost 18 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2007-02-10
Due date:
% Done:

0%

Estimated time:
PHP Version:
Tags:
Complexity:
Sprint Focus:

Description

All typolinks that has JSwindowParams have hardcoded 'FEopenLink' as target and 'vHWin' as window object.

This patch allows to set in TS typolink configuration:

#take target from parameter
typolink.JSWindow.target='xyz'

#new window-object for each link
typolink.JSWindow.newWindow=1

i choosed JSWindow cause this is known from imageLinkWrap
(issue imported from #M4963)


Files

patch_typolink.diff (1.38 KB) patch_typolink.diff Administrator Admin, 2007-02-10 20:04
patch_typolink_2.diff (1.86 KB) patch_typolink_2.diff Administrator Admin, 2007-02-10 22:17
patch_typolink_3.diff (1.85 KB) patch_typolink_3.diff Administrator Admin, 2007-02-10 22:26
4963_v1.patch (1.48 KB) 4963_v1.patch Administrator Admin, 2010-10-27 17:40
Actions #1

Updated by Steffen Kamper almost 18 years ago

sry, i tested now with all browsers and had to correct a little. Please forget first patch and look to 2nd one.

Actions #2

Updated by Steffen Kamper almost 18 years ago

sry, my tortoise did something wrong, patch 3 is now the actual !

I also changed the vHWin as Masi suggested, cause it's the better way to handle the object.

so param for newWindoObject is now:

typolink.JSWindow.windowVar = myWindowObject

Arghh - my tortoise ... forget last 5 lines with -, i never removed them ...

sry for confusing, this is the change i made:

if ($JSwindowParams) {
$wtarget=$conf['JSWindow.']['target']?$conf['JSWindow.']['target']:'FEopenLink';
$winObj = $conf['JSWindow.']['windowVar'] ? $conf['JSWindow.']['windowVar'] : 'vHWin_'.md5(rand());

// Create TARGET-attribute only if the right doctype is used
if (!t3lib_div::inList('xhtml_strict,xhtml_11,xhtml_2', $GLOBALS['TSFE']->xhtmlDoctype)) {
$target = ' target="'.$wtarget.'"';
} else {
$target = '';
}
$onClick=$winObj."=window.open('".$GLOBALS['TSFE']->baseUrlWrap($finalTagParts['url'])."','$wtarget','".$JSwindowParams."');".$winObj.".focus();return false;";
$res = '<a href="'.htmlspecialchars($finalTagParts['url']).'"'. $target .' onclick="'.htmlspecialchars($onClick).'"'.($title?' title="'.$title.'"':'').($linkClass?' class="'.$linkClass.'"':'').$finalTagParts['aTagParams'].'>';
} else {
...
Actions #3

Updated by Jochen Rieger over 15 years ago

This is a nice patch... I think it could be improved a bit concerning links that are generated by RTE in the following situations:

Imagine multiple content elements on one page having some popuplinks. But the Popups have different sizes. If you click on one link, don't close the popup then open another one (of different size!) then the content will be put into the existing popup of wrong size.

My idea: hashing the target URL to get some unique JS window object name. Something like this:

$jsWindownName = $GLOBALS['TSFE']->config['config.']['uniquePopupWindowName'] ? md5($finalTagParts['url']) : 'FEopenLink';

$wtarget = $conf['JSWindow.']['target'] ? $conf['JSWindow.']['target'] : $jsWindowName;

What do you think?

Actions #4

Updated by Jochen Rieger over 15 years ago

corrected typo and made hash xhtml valid (starting always with jswin)

$jsWindowName = $GLOBALS['TSFE']->config['config']['uniquePopupWindowName'] ? 'jswin' . md5($finalTagParts['url']) : 'FEopenLink';
$wtarget = $conf['JSWindow.']['target'] ? $conf['JSWindow.']['target'] : $jsWindowName;
$winObj = $conf['JSWindow.']['windowVar'] ? $conf['JSWindow.']['windowVar'] : 'vHWin_'.md5(rand());

Actions #5

Updated by Jochen Rieger over 14 years ago

hmmm ... I don't really see the relation to #17968 ... two completely different issues, aren't they?

Actions #6

Updated by Chris topher over 14 years ago

I think so either and have deleted that relation again (some weeks ago already).

Jochen, can you provide an updated version of this patch and post it to Core List?
Than this will finally get fixed!
See here http://typo3.org/teams/core/core-mailinglist-rules

Actions #7

Updated by Jochen Rieger over 14 years ago

@ Christopher:

Yes, I'll do that ... against which version(s) should I patch it?

Actions #8

Updated by Jochen Rieger about 14 years ago

Hey all - wouldn't this one still be worth a patch?

Actions #9

Updated by Chris topher about 14 years ago

Hi Jochen,

sorry for the delay.

Please make the patch against trunk, which you find at https://svn.typo3.org/TYPO3v4/Core/trunk/ .
As this is a feature, this already is enough.

Then send a mail with your patch to Core List. You can find a how to here: http://typo3blogger.de/ab-in-den-core/ (I assume you're German ;)).

If you have any questions, don't hesitate to ask!

Actions #10

Updated by Jochen Rieger about 14 years ago

Hey Christopher,

me too, I completely forgot about this issue. So thanks for your quick answer now after the reminder and thanks especially for the blog post link - very useful!

I modified the code a bit and attached the new patch

4963_v1.patch

I have posted it to the core list.

Actions #11

Updated by Alexander Opitz about 11 years ago

  • Category deleted (Communication)
  • Status changed from New to Needs Feedback
  • Target version deleted (0)
  • PHP Version deleted (4)

Hi,

as this issue is very old. Does the problem still exists within newer versions of TYPO3 CMS (4.5 or 6.1)?

Actions #12

Updated by Alexander Opitz over 10 years ago

  • Status changed from Needs Feedback to Closed

No feedback within the last 90 days => closing this ticket.

If you think that this is the wrong decision or experience this issue again, then please write to the mailing list typo3.teams.bugs with issue number and an explanation or open a new ticket and add a relation to this ticket number.

Actions

Also available in: Atom PDF