Project

General

Profile

Actions

Feature #14127

closed

FE-Editing new pages and simulateStatic

Added by Peter Niederlag over 20 years ago. Updated almost 11 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Backend API
Target version:
-
Start date:
2004-04-29
Due date:
% Done:

0%

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

Description

If you do FE editing, and create a new page, TYPO3 generates a backurl
to lead you to the page just created. It does this by appending
&id=yxz to the URL you came from. Works fine...

.. unless you use simulateStatic. Then you get something like
mypage.html?id=xyz, which obviously cannot work.
We 'hotfixed' this by adding this to .htaccess:
RewriteRule ^[^/]*\.html&id=([0-9]*)$ /t3cebit/index.php?id=$1 [R,L]

Problem(?):
TYPO3 first sets $this->id according to the GPVars, and then starts
parsing the path. If the path resolves to a valid pageID (or
page-alias), $this->id is overriden by the resolved one.

Solution(?):
What I did is see
if the GPVar 'id' is set, and if so, just use that one, and don't even
look at the rest of the path. This really doesn't qualify for a
beauty-contest, but it worked fine...
(martin Polestra/real_url)

thx to Karsten D. & M. Stucki for getting on it again
(issue imported from #M36)


Files

0000036-class.tslib_fe.php.diff (776 Bytes) 0000036-class.tslib_fe.php.diff Administrator Admin, 2004-04-29 16:56
0000036-class.tslib_fe.diff (1.45 KB) 0000036-class.tslib_fe.diff Administrator Admin, 2004-06-21 14:44
0000036-class.tslib_fe-bug-36.diff (817 Bytes) 0000036-class.tslib_fe-bug-36.diff Administrator Admin, 2005-03-08 16:05
0000036-db_new.php-bug-36.diff (1.11 KB) 0000036-db_new.php-bug-36.diff Administrator Admin, 2005-03-08 16:52

Related issues 1 (0 open1 closed)

Has duplicate TYPO3 Core - Bug #14298: RewriteRule "Feature"ClosedIngmar Schlecht2004-08-31

Actions
Actions #1

Updated by Michael Stucki over 20 years ago

This patch should do the trick but I didn't test it.
Please give me your feedback, thanks.

Actions #2

Updated by Karsten Dambekalns over 20 years ago

I tried the patch, applies just fine, but doesn't help. I tried to add a new page, and got redirected to this: partnerbereich.html&id=137. Which gave me a file not found.

Now, why? See the '&' sign - if I change this to a '?' it works, which is obviously the right thing to happen. So the patch does what it is supposed to do, but the URL is still constructed in a wrong way.

There is a check needed, whether there are already some parameters in returnUrl or not, and decide on the use of & or ? depending on this.

Actions #3

Updated by Michael Stucki over 20 years ago

Let's get on this again...
Karsten, I think your problem doesn't have to do with this bug since we just check if the ID or the type is already set or not. The patch does nothing more, it just checks first.

Can you please confirm? BTW, attached is a new version of the patch (I noticed that the same thing didn't work with RealUrl, should be fixed now - can anybody using RealUrl please confirm this?)

Cheers, michael

Actions #5

Updated by Karsten Dambekalns over 19 years ago

Finally (it's CeBIT time again :), I was at this again. The Provided patch indeed gives an id parameter higher priority than the id embedded in the simulated file name. So this part of the problem is solved. I attached a new patch (...-36.diff) matching 3.8.0-dev CVS, in case anyone wants to test this further.

Still, the returnURL is generated wrongly. I'm looking into this.

Actions #6

Updated by Karsten Dambekalns over 19 years ago

I uploaded a second patch for db_new.php. It checks the submitted returnURL for a simulatestatic URL, and parses that into a "classic" URL, to which the new id can be appended without problems.

The parsing of the static URL is done like in tslib_fe (grabbed the code from there). I quickly checked that it works, but firther testing is probably advisable.

Actions #7

Updated by Chris topher about 15 years ago

This issue is open for more than5 1/2(!) years now, the last3 1/2 of them without any feedback.

Simulatestatic has inbetween been massivelly changed (it is no longer "in" the core, but a seperate sysext etc.).

So: Is this one still valid?
If not, I propose to close it...

Actions #8

Updated by Benni Mack almost 15 years ago

Christopher, can you reproduce this issue? I will try to reproduce it in the next few days. If it's not reproducable anymore, we can close it.

Actions #9

Updated by Christian Kuhn over 14 years ago

I'm unsure if I did everything correctly, but I think I'm unable to reproduce this anymore.

Actions #10

Updated by Alexander Opitz about 11 years ago

  • Status changed from Accepted 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 #11

Updated by Alexander Opitz almost 11 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