requinix

That's the way to do it. There's something else going wrong.

1. Aren't you outputting the username multiple times too? Shouldn't it just be the stars? If you mean only one of those spans to be outputted you have to use else-ifs so that only one branch works at a time and then rearrange the branches so that the most specific (gold >= 5000) happens before the least specific (gold >= 100). Because if I have 5000 gold then I definitely have >=100 gold too. 2. SHA1 is less secure than it used to be. If you're redoing this then you should switch to a better algorithm like SHA512 or bcrypt. As for the salt, it should be an entirely random string - not some predetermined value already associated with the user. Yes, you do have to store the salt. I strongly disagree with lemmin's comments that SHA1 is "completely fine" and that you "can use the same salt for every password and be safe". I can't let that go.

if ($dow == 0) { $dow = $day + 1;You don't have anything that wraps the last day of the month on Sunday to be the Monday in the next month. Same way you don't have anything that wraps the first day of the month on Saturday to be the Friday of the previous month.

The part where you actually set the value of $this->firstname. Or $whatevervariable->firstname.

Because it seems like it's not happening.

Where are you actually setting the value of $this->firstname?

Don't use regular expressions in the first place. Use DOMDocument or some other HTML parser to navigate to the place that has that data. Which is hard to help with because I don't know what the HTML is.

What code do you have so far?

Heh. I was going to include my usual "how to convert ereg/POSIX expressions to preg_match/PCRE expressions" but figured you didn't need that. What's funny is that the spiel would have said something about adding delimiters and then escaping that character in the expression if it's used.

Only thing you haven't said is how it's not working. Not matching on a particular string? What string? Getting the wrong numbers? Something else entirely?

Pretty sure you don't want the ui.id part. SELECT COUNT(*) + 1 FROM table WHERE points > players points /* and then +1 */ or SELECT COUNT(*) FROM table WHERE points >= players pointsOne of those will give you the rank number you want, and it depends on what rank number you would give someone if they were tied for first place. Say three people score A=10, B=10, and C=9. Are the rankings #1, #1, #3 (ties get the highest rank) or #2, #2, #3 (ties get the lowest rank)?

Do not turn on allow_url_include. Fix the code instead. Not sure why you thought removing it would help. Looks like you did try with readfile(). Does top1.html contain any PHP code?

Are you sure you're putting the files in the right place? Did someone specifically tell you to use FTP to upload the files into the public_html?

Calling something "normalized" is like calling someone's actions "illegal". By just the terms themselves you can get a decent idea of what the person means to say, but the reality is there's varying degrees of both. Most everybody knows about normalization where you use a primary key ID (or other single, small piece of unique information) as a key for data across various tables. But there's also stuff about not using multiple tables for a single entity, or not including data in a table that doesn't belong there. Typically (and strictly speaking) normalization comes in different levels: you normalize for one criteria, then for a couple more to reach the next level, then a couple more for the next. Likewise illegality can range from simple shoplifting to armed robbery to outright murder. (Interestingly enough, the analogy doesn't stop there. There are accepted exceptions to normalization, typically for caching or ease of access, like how murder in the name of self defense is sometimes excusable: you should still take a second look to make sure things are the way you think they are, but once confirmed maybe you can let things slide. But don't worry about that quite yet.) EAV is powerful but complex. You can represent just about anything applicable using it but at the cost of opaqueness and difficulty. If you know how it works you may be tempted to use it everywhere, and that's one way knowledge in general backfires, but if you can evaluate potential solutions to a problem in increasing order of sophistication (which often goes hand-in-hand with complexity) then you may be safe. - It's heavily normalized. That's kinda good as normalization is generally good, but kinda bad since you get lots of data and lots of tables and lots of overhead. - It shouldn't have anything to do with SEO. SEO focuses on your presentation of the data, not on the actual representation of the data in your database. Apples and oranges. - It does mean lots more rows, but these rows are generally small - often simply ID+name or ID+name+value - and unique across the table. And there's generally a point or three where additions to your "enum" and "lookup" tables plateau and you only deal with the entities that reference them. - Indexing that data means larger indexes in MySQL but searching is fast: for example, rather than MySQL scanning an entire column in a source table for matching values, it can scan the entire column in the much smaller attribute table and only then join up the source table. I would suggest looking more into it. It seems like you're describing a situation where different types of products have different attributes, and as long as that list of types is subject to change then EAV may be worth it. On the other hand if you have a handful of different products but that's not really going to change - at least not without significant work in the rest of the site - then EAV may be overkill and not worth the time. Also note that converting to and from EAV is fairly painless, should you decide one way now and change your mind later.

Pagination. It's called pagination. Not pigmentation. You know how many rows you want on a page, right? Use a LIMIT clause to reflect that. SELECT fields FROM table WHERE rank >= $players_rank ORDER BY rank ASC LIMIT 50 /* 50 rows per page */

That file /usr/local/apache/htdocs/functions/functions.phpdoes not exist. Are you sure you have the right path to it? Once you get that right the "undefined function" error should go away.

Constants may be case-sensitive (by default) but keywords aren't. define("RETURN", 123); echo RETURN; // unexpected T_RETURN

So the explanation of what happens (SEO goodness!): Say you had an image 9999x1000 and want to scale it to fit in 154x75. Maintaining the aspect ratio means you resize the width and height by the same percentage, but the question is which side do you use to calculate that? If you resize 9999->154 that's 1.54% of the original width while 1000->75 is 7.5% of the original height. So say you resize according to the width. New width is 154 and the new height is 1.54% * 1000 = 15px. That's good because you want the image to fit inside the new dimensions. If you resize according to the height then the new width is 7.5% * 9999 = 750px which is definitely not inside. Given the two percentages, the smaller percent will mean the image shrinks more and so guarantee it fits inside the bounds (like if you have a box to fill), while the larger percent means the resized image fits outside the bounds (like if you want the image to be at least as large as some size). With that explanation you can width percent = new width / old width height percent = new height / old height if width percent < height percent { new width is unchanged new height = width percent * old height } else the width percent >= height percent so { new width = height percent * old width new height is unchanged }or even easier percent = min(new width / old width, new height / old height) new width = percent * old width new height = percent * old height

Not normally, but you can put them in the URL or form (insecure) or session (secure) instead.

Nope. Also would help to know what "bad code" you're talking about.

Well yes, but that's not much detail to go off of. Maybe you have some examples?

How different are the schemas? If there was a very small amount of data how would you manually import it? How much data are we talking about? How about giving us some real information to go off rather than vague statements "front-accounting software" and "totally different schemas"?

"Final page"? How does the $quotation get there?

IIRC Mac software may include orientation data in the picture: the actual image is upside-down but the metadata specifies that the image needs to be rotated. Problem is that software has to be aware of and able to read that metadata. exif_read_data may be able to tell you. Try it on a flipped image: what does it return?

If the image is reasonably sized then CSS is much easier. But if the image is huge, like unresized from a digital camera and in the thousandsXthousands, then ImageMagick is definitely better than GD at resizing.