kon

Sorry but this has to do with Yii it should be in Applications and Frameworks section. It can’t be in Application design because you could read “this is really awful application design”

The coding indentation style is something like which side of the road you are driving. It doesn’t make any difference except if you are driving opposite in others in this road. Yes there are numerous studies that suggest the one side of the road over the other as I guess there could be with indentation style. That means that if you have any important reason to have your code PSR-2 “compliant” then you should abandon Allman style and use their rules. Allman style is wired in my brain , even in some projects that I had to write in K&R , I eventually wrote in Allman and then had a second IDE (Eclipse) with K&R configurations to change it and make the commits and updates in SVN. I really can’t understand why people prefer other indention style but equally I can’t understand why some people think the blue color relates to sadness and therefore dislike it. I can be friend and coworker with a person that hates blue , it is a matter of taste. So yes I can work in a non Allman style environment, but my taste in coding indention probably wont change. Many things have being wrote about Allman vs everything else, many times when I talk to a person that is strongly opposed to Allman I ask “in how many OOP languages do you write code this epoch ? ”. The answer is usually from none to one. I were a Java enthusiastic at mid 90’s , all the official books from Sun were in Allman , luckily this went well with my previous programming indentation style experience in C and C++. When PHP became really OOP (after version 5) I jumped in. I can see that Allman is in decline in amateurs code, that’s sad for me , but again it is a matter of taste.

As I can see you have in your status table id and name , as you wrote this table is rarely modified and I guess the name of status (description) is also unique. With all that instead of evaluating the status id , you could evaluate the status name , making your code easy to read and meaningful. With some way you have this status in your user object , you can keep that and make its value to be the status name or even split it in statusId and statusName (where are the accessors and mutators ?). So the code: if ($user->status == "inactive") { // now everyone can understand it }

Every language can be used to create AI algorithms , modules or even coding templates. The problem with PHP , as with any language that normally are not precompiled ( same problem also with Java or Python) is that it runs above one more layer , the interpreter. Recently I created a game (for android in Java) and because my first implementation was with PHP and JS (client-side) I created the first AI algorithms to split levels according how difficult they are , in PHP. It was only 3 AI algorithm sequences but , the result was devastating. Then I made it in C++ and the result was more than 10.000 more efficient (time + cpu used). I was intrigued by that and I made it a PHP extension with C++, the results were almost the same as native C++ ( I underlined it because its interesting). I made also some tests with Haskell and the results were even better (but I still lack the experience (and confidence) in Haskell). So in conclusion AI algorithms can be wrote in any language , the difference is in performance and specially when we talk about AI , performance matters.

Is there any specs how the first select “GRAPHIC SIZE” is selected ? I would bet that anyone would want it to be ordered by how many times are there. But I could bet wrong , simple WE DONT KNOW. First Jacques1 you proposed an all PHP solutions with arrays and building them without any clue to the creator of this post of how to do it. I am fine with that approach , its great but there are other approaches also. Then in the second approach that I PROPOSED you have a disagreement of the use of “SELECT DISTINCT” vs “GROUP BY” this wasn't what I proposed at all … Copying from my first reply “You can do it in many ways and GROUP BY is one of those” it all depends of what really needs to be done . If how many records are there go with the “SELECT DISTINCT” if how many records affect the order go with “GROUP BY”. No need to disagree where there isn't a issue to. (let's keep that for when we really disagree)

Hello Jacques1, As I wrote there are many ways depending on schema . One of those is “SELECT DISTINCT” but the “GROUP BY” would allow us to list them in an order of how many records are there in each case. We don't have any clue of the specs so let's give all options. We also don't know the table. I still agree with your first reply that can be done only with PHP, but it can be done other ways also. We don't have to disagree only for making it interest

My humble suggestion is before watching any video read the OOP theory and try it your self. If you can try it in a real life project also. You put “dependency injection” that is a basic feature of OOP , with the factory pattern in the same sentence. What is next there ? Encapsulation ? Having a sufficient understanding about OOP you could learn more about loose coupling and make your own tests. But having a real loose coupling architecture in most projects doesn't worth the effort and the disadvantages of maintaining the code, sometimes it does.

what exactly don't you understand here ?

One way would be what Jacques1 suggested. If you don't know how to turn the results array into an array that has a more convenient format , you can write what you tried and we will help you from there (but please , first try something). The other approach is using prepared statements (that from your code I can tell you know the basics) to select first the different “GRAPHIC SIZE”. You can do it in many ways and GROUP BY is one of those. Then having those and using each “GRAPHIC SIZE” you can select different donors that correspond in this (again you can do it with GROUP BY). Finally you have the “GRAPHIC SIZE” and the donator , so you can perform a simple select to get the images (the priorities in each select is up to you). Using prepared statements (and the PDO objects of those) will make the performance really great IF you don't have a great amount of “GRAPHIC SIZE” and a great amount of “donators”. In any case you should consider creating another table of “GRAPHIC SIZES” and another for donators and have in this table only the id of those records. That would be the reasonable way but also would allow you could scale your app easy if records are more than you anticipated.

Hello CB150Special, In those few lines of code there are many things that could be said. I will state only one of them. ID's in HTML should be unique , you have two buttons with id “button” . Fix this and if your problems stay we can see it further. When we have a problem in a core understanding its easier to create a test project with only the parts needed. For example here you state that isset($_POST['submit']) is false, so make a simple test with only this (no db , nothing else included that we don't see) , and if this doesn't work post it here to let us figure out why.

Yes Jacques1 anyone should know that , but since you stated that I can change it after a while its ok for me...

Hello, Nice to see you again . I am trying to change my profile image but I am getting "member_profile_disabled" I have tried both png and jpg so what is the issue here ?

Anyone participating in a forum should try at least to understand what the other person says. That you are a “beginner” doesn't exclude you from this rule. You store in your db a “field_list” that is actually an array that has been imploded by comma. What is the reason for that ?. If you know the field couldn't you create the same fields in db? RDMS means Relational database management system and if you have all of your fields in one big txt field there is not relational no more. It is like storing your data to a txt file without even the index files we used those days (copybooks and etc).