PFMaBiSmAd

You can dynamically produce and output the data.js file using a server-side scripting language, getting the actual data out of a database, depending on the maximum number of data items (after more than a few 10k-100k of characters, you wouldn't want to do this all at once.) You can also use ajax to dynamically get specific blocks of data. To limit the number of http requests, you would do something like retrieve all the entries that match the first letter typed and send them to the javascript on the page all at once, for that first letter. Your existing search scheme would then use that block of data, the same as if it had been output as part of the data.js file.

What kicken is indicating is your web page is sending a content encoding header of none. The site that can be validated at the w3.org validator is sending a specific content encoding header of gzip (i.e. your joomla global server settings are set up to compress the html output.)

Only if you are including the code twice, so that it is executed twice. Here are the cases I have seen where pages are requested twice/code executed twice - 1) FF - debugging addons 2) FF - default page language encodeing set in the browser is different from the language encoding set in the page 3) IE - something to do with requesting the favicon.ico file causes it to request the page a second time 4) URL rewritting - something about either a missing or an actual trailing slash that causes a page to be requested twice 5) Some web hosting where requests are forwarded to servers behind a proxy 6) Javascript on a form that submits the form and the browser submits the form (the javascript does not return a false value, so the browser submits the form too.) 7) Server-side code that loops over/includes/calls code twice. Your simple test code probably rules out 1, 3, and 5. Number 2, 4, 6, and 7 are still possibilities. You would need to post all the code needed to reproduce the problem for anyone here to directly be able to tell what the code is or is not doing that could cause the problem.

Also, I just used the html source that I saved from my browser (Firefox) and it validates processes at the w3.org validator. I would say this is most likely a user agent issue.

Any chance the site that doesn't work is checking the user agent string and is outputting different things depending on the user agent being used? I don't know what user agent string the w3.org validator uses, but it might not be what your site expects. Also, I'm pretty sure that w3.org validator does not accept cookies, so if your site outputs different content with/without cookies, you might not be outputting the same content to the w3.org validate that it does to a browser. I just tried a different online validator - http://www.htmlhelp.com/cgi-bin/validate.cgi?url=http%3A%2F%2Fwww.watersport4all.nl%2F&warnings=yes&input=yes and the site can be processed.

http://dev.mysql.com/doc/refman/5.5/en/string-functions.html#function_substring-index

You basically have a whole page that doesn't work. Snippets of code from that page don't really help us because the posted snippets of code are each doing what they were written to do. The problem is in something that's occurring somewhere between those snippets of code. Without all the logic on the offending page that is needed to reproduce the problem, its not directly possible to help you with the logic on your offending page. I'm going to guess that you have overwritten $_POST['sub_comment_reply'] at some point between where it is set at the top of that posted code and where you test it again in the included code. The problem could even be in how you are including that code. When you were dumping the values, were you doing that in the included file's code or was that in the main file's code? Posting the full relevant code will be the quickest way of getting a solution.

It seems you are actually requesting the includes/user-process.php file directly, instead of the main index page. When the includes/user-process.php is requested directly by the browser, the config.php file hasn't been included and none of the files that config.php include/require have been included either.

After your require("includes/config.php"); statement, add the following two lines of code to get a list of the actual files that have been included/required at that point and to stop execution before the fatal class not found ... error - echo '<pre>',print_r(get_included_files(),true),'</pre>'; die;

Only if either the /usr/share/php or /usr/share/pear paths also contain an includes/config.php or includes/classes/user.class.php file or you have an includes path stating in the folder with your main file and you have an includes path starting in the includes folder. Since we only see the information you post, it will take seeing the actual error message (xxxxx out any part of your account name/domain you don't want to post, but leave all the syntax/paths as is) and the actual require statements in order to have a chance at helping you pinning down the actual problem.

You probably have more than one "includes/config.php" file, at different paths, and the include_path statement is causing the wrong one to be included/required. What does echoing the output from a get_include_path statement show on both your Windows and linux systems? Do you have more than one config.php file present?

What is the code in the includes/classes/user.class.php file (show the opening php code tags as well)?

You seem to be randomly changing your code. I suggest you read through both your original code and the last code you posted and try to determine why the change you made to it didn't do what you intended.

Your session_destroy statement in that code is clearing all the session variables, so when the page is requested the second time, it starts over as though it was the first time it was requested. You also have one = sign (an assignment operator), instead of two == signs (an equal comparison operator) in the following statement: if($_SESSION['itel'] = 1){, which sets the session variable to 1, then tests if that expression is true, which it always will be. You need two == signs.

You need to turn register_globals OFF. They were depreciated and turned off by default 10 years ago last month, because they allow hackers to set your session variables to anything they want, so anyone can bypass your login code anyway with them on, which is why they have been completely removed as of php5.4. The problem is not in your log in code, it is in your code on other pages that sets or tests the $_SESSION['id'] variable. You also have the following 'assignment' statement in two places: $_SESSION['id'] == $level['userid']; One = sign is an assignment operator. Two == signs is a comparison operator. That statement is not setting $_SESSION['id'].

Edit to the above: or do you mean $_SESSION['level'] gets changed to the id value?

There are two like possibilities for your session variable changing - 1) register_globals are on and you have another variable named 'id', - $id, $_COOKIE['id'], $_POST['id'], $_GET['id'] (and less common but still possible - $_FILES['id'], $_SERVER['id'], $_ENV['id']) that contains or has been assigned the level value. What does a phpinfo statement show for register_globals and do you have any of those other 'id' variables present with the level in it? 2) Your code is assigning a value to $_SESSION['id'], using one = equal sign, instead of comparing a value using two == signs.

The string that fgets returns, contains the newline character(s) at the end of each line. You would want to trim those off, since they are not actually part of the filename being put into the simplexml_load_file statement.

@cpd, I can name at least 7 different reasons pages can get executed twice, the most frequently occurring reason is: Firefox with debugging plugins. If you have eliminated your client-side, server-side, and any rewrite rules or how your site is hosed as the cause of the double page execution, the surest and simplest method to detected and prevent duplicate page requests in your server-side code is by setting a session variable that indicates the page has already correctly processed the request and then skip the processing for all requests after the first one.

Thinking about the meaning of what you are doing is required in programming, because computers only do exactly what their code and data tells them. I'm not trying to pick on you or be mean, but you must think about what goal you are trying to achieve and how it relates to your code and data. A statement that - "your product_id should be the auto-increment identifier from your database table, not a text string." is a suggested direction that requires more than one step to accomplish (all programming involves breaking down a problem into the individual steps needed to accomplish any task.) 1a) If you didn't already have an auto-increment column, you would need to add one to your table. Are you sure you didn't already have an auto-increment column with values in it? Most database management tools will automatically make the first column you create an auto-increment index. 2a) If you had to added an auto-increment column, you will now need to assign numerical id values (1,2,3,...) to your existing products and setup the table so that it will use the next available auto-increment value when you insert new rows (the database might do this for you after you assign values to the column.) Given that you have a relatively small number of products in your table, I would manually assign the numerical id values to your existing products using your favorite database management tool (phpmyadmin or similar.) To set the next available auto-increment value, you would directly execute a query like: ALTER TABLE your_table_name AUTO_INCREMENT = x; where x is the value you want the table to use for the next row that gets inserted. 3) Now that you have an exiting or a newly added auto-increment column in the table, with values in it, you would just need to use that column name in your queries.

^^^ If you were able to do that, what exact issue are you having creating a php script to provide an administrative interface? It would be just more of the same basic form/form processing/database query concepts, possibly with a little login/session security to limit access to specific logged in users.

There's nothing wrong with that line of php code. DW has never been very server-side code aware and frankly, you should not be dependent on your programming editor for the actual php syntax. What sort of problem did you get when you RAN that php code on your server?

A slightly different array method - <?php function _empty($var){ return ($var != ''); // filter empty strings } if (isset($_POST['calc'])){ $values = array_map('trim',$_POST['vars']); // trim all $values = array_filter($values, "_empty"); // remove empty entries $ave = array_sum($values) / count($values); // calc average echo $ave; }

Not without knowing the context and conditions and values under which it would need to work. What is typically in $userlimit? Is it just the number or is it a longer string of some kind? How is this value being used? Is it in an update query, in which case, you can probably just do it in the query? Is the value (5000) a variable or a fixed number? Just one line of code taken out of context doesn't define a programming problem. Anything we come up with for just that one line would take more statements, but in the overall scheme of what you are doing, once you tell us that, you can probably greatly reduce the number of lines of code.

I assume you are referring to setting the session.cookie_domain setting and the setcookie() domain parameter to be: .yourdomain.com to get it to match all variations of yourdomain.com You would need to use a different session_name for that one sub-domain (let all the others use the default session_name.) This would cause a different session id cookie name to be used for that one sub-domain. As far as regular cookies, to cause that one sub-domain to ignore the other cookies and only use the ones intended for it, the only thing that comes to mind would be to create unique cookie names (similar to what using a different session name does.) Setup a defined constant that you prepend to the cookie name. You would set this defined constant to a unique value (perhaps the sub-domain name itself) that would create a unique set of cookie names just for that sub-domain. All the setcookie() and $_COOKIE references would use that defined constant when forming the name of the cookie to set or reference.