My company recently moved a php website to a new server. I updated all of the links and references to the database, etc. The problem is that in the new location the database is recognized and when the php page performs a sql query the results appear to be found but not displayed.
For example, if you log in as an admin and click on "People" it should list all of the members of the site. However, when you log in as admin and click "People" it displays 6 pages of blank lines (old site works fine). Am I missing something simple? Why can it read the info but not display it properly?
Couple things to try/think about:
Turn on 'display_errors'
raise the reporting level and pay attention to notices.
Check for a different version of PHP
Specifically, look for differences in the MySQL functions/methods if the PHP version is different. This may affect the portion of code which iterates over your responses.
My gut says the problem will be in the line that iterates your results. Since it appears to be iterating the right number of times, but the data is not there, I suspect you are getting good results but not fetching them properly. This is feasible if there is a newer version of PHP involved.
Related
Here is the problem we have been facing for the past few weeks.
1/ Our setup
PHP 5.4 + MySQL
2 dedicated servers, load-balanced
Sessions are replicated between the 2 servers using memcached
3 applications running on these servers :
One custom-developped application, using default php session settings
Another custom-developped application, using different session settings (cookie name, path)
One Wordpress CMS
2/ The problem
The problem occurs on our first application.
Some of our users reported that they sometimes get disconnected after a few minutes (when the session is setup to last 3 hours). It can happen to them several time in the same day, then no disconnection for a few days, but the problem always comes back.
So far the fraction of users impacted is small, but I would like to solve this before it "spreads" to other users.
The problem seems to occur in different places of the application, though we have identified 3 scenarii where most of the errors occur :
Some involve submitting a form ($_SESSION variable is modified)
Other simply involve opening a popup page, with no modification of the session data
We have tried to reproduce the different scenarii described by the users : sometimes we have been able to, but most of the time we don't have any problem, which makes it hard to debug.
Other notes :
The problem is recent, this application had been running for years without any problem.
It doesn't seem to be related to our server load, because the problem still occured during the summer break when our trafic was low
It only affects one session/users at a time: all the other users logged in at the same time don't experience this problem
The problem occured on all the different browsers (IE, Firefox, Chrome)
3/ Technical analysis
When a disconnect occurs, the user is redirected to a page "Your session has expired or you don't have the right to view". When this page is loaded, we get a technical email with a dump of the $_SESSION variable.
When a session expires the normal way, the email we get shows that the $_SESSION variable is empty (normal behavior).
When an unexpected disconnect occurs, what is interesting is that the $_SESSION is not entirely empty : out of the ~20 elements the array contained, only one is left (always the same).
So this would mean the session is not expired, but not enough data is left to "identify" the user, hence the "no rights" page displayed. As a confirmation when this occurs, we can check in memcached that this session still holds some data.
These are the potential problem causes we have identified so far, and what we have done to rule them out :
Memcached indicates between 70 et 80% freespace, so we don't think it is the problem.
We removed Memcached and went back to using a NFS shared directory for session files: the problem actually got worse. This would point to an applicative bug, because NFS being slower to write data, session loss would occur more often.
We have browsed all the different forums (including SO) talking about PHP session data loss, and reviewed our code accordingly. The code base is big, but we have used automated tools and scripts to avoid missing a file.
session_start() is called at the beginning of each page.
exit() is called after each header("Location...")
register_globals is Off
We have tested the possible interractions between our 2 other applications and the problematic one, though they don't share any code, database or session handling. Nothing identified there.
We have analyzed our access logs around the times of the disconnections, to check for behavior patterns : no luck here either.
So we have no idea what causes this problem, as it seems to occur randomly, so my questions are :
The problem could come from our code: did we miss anything to check ? This solutions seems unlikely as the code works most of the time for all our users, but I am still considering it.
The problem could come from another application/process that would "empty" part of the session variable array. We have also reviewed the code from the other applications, but didn't find anything that could cause this.
And if another process is doing this, why would it only empty some sessions and not all of them ?
Thanks for your help.
I don't think you'll get a definitive answer to your question. There are too many probable causes and you haven't shown any code.
Still, my guess is that you have memcached.sess_locking turned Off, or if you have a custom session implementation - that it doesn't implement locking at all.
Eventually, this leads to a race condition between two simultaneous HTTP requests.
My guess is based on the often seen bad advice to turn off locks or free them as soon as possible, in order to achieve higher performance.
If this problem "suddenly" occurred, check what has changed. Did you do any work on the application? If so check committed code (you talked about automated tools so I expect there to be a repository which would allow for accurate finding of code changes).
Did you change anything on the server? Like upgrade software, upgrade/change hardware, make changes to the other two applications ?
One thing that popped to mind, did you check the drives you use for caching? It could be a corrupted part of the file system. Which would explain the random user part.
I couple of things I always to is:
Try to determine the moment of first occurrence as accurate as possible. At my work this occasionally triggers someone saying "oh yeah that might have to do with when I changed/updated/created this or that" so this might help. On the other hand it can sometimes takes days, weeks or more before something gets noticed so start expanding that time-frame if nothing comes up.
You have already a couple of scenario, find the common factor in these. If they don't share any code, stop looking there. If they DO share code search there. Of course sharing (part of) it here might allow us to help you search.
Do an organised search. I usually do the main application check when I am the one working most on the application (or even better when I created it). A colleague will check surrounding applications that might have influence on it. In your case those 2 other applications. Finally our sysadmin will check for newly installed or updated software on the server(s) and he will also check with our network guys if anything changed hardware wise or network related (for other people this could be the hosting provider).
It could be as simple as a WordPress plugin that uses sessions and calls either session_name() or session_id() with a different value, overlapping your custom applications with default session settings.
Since WordPress itself does not use sessions, plugins are often written from the perspective of having free rein with sessions. I just did a search on a WordPress test site and found sessions used in a gallery plugin, a plugin for putting a background image on the page, a shopping cart plugin, and a plugin I was writing that needed to carry an uploaded file from one admin page to another.
Newbie here. My hosting company recently upgraded their server(s) and that's where my website problems began:
FYI:
MySQL upgraded from 5.1.70 to version 5.5.32
Apache upgraded from 2.2.25 to version 2.4.6
PHP upgraded from 5.3.27 to version 5.4.22
I have a shared hosting account
For the last 2 days I've been searching Google, online manuals and developer/tech forums for possible answers to my "issues" and I'm having no luck finding good answers that help me fix my code to make my website display properly. Very frustrating. Obviously I need to learn more.
BKGD: I hired a developer to build a CMS for my website a couple of years ago and have since been trying to learn so I have a VERY basic understanding of Php, MySQL and HTML... but obviously not enough to fix these issues. Can you/anyone please help me get closer to fixing this nightmare.
I know my original website code worked fine a week ago - prior to the hosting updates.
The Index page and other "main Sections" currently display just fine for some reason. But if you click on any of the links to "articles", "news" and other "pages", those pages are not connecting properly >> not pulling table data from the associated MySQL database. Those pages showed a couple of different error messages.... initially displayed ONLY a "1064 syntax error" message OR "no page found" error (no "header", "footer", "page title", or any other info). I've since tweaked the code (I.e., I "hid" some of it with "//") and have it displaying the header and footer but nothing from MySQL database.
The original "php.ini" file needed extra code >> "register_globals=on" << to work properly after the second-to-last Php & MySQL update. That is now "deprecated" and "removed".
This newbie thinks that the following code is ONE EXAMPLE that isn't working properly (that I believe needs to be edited/updated to allow it to connect to MySQL). I think if I figure this one out I can apply similar tweaks to the other "news" and "article" pages:
//-- START: SAMPLE CODE ----
include "init.php";
$res = mysql_query("SELECT * FROM {$prefix}pages WHERE pag_name='$page_name'") or report();
if (mysql_num_rows($res)==1)
cdie("no page found");
else
$row=fetch($res);
$title = "$row[pag_title]";
$desc = "$row[pag_description]";
//------- END: SAMPLE CODE --
I realize I might be way off on this being the issue (E.g., the problem might be in the functions.php file) but that's where I'm at right now. Clueless. Ugh.
Any thoughts or suggestions? Need more info (just ask and I'll reply as soon as I get the email).
If your code relies on register_globals, you are going to run into undefined variable problems.
For example, if the $page_name variable comes from a query string like index.php?page_name=test, you could access it before like $page_name but now you must access it like $_GET['page_name'].
You need to check all your code to see if your variables are defined (a good IDE can help with that).
As a sidenote, you also need to double-check to see if you don't have any sql injection problems, injecting variables directly in a query is normally not a good sign. You should really switch to PDO or mysqli and prepared statements but at the very least use mysql_real_escape_string on your variables before you use them in your queries.
The other day my colleague accidentally dropped my entire database. This completely disabled the website and just an error message displayed saying;
A DATABASE ERROR OCCURRED.
Error Number: 1146
Table website.news doesn't exist
Technically, my website does not need the tables in the database in order to serve it's actual purpose - they just provide a little more information. Is there a way to stop that error from appearing should the database be dropped again? And for my website to continue as normal but just display blank where the content of the database tables would usually appear?
You need to disable all database calls within your application. In correctly designed Codeigniter app it should be enough to comment (disable) all models usage (within cotroller(s) code), but it depends on your particulat code if this will work.
You investigation can be started from grep "website.news", good luck!
I have a few modules, but I will focus on one in particular. This module was working fine, and it appears in two articles. One article is viewable to registered users and the other article to the public.
I query my database from both of these articles. However, in the public article the module does what is supposed to, but in the registered article, it doesn't.
Before posting code and examples, is there anything obvious that I'm missing that I can try to overcome this?
EDIT
Here are the results of debugging mode:
Working article:
SELECT name, specialty, location
FROM people
WHERE name = 'larry' OR specialty = 'testing' OR location = 'seattle'
Non-working article:
SELECT name, specialty, location
FROM people
WHERE name = '' OR specialty = '' OR location = ''
The same query should be at work in both cases, and is this:
SELECT name, specialty, location, description
FROM people
WHERE name = '$name' OR specialty = '$specialty' OR location = '$location'
where these variables are POST data, eg, $name = cleaned_up($_POST['name']);
So basically the "registered" users version of the form doesn't post data to the query but the "guest" users version does.
EDIT 2
I discovered that when I remove the module on the left side of my page (I have two modules in divs, side by side, that share POST variables - which is probably part of my problem), the form that doesn't work, starts to work properly.
So I built an identical module, thinking if I pulled that form out and gave the code to another module it would work, but it gave same results as above.
Any help is greatly appreciated.
EDIT 3
I threw a var_dump($_POST); in there in several locations, one at a time, and this gave the expected POST data. So now I'm really confused, because the SQL query is correct and the POST data are getting to the file that needs them.
Although the question is a bit vague without specifics, I would suggest turning on debug profiling in Joomla. If you turn this on, you'll be able to see the exact SQL queries being executed by the module. Locate the queries used by your module, run them via phpMyAdmin or MySQL Workbench, and make sure you get the expected result.
If the issue is not SQL related, then you may need to provide more specific examples.
I found a work around that seems to solve my problem. The original weird issue still exists, but this work around gets my site working and gives me something to go on.
I created as separate variable file for each access state, registered and public. Apparently in the registered state the variables were getting conflicted and the POST data wasn't making it to the SQL query and thus wasn't showing up in my results table.
I think it may be a bug in Joomla but I'd like to get someone else feedback before reporting it. BUT... I posted on forum.joomla.org weeks ago with not response so I have little faith in that support site at all. Actually, if this is as good as their support forums get, then I think I might look into another CMS.
I'm new to PHP (and web development in general) and have come across something that to me seems really, really bizarre!
Background
I am currently designing and developing an online enrolment form for my employer, a training company. The form consists of 3 pages - pages 1 and 2 are for data input whilst page 3 is a summary page with only one input, a box to check that the customer agrees to our T&Cs. Page 3 also includes a box where calculations are made as to the price of the selected training course based on choices made earlier in the form.
The form displayed on page 2, and some of the text on page 3, changes depending on a choice made on page one - that is, whether they are paying for the course themselves or their employer is funding it. If they choose employer, they get one form, if they choose self funding they get a different one. However, both of these forms are contained within a single .php file, using session variables to decide which one should be displayed.
I am using sessions to transfer the data between the pages. Each page has been made sticky using session variables. Real-time validation is carried out using javascript on each individual page, then a final PHP validation check is run on the whole thing when the customer tries to submit the final page. Javascript is also used on page one to calculate the price of the course in real time so the customer can see how much he/she will be paying before proceeding further.
The Problem
I find this really strange:
In Firefox, everything works perfectly
In Internet Explorer, when JavaScript is turned off, everything is fine. But when JS is switched on, the PHP validation on the final page seems to go haywire, thus making it impossible to submit the form.
In Chrome, again when JS is switched off, everything works, but when switched on, I can't even get past the first page. Instead of loading the correct form for page 2, I just get a blank screen.
Can anyone help? This is my first major project and I've been working on it for weeks, coming up against all sorts of problems and tearing my hair out but managing to solve them. Now I'm completely stumped, when I'm almost within touching distance of completion!!
I can't post the code here as it's 3 separate documents and very complicated, but if you want to have a look at the form itself go to:
http://testing.xenongroupadmin.com/testing/enrolment.php
I hope someone can help! Thanks very much!
You are most likely getting errors on the page2.php,
See error reporting to display and debug those:
http://ca.php.net/manual/en/function.error-reporting.php
When I have validation errors in non-Firefox browsers, it's usually because I have some error-reporting code in my JavaScript. Just something like
console.log(testValue);
can bring IE to its knees. If you have any code like that, remove it before testing in other browsers.
Also make sure that all variable declarations are done with "var", and that you're using semicolons at the end of each line (the spec should really enforce this, but I guess it doesn't, and browsers handle it differently).
I've only just seen all these answers, so apologies for not responding sooner.
I managed to fix the problem - turns out it was all to do with JS, no problems with my PHP at all. There were two issues. Firstly, a few syntax errors (which it took forever to find). Secondly, a lot of my HTML elements had id's and classes with identical names (e.g. id = "example" class = "example") which seemed to be throwing the javascript a bit.
Anyway, thanks for all the responses, and also apologies for not being very clear on some aspects - 'going haywire' was a pretty poor way of explaining the problem!!
Cheers