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.
Related
so I want to properly secure my app from crashes on "udefined indexes". Say that article exists but is listed in nonexistant category, or its author is out of system (basically missing id), or doesn't have any tags (missing list of tags)...
My problem is that whilst I can check for every id and array everywhere (like check for existing author everywhere where I use author...), I don't really want to do that and I am hoping for some simpler/more practical solutions, or some effective workflows/best practices.
My primary issue is that I don't even know how to label this problem, so I have very hard time googling anything about that, finding some tutorials and so on...
example:
$this->article = $this->data->articles( $this->articleId);
$this->author = $this->data->authorGet($this->article['article_user_id']);
This crashes if article isn't found (and obviously, I can check it here, but I don't want to do that on every single line in my system, or forget it somewhere and have a bug)
From this I get the feeling, that I have to do it on each and every place separately, maybe integrate some of the stuff in code (say author of article could be part of article itself and article db loading would be "no author protected").
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.
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.
I've inherited a site that uses PEAR to handle all DB calls.
This is an example of how it handles a query:
$result = $conn->query($sql);
if(PEAR::isError($result))
{
die('<b>Error:</b> '.$result->getMessage().'
<br/><b>Debug Info</b>: '.$result->getDebugInfo());
}
$row = $result->fetchRow(DB_FETCHMODE_ASSOC);
This is exactly how it is on hundreds of pages of this site. The problem with this is that whenever there is any kind of DB error (e.g. a SQL syntax error), it is displaying the ENTIRE error and related query directly to the user because of the $result->getDebugInfo(), which is a big NO-NO for obvious security reasons.
Instead of displaying the error to my users, I want the site to simply e-mail me whenever there is a DB error, and to e-mail me the contents of $result->getDebugInfo() rather than displaying it to my users so I can be alerted to the problem and debug it while avoiding the security risk altogether.
Now, I thought this would be as simple as searching for the getDebugInfo() function in the PEAR library and changing it to do the above, but that did not work at all which is very puzzling. I found the function in only one location, which was the main PEAR.php class file and it looks like this:
function getDebugInfo()
{
return $this->getUserInfo();
}
No matter what changes I make to this function, they are NOT reflected when $result->getDebugInfo() is called in the script, which is incredibly puzzling and is making me pull my hair out. I've even tried commenting out the ENTIRE function and it STILL displays the error code to my users as if it were HAL and in complete control to do as it wishes while I'm his little minion. Talk about puzzling (I'm bald now)!
So how in the world do I get my site to stop revealing the PEAR error and SQL code to my users and to e-mail it to me instead?
Search
die('<b>Error:</b> '.$result->getMessage().'
<br/><b>Debug Info</b>: '.$result->getDebugInfo());
and replace with
handleQueryError($result);
or something similar in your entire project. You don't want to display debug information to the user, so don't have statements in your code that do this. think about the next guy that will inherit this code.
I'm getting a really weird error for a query. I'm working on a CMS and the query works perfectly when I'm in the public pages and, until a couple of hours ago, it also worked in the admin pages.
The weird thing is, when I go to login to admin, it's failing due to a reference to an unknown column which isn't actually a part of the query at all, it's a session variable.
The query is;
select * from pages p, templates t, sites s where p.page_title_csv='uber,admin' AND p.page_template_id=t.template_id AND s.site_id=p.page_site_id
The error is;
Page selection query failed coz of:Unknown column 'this_site' in 'where clause'
The column it's referring to ('this_site') is in fact one of my session variables and isn't mentioned in the query at all so how it's causing the error is a total mystery to me. It's not even a column in any of my tables.
I've already checked;
the database is connecting fine
there is definitely a page with a page_title_csv of "uber,admin" (and definitely only one)
I've tried removing the aliases
I've even tried changing the 'like' to '='
Destroying $_SESSION and starting again after closing multiple browsers (Chrome, Firefox, Safari)
Restarting all services (running Windows 7,Apache 2.2.17, PHP 5.3.5 & MySQL 5.5.8)
I know I haven't altered the table structures recently enough to have caused any problems. As I say, it works fine on all of the public pages but not on any of the admin.
The only possible clue I've got left is that $_SESSION['this_site'] has one setting for the public pages while the admin ones have a different value, although why that should matter when it's not even in the query is beyond me (especially when it was fine up until now).
Any help appreciated, it's 3:30am here so giving up for the night before I make things worse... Cheers
(Last ditch is to try a full reboot, if I'm not posting here again within the hour, that didn't work either)
Fixed it!
Marc pointed the way - I started looking further down the line and found that an embedded function in the page was causing the dodgy query because I had changed the way I handled call_user_func() in the page building routines. I'm sure I would have been stuck for much longer if not for the help. (Just writing up my question helped me get it right in my head too, never underestimate the power of writing problems down lol).
Thanks all for viewing/pondering this problem- almost every other problem I've had in the last few months has been solved by just browsing Stackoverflow but this was the first time I had to post. The best site for programmer community help ever and that's partly your fault for reading and responding where you can - thank you one and all!