KevinM1

How does the link actually fit in with the search? Usually a search is initiated in a form, where the search term is used in a JOIN of some sort. If you can describe your current search process (looks like it has something to do with gamer profiles), that would help.

The design question should be "Why change from the norm?" Virtually every site that has some form of user login splits the username/email and password into two different fields. What are you trying to gain from a one field setup, aside from novelty?

Which is fine, and believe me, we don't want to stifle discussion. It's just that, after having the same discussion over and over, we tend to get a bit annoyed with how masturbatory it all is. I mean, if you put in the same effort and passion that you put into your posts here in a RFC, you might actually be able to steer PHP in the direction you want. Which is pretty cool. I dunno... it seems like if this is the part that you're most passionate about (and, looking at your post history, it seems like it), then why not harness that passion into something tangible? Why waste time trying to convince us when you can actually convince the powers that be? Again, not saying that you can't, or don't have the right to talk about it here. Just pointing out that you can actually have a hand in the changes you want to see materialize, if you so choose. That's the beauty of open source. You don't need to be on the sidelines.

Have you actually taken part in the development process? Or made RFCs? Because wishcasting here isn't 'developing PHP' nor is it officially requesting new features. We're not tied to Zend. That's why we're generally amused/bemused at your quest to make PHP better. Writing posts here isn't actually accomplishing any of that.

And, like I've said many times before, this is exactly the wrong way to approach it. Programming is not like learning Photoshop. Going at it like "I want to make a button that posts things" and then trying to find a tutorial that only does that is hurting you. You really need to focus on understanding how things work in general. When the description of print_r() says something along the lines of "Prints out the contents of the variable in human readable format" you need to know what a variable is and what human readable format means. Likewise, you need to learn the difference between server side programming (which is what PHP is, and cannot interact with the web browser directly) and client side programming (Javascript, which is used to directly manipulate HTML (which is where buttons live *hint*)). So, quick quiz: Do you know what a variable is? Do you know what an array is? Do you know what a loop is? Can you write a while-loop? Can you explain the differences between a while-loop, for-loop, and a foreach? Can you explain the difference between = and ==? Can you explain the difference between return and echo? Can you write and execute your own function? Can you explain the differences between PHP and Javascript? If the answer to any of those questions is anything but a confident "Yes," stop what you're doing, get yourself a good book (http://www.amazon.com/PHP-MySQL-Dynamic-Web-Sites/dp/0321784073/ref=sr_1_2?s=books&ie=UTF8&qid=1356658475&sr=1-2&keywords=ullman), and actually learn.

Data Normalization: people tend to treat relational (notice that it's in italics) databases as Excel spreadsheets. That's exactly the wrong way to use them. The way to go is to normalize data so it can relate to itself/other data in a way that eliminates insertion and deletion headaches. Sessions: HTTP is stateless, meaning there's nothing inherent in it that can remember things. Take this forum: it 'remembers' that you're logged in when you go from page to page. That remembrance is facilitated (in part) by sessions. Pagination: Breaking long lists of items into manageable pages. --- Data normalization is primarily a database concern, although it will affect how you write queries. Sessions are baked into PHP (and just about any other language that deals with HTTP on a regular basis) and are trivial to use, and can be modified a bit according to your needs. Pagination is really an algorithm. You'll use PHP to write it, but it's not dependent on PHP.

@justlukeyou - We're becoming more and more frustrated with your posts and topics because you're not demonstrating the ability to learn from your previous problems. So, we continue down this cycle of you asking a basic question, one of us answering it in about a clear and concise manner that we can, you not understanding it, and the whole thing boiling down into an exercise in frustration as we attempt to explain how something simple like variable assignment, or print_r(), or whatever else is nearly self-evident works instead of actually addressing the problem. As I've said before, you need to work on your ability to read and comprehend. The PHP manual is written at a middle school level. You need to be able to read it, understand it, and use that knowledge in your own code if you're ever going to be able to do this for real. I'm not saying this to beat you down. It's just the reality of the situation. No one is ever going to hire a developer that can't read documentation. It's for your own benefit. At some point, we'll get so frustrated that we'll just stop answering your questions. We're all volunteers here, so none of us get paid for helping others. At some point, we all get to the point where it's simply not worth our time or effort to answer certain questions. After 726+ posts, and being registered here since 2007, you need to show us that you're growing as a developer, that you can understand what PHP warnings and errors mean, and that you can do basic debugging yourself. Otherwise, those that do answer your questions will become more snarky and show less patience until no one will even bother. It's just human nature. To put it in other terms, you wouldn't expect a garage to explain how a wheel works every time you went in, or a kitchen explain how heat cooks food every time you ate, would you? Because that's what your topics boil down to here - an explanation of things you should be able to grasp by reading documentation, or simply writing your own small test scrips. And soon, we'll simply not bother to explain it. Again, I'm not trying to be mean or insulting. I'm just trying to explain where we're all at. We're losing patience, so you need to show us that our efforts won't be wasted. You need to grow.

The problem isn't one of navigation but of design. What do you think the user should see when they look at their generalized (not console specific) profile? All of their data? A few key stats with link to their console specific profiles? Default to a particular console profile? We can't give a definitive answer because there isn't one. Without knowing your app design from top to bottom, we're shooting in the dark. It depends on how you want the flow to go as it relates to the rest of your site. You need to mock up the process, either with actual HTML pages, a storyboard (Indigo Studio is a free storyboard and wireframe tool), or, hell, a notebook or index cards. Walk through it and ask others to walk through it. Once you figure that out, the actual code will be fairly simple.

You're missing the point of what PHP can do by thinking about sites in terms of pages. You should be thinking about templates that are rendered and filled with information based on an incoming request. In other words, if I type in: www.example.com/profile/kevinm1/xbox Your system should be able to look up my Xbox related info and then display it in a Xbox profile template. I'm not sure how your back end/database is designed, but you should be able to pull all that info with one query. Can you show us how your db is structured?

If I didn't have a ton of X-Mas purchases on my CC, I'd be so over this. My license expires early next year, but thankfully after I can pay off my balance a bit.

Okay: 1. Don't use quotes unless you're trying to output text. 2. There's a difference between single-quoted text and double-quoted text: a. Single-quoted text is literal. Meaning, whatever is in that text will be printed as-is. If you have '$a', it will print $a. b. Double-quoted text interpolates variables. Meaning, if you have "$a" it will print the value of $a. Regarding $activationcode, don't use quotes at all in that context. If you're not printing to screen, don't use quotes around a variable. --- From a fundamental level, you need to improve on your reading ability. The official PHP docs are written at a middle-to-early-high-school level. They are some of the easiest documentation to read (seriously, try reading the MSDN). Now, I don't know if you have a learning disability or something, so I'm trying to tread carefully, but being able to read and understand documentation is a foundational ability for any programmer trying to do it for real. It's only going to get tougher from here on out.

@justlukeyou: make a test script: $b = 5; $a = $b; echo '$a = $b: ' . $a . '<br />'; $a = '$b'; echo '$a = \'$b\': ' . $a . '<br />'; $a = "$b"; echo '$a = "$b": ' . $a; Whenever you don't understand something, make a small test script to try out the concept. And work in small increments (think of something -> test it -> integrate it if it works -> repeat). It's far better to do it that way than with your usual "Throw shit at the wall and hope it sticks" method.

Properties are the big one for me. I don't understand why it hasn't been implemented yet.

Yeah, while the image is cute, it's not really suitable as the background of the entire site. It makes things difficult to read and navigate. Cute shouldn't trump usability.

I moved your topic here because it has something to do with app/algorithm design. That said, we're not 1-on-1 mentors, and, quite frankly, we don't know what you're talking about. It looks like you're making a game. Beyond that, who knows? So, take a breath and write exactly what you're trying to do, what you've tried, and what's gone wrong. Since we're not in the room/in your head, we need more info. Finally, please don't PM your code to me. Instead, post it here within tags. You'll get more eyes on it, and thus more help, that way.

It was slow for me yesterday, too. Page loading took longer than the actual survey.

First, snark like: only makes people not want to help. Now, people are telling you to use another IDE because, evidentally Adobe Muse isn't meant for PHP editing. Note that no one has suggwsted that your brother also switch IDEs. Since, apparently, Muse just outputs HTML (and likely CSS as well), there's no reason why your brother couldn't do his part in Muse and you do your part in something else. Right tool for the job and all that. Regarding PHP, I'm going to go out on a limb and guess that you learned what you know from a poor and/or dated resource (like w3schools, which NO ONE should go to). I'm also going to guess that the resource's examples highlighted PHP's ability to go between PHP code and HTML. I'm guessing this because you want to put PHP code in the body of your pages. That's exactly the wrong way to write PHP. The best way to write PHP is to do all your scripting upfront, store your results in variables, and then use as little PHP as possible in your HTML to echo those results. For you, this means all session and database work first. Now, to your actual problem - do you have session_start() on each page? Can you post your code?

Have you looked at linode?

Object initializers are used to populate anonymous types. Anonymous types are types that don't have an actual class definition (thus no parameterized constructor). Instead, they're generated on the fly, usually as the result of some LINQ query. Example: var productInfo = from p in products select new { p.ProductName, p.UnitPrice }; productInfo contains a collection of objects of an anonymous type that are made up of the product's name and price. That info can then be iterated over by a foreach: foreach (var prod in productInfo) { Console.WriteLine("Name: {0} , price: {1}", prod.ProductName, prod.UnitPrice); }

I think they're fairly common. Symfony has Doctrine out of the box. I think Propel, too. Kohana had its own Active Record style ORM when I played with it back in the version 2 days. Same with CodeIgniter. Ruby on Rails uses Active Record. ASP.NET MVC has Entity Framework and there are others, like NHibernate. ORMs tend to fall apart with complex queries, especially if you're dealing with many-to-many relationships. Sometimes you just need to roll up your sleeves and write SQL.

I'm a fan of doing local business. Online freelance gigs always struck me as a bit sketchy as there's little to no face-to-face contact. Being able to actually sit down and talk to a client is invaluable. For one, it makes the consultation process go a lot smoother. But, it also reinforces that human connection. It's easy for one side to screw the other over if they're just an email or IM entity, especially if they're in another country. Interacting with a real person is grounding. Local businesses tend to fall into three categories: 1. They don't want a site 2. They don't currently have a site, but want one 3. They have a site, but it's shit There's not much you can do with category 1. Category 2 is nice, but it tends to be filled with clueless clients that drag their feet and are indecisive. Worthwhile, but also frustrating. Category 3 is the honey pot - you can sweep in and save the day, thereby getting yourself both a nice payment and future business as they usually spread the word and offer glowing reviews. They also tend to know what they want, and are willing to work with you to get it done. However, since they feel letdown/burned/betrayed by their last developer, trust is an issue. Earn that trust, and they'll be in your corner forever. How do you find local businesses to work for? Ask your friends and family if any of the places they frequent have a site. Go to your local hangout places and offer your services. Every town has at least a couple of small business owners that want more. And if you can satisfy them, more will appear. One word of advice: in the rush to get new clients, don't oversell your abilities too much. The worst kind of developer you can be is one that over sells and under delivers. Then again, people like me make money cleaning up those kinds of messes....

http://arstechnica.com/security/2012/12/oh-great-new-attack-makes-some-password-cracking-faster-easier-than-ever/ Like MD5, SHA1 was never really intended to be used as a hash for passwords. Use SHA512, bcrypt, or any of the slower hashes that take multiple passes over a string. Use salt. Use phpass rather than rolling your own: http://www.openwall.com/phpass/

In other languages with namespaces, the above would, at the very least, result in a runtime error if not a compiler error. For once, I agree with Hall of Famer. PHPs namespace implementation is half-baked, and not keeping in line with other languages that implement the feature. Merely dismissing it as "PHP is not Java, get over it" misses the point. The point is that namespaces could be better. In cases like the example above, it's solved either by using an alias or by explicitly refering to the foo in question. But, one of the entire points of using namespaces is to be able to refer to classes only by their class names. Having to still refer to them by their fully qualified names when there's no naming conflict, even if it's just once, is ridiculous. All it does is add unnecessary boilerplate.

Hey, it's nice seeing you back on here. Some crits/suggestions/questions: Can you make the background of the SARCM logo the same dark blue as the rest of the header block? The black sticks out in a negative way, especially since the height of the logo isn't the same as the height of the header. What's with the picture of the Concorde on the lower left? It kinda sticks out there. Looks lonely. Have you thought about uploading the group's videos to YouTube? It would allow people to find your site from multiple sources, it would stop you from having to host the videos directly, and I believe it's easier to embed them than what you're currently doing. Just a thought. For the rest of the index, I think you need to make a choice between the rounded orange rectangles and the light blue rectangles. I can't tell why two of the items are orange and the others are not. As a general tip, try to make sure that your images are optimized, that you're serving as few files as possible on each request (your CSS can likely be combined into one file, and look into CSS sprites), and that your Javascript is solid. Given that most of the site is text, it had a bit of a loading issue. Finally two files are missing: information.gif and loveismamst.mp3. I strongly suggest that you don't put background music on your site. Users hate it, and it's just cheesy. Aside from that, it's pretty solid. Like you say, a pure CSS layout would be better, but recognizing that issue is better than not knowing it or ignoring it. Keep it up, and keep improving!

A lack of complete and up-to-date documentation. Even enterprise products like Symfony suffer from it. It seems like with just about every OSS project the lead developer is also the doc writer, so invariably some of the critical, but basic, steps for a new user to use the product correctly are either glossed over or not mentioned at all because of their intimate familiarity with what they're creating. It's incredibly frustrating to follow documentation 100% correctly only for the product to not work or spit out a confusing exception.