Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
The PHP docs clearly mention this since 5.0.5. Why Drupal was wrorking with previous versions? Mystery. But 5.2 seems to have brought this up.
There was another issue out of this but that was too littered.
Comment | File | Size | Author |
---|---|---|---|
#40 | session.inc.patch_5.txt | 646 bytes | magico |
#28 | remove_sess_write_close.patch | 782 bytes | chx |
#27 | session_2.patch | 1.55 KB | jhm |
#18 | sess_patch_47 | 632 bytes | Arto |
#2 | sess_patch_0 | 702 bytes | chx |
Comments
Comment #1
chx CreditAttribution: chx commentedBefore I forget. Can this break something? Unlikely. If you have an object that changes $user in the destructor or save something into SESSION then that will break, but objects especially objects with destructors (ie. non stdClass objects) is alien to Drupal world. This matter because we will need to port this back to every Drupal we care of.
Comment #2
chx CreditAttribution: chx commentedSome sneaky chars in my patch which are invisible to my editor :(
Comment #3
AjK CreditAttribution: AjK commentedsubscribe to issue
Comment #4
chx CreditAttribution: chx commentedForgot to say thanks for ajk who did a lot of gruntwork and uptimebox who lended access to a broken box.
Comment #5
AjK CreditAttribution: AjK commentedOK, I went through the old issue and where people stated that certain things weren't fixed by this patch (notably cron and update.php) I tested this patch and it worked ok. So that's good.
For those that said "it didn't work in other places", sorry I could not test that, not enough information! So, if you are going to reply to this issue please be verbose and give us pages that don't work. One liners that say "didn't work" aren't helpful to debugging / testing.
Comment #6
NaX CreditAttribution: NaX commentedHave you guys looked at this http://www.php.net/manual/en/function.session-write-close.php#54838 for the
file_transfer($source, $headers)
function. When a user is downloading large files the session is locked and all other pages wait for the page to finish downloading.I think we need to call
session_write_close();
before the file start downloading.Comment #7
chx CreditAttribution: chx commentedNax, that's a whole different issue.
Comment #8
fagothanks chx for your patch. I've tried it and it seems to work fine.
I had tested the same line, but I had this line in the index.php after the drupal_bootstrap(). Presumable this was too late, so I had problems with this.
I'm using this now and I'll report if any troubles occur again.
Comment #9
satori1984 CreditAttribution: satori1984 commented+1
Just subscribing.
Comment #10
chx CreditAttribution: chx commentedIf fago, the original reporter also says it's OK (and ajk did a very through testing on an also known-to-broken box) then we are good to go.
Comment #11
laura s CreditAttribution: laura s commentedAssuming this will not work for 4.7.... subscribing.
Comment #12
AjK CreditAttribution: AjK commentedOnce this goes into HEAD we'll backport the fix to 4.7 (and maybe 4.6)
Comment #13
satori1984 CreditAttribution: satori1984 commentedlaura s: I've manually merged this patch with my 4.7 session.inc and everything seems to be in order.
Comment #14
jhm CreditAttribution: jhm commentedI am one of those who CAN reproduce the behavior every-time under
Mac OS X 10.4.8
Apache1.3
PHP5.2.0 (www.entropy.ch Release 3)
MySQL 5.0.24a-standard
but only when using the mysql driver. The problem goes away as soon as I specify the mysqli driver.
Therefore I am dubious that the proposed "patch" to register a shutdown function in sess_read is the right approach.
My 2cents.
Comment #15
drewish CreditAttribution: drewish commentedthis patch fixed it for me.
Comment #16
fagoby using mysqli the issue doesn't occur, because of the mysqli db layer of drupal, which does already address this problem the same way
Comment #17
fax8 CreditAttribution: fax8 commentedI was having that problem. this patch fixed it.
Fabio Varesano
Comment #18
Arto CreditAttribution: Arto commentedAttached is Karoly's patch rolled against DRUPAL-4-7. Fixed the issue with Drupal 4.7.4 running on PHP 5.2.0 + Apache 2.2.3 + MySQL 4.1.20.
Comment #19
drewish CreditAttribution: drewish commenteda bit more feedback: i applied the fix by hand to two 4.7 sites, one running php 5.1, the other php 5.2. both are working fine now.
Comment #20
jhm CreditAttribution: jhm commentedindeed, adding the snippet from database.mysqli.inc:db_connect to database.mysql.inc:db_connect solves the issue.
So my question is, why adding the same patch to a different file (session.inc)? Doesn't that mean that session_write_close is getting called twice if I apply the patch AND use mysqli?
Comment #21
chx CreditAttribution: chx commentedComment #22
drummCommitted to HEAD.
Comment #23
Arto CreditAttribution: Arto commentedPlease also apply the patch in #18 to the DRUPAL-4-7 branch.
Comment #24
FiReaNGeL CreditAttribution: FiReaNGeL commentedJust encountered this problem by upgrading to latest WAMP on test box (contains PHP 5.2.0) in drupal 4.7. The patch in #18 fixed the problem.
Comment #25
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedapplied
Comment #26
Veggieryan CreditAttribution: Veggieryan commentedthis works for me as well on latest WAMP5 on windows vista
Comment #27
jhm CreditAttribution: jhm commentedafter discussion this on #drupal-support, I created a new patch file that adds register_shutdown_function to session.inc:sess_read and removes same call from database.mysqli.inc:db_connect.
This patch file is for drupal4.7.4. It shouldn't be hard to create one for drupal5.beta-1
Comment #28
chx CreditAttribution: chx commentedNo need to two pieces indeed... your patch moved it to sess_read for 4.7 but that's already committed. Please apply this patch to 4.7 and HEAD too.
Comment #29
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD.
Comment #30
arthurf CreditAttribution: arthurf commentedJust wanted say thanks for this patch, it saved my hide when my host updated!
Comment #31
Firewolf CreditAttribution: Firewolf commentedThere is still a problem when trying to attach a file. When a file is selected and the submit button is pressed, I get kicked out of the system. The problem with PHP 5.2.0 is not completely solved.
Anybody looking at this?
Or is this issue handled in another node as this problem is likely to be in the upload module?
Comment #32
ceardach CreditAttribution: ceardach commentedI applied only patch #18 and was able to remain logged in and upload files.
My system is:
Apache/1.3.37 (Unix)
PHP/5.2.0
Comment #33
Firewolf CreditAttribution: Firewolf commentedOK, my file uploading problem is solved too.
The problem was the combination of 2 patches. I removed the very first patch which was issued for this problem.
Currently only using patch sess_patch_47 and everything is working fine again.
Comment #34
thepeter CreditAttribution: thepeter commentedHi someone told me that this patch could help me with problem decsribed here (imce upload files problem) I have applyed this patch but nothing has changed and by checking the uploading attachments for node also doesn't work. drupal is 4.7.3 php is 5.2 apache 1.actual (don't know precise version) and Iam using mysqli extension
Comment #35
webchickI think this is the right status.
Comment #36
inforeto CreditAttribution: inforeto commentedSubscribing.
Comment #37
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedif there is no work neccessary RTBC is IMO the right status. applied
Comment #38
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedif there is no work neccessary RTBC is IMO the right status. applied
Comment #39
magico CreditAttribution: magico commentedSubscribing, so it can be ported to 4.6.x
Comment #40
magico CreditAttribution: magico commentedHere it is. I've tested and it seems right.
BTW: can someone create a 4.6.x-dev please? Thanks
Comment #41
magico CreditAttribution: magico commentedI received the following message:
Marking this RTBC.
Comment #42
magico CreditAttribution: magico commentedComment #43
Mguel CreditAttribution: Mguel commentedAs mentioned at:
Troubleshooting FAQ > Login problems on PHP 5.2
I applied patch at:
http://drupal.org/node/93945#comment-155161
which is comment http://drupal.org/node/93945#comment-155161>#27 of this thread.
After applying the patch the problem persists when using Firefox 2.0. With konqueror I don't have the problem, but I'm not sure if it is because of the patch, or it worked before (I didn't test it with konqueror before applying the patch).
Thanks,
Mguel
PS: shoudn't apache be restarted after applying the patch?
Comment #44
relyod CreditAttribution: relyod commentedI manually applied this patch to my system (freshly installed 4.7.4) For less php-aware users, can we roll a 4.7.4 version of this
patch, since the patch didn't want to apply since it was from the 5.0beta branch ?
Also, to the poster who asked "why previous versions worked", the answer is probably that they were using an earlier version of PHP, since I first saw the problem after updating PHP, rather than after updating Drupal! - Luckily I updated PHP on my test system first, rather than on a production system, of which I have several
Comment #45
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedthis patch is already committed for 4.7 and will appear in 4.7.5.
Comment #46
magico CreditAttribution: magico commentedCan someone look at #40? It has a small patch needing some commit...
Comment #47
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedappleid to 4.6
Comment #48
Chill35 CreditAttribution: Chill35 commentedWhat behavior is this supposed to fix ?
Comment #49
(not verified) CreditAttribution: commentedComment #50
ChrisKennedy CreditAttribution: ChrisKennedy commentedI upgraded a site running on PHP 4.3.11 from 4.7 to 5.0 only to find myself completely unable to login. I checked and no rows were being stored in the sessions db table. This was pretty disturbing and after experimentation with numerous cookie/domain setting combinations, I have discovered that commenting out this change fixed the problem.
This might also be causing the issue at http://drupal.org/node/108663#comment-182479
Comment #51
kweisblatt CreditAttribution: kweisblatt commentedI have no idea how to apply this. I have applied patches using cygwin before with specific files, but this is over my head.
Any help is appreciated.
Comment #52
asimmonds CreditAttribution: asimmonds commentedReverting title
Comment #53
Clemens CreditAttribution: Clemens commentedManually applied patch in #40 to 4.6.5 session.inc for a perfect fix...
Thank you Magico
Comment #54
shayne1012 CreditAttribution: shayne1012 commentedI got to this page one way or another, but my problem is with Drupal 6.14. I keep getting kicked back to the login form whether I put in the right login information or not. It never seems to register. It worked fine for months and now I can't access the admin at all. I think that it has to do with the session in some way or another like this issue, but there is not a patch for drupal 6.14 for this.
Where should I start?
Comment #55
siva.thanush CreditAttribution: siva.thanush commentedHi,
I am new to drupal.
I installed drupal6 in karmic koala,using apache.
I started working too.But never used mysql(not yet started using databses.)
I create pages etc,etc...
Now i got a problem, I logged out and tried to login again i get the screen of anonymous user and saying that
" Access denied You are not authorized to access this page."i searched to fix this problem and browsed
many forums but could nt get what i need.I hope there is no problem with mysql.
i.e.,i cannot enter in the admin window pls someone help.
-THANKS AND REGARDS
Comment #56
Heine CreditAttribution: Heine commented@ #55 - you replied to a closed report about a very specific bug. Please open a new topic.
Comment #57
DocDJ-forum CreditAttribution: DocDJ-forum commentedUsing Drupal 7, Windows 7 Pro X64, Apache 2.4, PHP 5.6, MySQL. I can login from a remote system using either FF or IE. I can login locally (the system that owns the site) using FF, but IE "ignores" the userid + password that works on the other scenarios. The ID & pw I am using is an administrator account. The site is new and thus has no content.
Any other tips to try?
regards,
DJ