So as title suggests, session doesn't start after submitting a form. $_SESSION is null after submitting. There are no errors, and redirect is to the page after successful login. I am pretty sure that is no related to any configuration problem in symfony, simply because I have exact copy on my local machine, and everything works fine.
That's why I think it's related with Apache 2.2. auto-session is off in php.ini. Any suggestions?
You should use the Session Management of Symfony (http://symfony.com/doc/2.3/components/http_foundation/sessions.html)
As stated elsewhere, Symfony Sessions are designed to replace the use of PHP's native session_*() functions and use of the $_SESSION superglobal. Additionally, it is mandatory for Symfony to start the session.
(http://symfony.com/doc/current/components/http_foundation/session_php_bridge.html)
Actually all of that was because of Varnish. I didn't have Varnish for that project, at least I thought so, because I had configuration done wrong, and Varnish was working for both projects (that which I wanted, and which I don't). So I think the problems was with cached form (generally page). I think all of that, because recently I switched off Varnish, and everything working like it should.
Related
I am a bit puzzled on using PHP's session. Are there any specific requirements or conditions to use sessions? From all other forums, I can only see that session_start() should be the first line of the php code and nothing else beyond that.
In my test server (with PHP 7.3) it took me a while to get it to work, the only thing I found out is that when I load my site using http, the session doesn't save across load. And when I load it using https, it works fine.
While at this topic, I am also confuse why this tutorial site: https://www.w3schools.com/php/php_sessions.asp doesn't work despite it loaded using https.
I've been struggling to put SilverStripe behind a load balancer and I've been fixing multiple problems with rsyncing the instances and using shared storage and have almost got it stable, however I've found another issue which breaks the CMS.
Specifically when you try to add a link in the CMS in the TinyMCE editor, when the pop-up screen shows to select the page/file the JavaScript throws an exception that tinyMCE.activeEditor returns null.
I've rsynced the cache directory silverstripe-cache between the two servers and still there is a discrepancy between the m=timestamp of only a few seconds, but I'm guessing this is enough to cause tiny_mce_gzip.php to be forced to load again.
I have a shared redis cache for session storage, shared db, have rsynced the cache directory and use CodeDeploy to deploy the app so it should all be in sync. What other storage areas could cause the different m timestamp? Has anyone had success with SilverStripe CMS being used behind a load balancer without sticky sessions?
You can disable the gzip version of the HTMLEditor. I've seen this happen before. Try adding the following to your config/config.yml:
HTMLEditorField:
use_gzip: false
After that, do a full flush and try again?
Another option, is the javascript not syncing correctly. For that, you'll need to change the way the ?m=12345 is built. By default, it's built based on the timestamp.
I'll see if I can dig up the md5-based one, which might otherwise solve your problem.
*edit
Here ya go, try creating this somewhere in your project, and add the following to _config.php
Requirements::set_backend(new MysiteRequirementsBackend());
https://gist.github.com/Firesphere/794dc0b5a8508cd4c192a1fc88271bbf
Actual work is by one of my colleagues, when we ran into the same issue.
Recently we upgraded a server from PHP 5.3 to 5.6. We tested all code internally before doing so, and all was well.
After the upgrade, everything works fine except for an extremely small portion of the clientele. We have an integration with a LOS called Calyx Pointe. A small portion of Pointe users are losing their sessions after loading a few pages. We cannot determine why.
They login and we see their session data. They choose an option and it redirects them to page #2, which still knows who they are. They choose an option on that page, which calls an AJAX GET call, and suddenly they're forgotten. I have verified that the AJAX called page includes the sessions code, so it should be fine. It's also called via the same domain, so there's no issue w/ multiple domains losing the session. Also, no _ in the domain name.
When we tested w/ the same version of Pointe, it works perfect for us. And we have done this on several different versions, using different underlying versions of Internet Explorer. (Also, a small portion of these users CAN place orders fine.)
So, 2 questions:
Does anyone know of any issue w/ the change in PHP versions that would cause this? We're not using mysql_* functions. The sessions are stored in a DB using a modified version of Zebra_Session. This started immediately after the upgrade (the next day), so I don't feel it's a coincidence. But, b/c we cannot reproduce the issue, it has made it extremely difficult to diagnose, as we cannot test from the client's machines.
Alternatively, would passing PHPSESSID in the URL to each page called w/in allow each page to "remember" the session?
Any ideas would be helpful and appreciated.
I am in the process of migrating an existing Drupal website from another provider to Bluehost.com -- while I think using Bluehost.com is not relevant in this context I thought I'd mention it anyway, in case there are indeed some particularities I'm not aware of.
The site is a Drupal 6 installation and it did work previously I am told on bluehost too so you think it shouldn't be any problems, however, having copied it over I encounter a big problem: all the responses from Drupal are sent with Content-Encoding set to application/x-gzip. This has the implication of all browser presenting a download dialog box rather than rendering the content.
I have actually curl'd the index page and ran it through gunzip and the output is the correct HTML for the site -- just that it somehow ends up being gzip'd and this mangles the content type and confuses the browsers.
Talking to previous maintainers of the site they suggested using PHP 5.4 (they were running it on php 5.5 as I understand and despite all the Drupal suggestions it was running perfectly well I'm told).
I am trying to eliminate now any type of gzip'ing that occurs here so I've got it down to a few layers which could cause it but eliminating those it still doesn't work:
SetEnv no-gzip 1 in .htaccess
zlib.output_compression = Off in php.ini
drupal had the boost module installed and some corresponding settings in .htaccess -- i've removed those from the .htaccess file as well as deleting the boost directory from sites/all/modules
The problem still stands and my files are being sent to the browser compressed. Is there any other way to disable this?
Note that this only happens for pages inside Drupal, having uploaded a simple php page and navigate to that url works fine -- which suggests therefore a drupal (rather than apache/php) problem.
I've noticed a module mimedetect which has a definition for application/x-gzip in there but not sure how could this affect it as removing this didn't render anything useful either.
Any ideas where to look and/or what might cause it?
Happy to provide any other insights that might be useful in diagnosing this.
Ok so having actually reset the database cache and with the settings above this now works. I'm trying to figure out which one of the above actually solved it.
I made a full migration of the Drupal site (both code and DB).
At first sight site works fine. All the pages and page content are fully available.
But all the POST forms don't work. I tried to put test messages to form hooks. Form generation works fine, but both validation and send hooks were not even called.
Moreover, all standard forms (for example Sign Up Form) don't work too.
Just after submitting form fields become empty without any errors or warnings.
Looks like all the differences between environments are:
PHP version. (from PHP 5.4 to PHP 5.5)
Different path on server
Another domain name (dev/staging)
But, I'm not sure. I might missed something else.
Does anybody have any ideas what could cause this problem?
Well, the reason of the problem was very simple and so confusing at the same time.
It's not a Drupal-related issue, it's quite strange behavior of Apache Web Server.
The mod_rewrite was disabled in Apache configuration (shame on me). But, despite this fact, Apache was managing all redirects, thus pages were returning correct content but with 404 response code! It caused empty POSTs and, as result, broken forms.
I still can't realize why Apache behaves this way...
Anyhow,the problem was solved.