CroNiX

Not really understanding your question. Could you explain a bit more?

Did you google the error message? Don't be so quick to just report your error here.

if (($i+1) % $imagesPerRow == 0)

Well, you're dealing with the static maps api, not google earth pro, and the TOS for that service prohibits what you are trying to do. Please read it. It doesn't matter if you have a license (which just allows you have more hits to the service/day). If you can show something from the static maps api TOS that expressly allows you to store one of their images without using their api each time outside of a publicly accessible website, please point it out and I'll gladly try to help.

Sorry, I'm not going to help violate googles terms of service. To display a map, they want you to retrieve it each time (like from a web page) and not store it. You're trying to store it in your pdf.

Also, I just read that mpdf won't store an image that doesn't have a file extension as it can't determine what image type to parse.

I know you're not directly trying to do that, but the end result would be the same as the pdf generator would store a copy of the image and not dynamically generate it each time you view the pdf like you are above.

Well, you can't legally do that. https://developers.google.com/maps/faq?csw=1#tos_staticmaps_reuse

What error are you seeing? Normally you'd put session_start(); at the very top of your script, on every page.

If you're db is in UTF-8, why are you using the windows character set in your <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> Basically stick to one character set and use it consistently everywhere. In the db, headers, code, etc. And translating from one set to another rarely works 100% of the time, so it's best to avoid doing that if possible. Sometimes you have to convert though, like you're retrieving data from an outside RSS feed that is encoded differently, but for your internal data, it should be consistent.

Absolutely, nitrous belongs in beer. Sorry, couldn't resist.

It would replace the code you posted in your last post, where you are setting $margin['x'] and $margin['y']

Something else must be going on somewhere else because the code in your last post wouldn't echo out a directory. Also, you are creating a HTML link with a query string, which means the variables in the query string would be retrieved from the $_GET superglobal, but you are trying to get it from the $_POST superglobal. You might also want to look into PHP's glob function, which would make this a bit easier.

It wouldn't matter if you are using math based on the original image and the watermark image. It will calculate it and stick in in the lower right, based on each images size. The numbers I gave you were just examples to demonstrate. You'd just do: //get the height/width of the source image $source_width = $source[0]; $source_height = $source[1]; //Get the height/width of the watermark image $wm_width = $wm_source[0]; $wm_height = $wm_source[1]; //Calculate the x/y coordinates to place the watermark in the lower right of the source. $margin['x'] = $source_width - $wm_width; $margin['y'] = $source_height - $wm_height;

You'd have to calculate the size of the image receiving the watermark. Let's say the original image TO be watermarked is 100 wide and 100 tall. x = 100, y = 100 would be the very far bottom right. let's say the watermark image itself that is being applied to the original image is 10 wide and 10 tall. So you'd take 100 - 10 for the x value, and same for the y value. So you'd put the watermark at x=90, y=90 to be in the bottom right. You are already getting the sizes of the watermark image an the source image here: $wm_src = getimagesize($wm); $source = getimagesize($img); So you just need to use them in your calculation

This isn't how this is normally done. You never want to have the raw prices in the form. This would allow a user to change the price by manipulating the HTML on the page by using many available browser tools. I could easily change the 350 price for the Galaxy S4 to 1 and submit the form. You'd lose money and I'd get a cheap new phone. Generally, you'd have a db table for products. Something like: id | description | price (and probably more like category ID for things like "phones", "office supplies", "tablets", etc. like: 1 | Pen | 10 2 | Galaxy S3 | 300 3 | Galaxy S4 | 350 etc. When generating your form, you'd query the db and get the values and display them on your form. Something like: <label><input type="checkbox" name="product[]" id="1">Pen</label> <label><input type="checkbox" name="product[]" id="2">Galaxy S3</label> <label><input type="checkbox" name="product[]" id="3">Galaxy S4</label> Then when you submit your form, you'd get the $_POST['product'], which will be an array of the product ID's that they made purchases for. Say they purchsed a pen and the galaxy s3. $products = $_POST['product']; //products = array(1, 2) Using those ID's, you'd again select those items from the DB but only getting the rows where the ID's are the $products SELECT * FROM products WHERE id IN(1,2); which gives you the Pen and Galaxy S3, their price and description. You can now calculate the total, and show the description of each item to the user on the checkout page because you just retrieved those items from the db using only their product ID. It's obviously a bit more complex than that, but hopefully this gives you a better (and more secure) direction to go in.

There are no constraints on arrays in php. If you add and element to an array it just adds the element to the end of the array, unless you specify the index.

And "Query failed - Lost connection to MySQL server during query" means that the query took longer than the "net_read_timeout" setting in mysql, which defaults to 30 seconds. http://dev.mysql.com/doc/refman/5.0/en/error-lost-connection.html

post the schema to your car_make table. SHOW COLUMNS FROM marcomdata.car_make; I'm pretty sure you can make that query run a LOT faster if you had an index on the year field. See what's happening here, and why group_by takes a long time. It has to do a lot of extra work. http://dev.mysql.com/doc/refman/5.0/en/group-by-optimization.html It's my experience that a lot of people don't properly index their database so that it performs well. Just having a (primary key) index on the "id" field isn't nearly enough in the vast majority of cases. http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html It (the slowness) doesn't show up when you only have a few records, or a few hundred records, but when you start getting a large database with thousands or millions of rows, it gets really slow because mysql has to process all of the rows.

Do you have the fields indexed that you are using distinct or group by on?

When you upgrade to php >= 5.5 http://php.net/manual/en/migration55.deprecated.php

Just to add for a more complete explanation, you can also get the array key, whether it's numeric, associative, or a combination in a foreach() loop. foreach ($arr as $arr_key => $arr_item) { echo "Key: $arr_key, Item: $arr_item<br>"; }

Best to use a table for tabular data.

All the wasted cpu cycles just to transform a bunch of overly verbose fancy stuff into SQL, when you could have just written...SQL. If you're worried about SQL injection, just use parameterized queries/binds/prepared statements like PDO or even MySQLi offers. I'd be interested to see you create that, and then benchmark it against querying the raw SQL it produces. And then think about 500 people accessing your app simultaneously, or thousands, or tens of thousands. SQL is fairly complex. Subqueries, joins, aliases, aggregate functions, math, casting, date functions, protecting reserved words for people who use them as column names like `order`, etc. It would take a lot of code to accurately replicate all of it's functionality to be able to recompile back into raw SQL and still have it work in all cases. I've never run across a "query builder" that did everything I needed it to and still had to write raw SQL to get around its limitations and waste a lot of time trying to figure out how to make it bend to what you want it to do. In the end, you have to learn an entirely new complex language. KISS. It's like you want to write a book for an English audience. So you write it in French and have someone translate it to English. It never comes out 1:1.

Yes, wget basically is a http wrapper calling the url like a browser would, which means it's not actually using the PHP CLI but using whatever your webserver is using, like cgi, cgi-fcgi, etc. If in crontab you used /usr/bin/php5 -q /path/to/php/script.php then it would be CLI