.josh

99% of getting your question answered is about presentation, not the actual problem at hand. Your question isn't very clear, and your formatting sucks. Is that good enough, or do you want to continue to whine about not getting help, and bitch when someone tells you like it is? What kind of response did you really expect from a thread like this? There isn't a single positive answer to a question like that.

yes. usually the server you connected to occasionally pings you and you have to look for it and pong them back, or else it assumes you are inactive and disconnects you.

Ranks are based on quality, not quantity, because we handpick who to promote to the different groups (guru, phpfreak recommended, moderator, admin), based on how long they've been here, how much they've contributed yes, but if they've contributed worthwhile stuff vs. random misc. topic stuff, etc... basically the goal is in order to get promoted, you have to have proven that you aren't just a random hit-and-run person, are willing to contribute, and you actually know wtf you're talking about. We feel the most accurate way to promote someone based on that criteria is to hand-pick them. Any guru+ member can nominate someone else, and any guru+ can cast a yay or nay vote for the nominee. We do have post-based ranks in place, but they have been purposefully made ambiguous to some kind of "knowledge" assertion, so that people do not get the wrong impression. For example, your post based rank is "Irregular", SA's is "Fanatic", Maq's is "Freak!", mine is "Insane!", etc..

it's the 130 character or less generation, what do you expect?

okay... markup standard? markup description? markup rules? markup definitions? markup (all by itself, just like .htm pages)? markup information?

I concede that in the broadest of terms, it can be classified as "a language," although I maintain that it would be better classified as something else, like fenway's suggested "template". But in the context that it is used in 99% of the time, that's where I have issues. The issue being that average Joe does NOT make the distinction between markup language vs. programming language. My compromise is renaming it to htlm instead of html, in the hopes that people can better understand that it is not a programming language.

it matches anything that is not a space shortcut (\S) \S : space, tab, newline So in the end $newString will not have any tabs or newlines.

preg_match_all('~\S+~',$string,$matches); $newString = implode(' ',array_slice($matches[0],0,79)); echo $newString;

To me, language markup and markup language are two different things. Yes, it is "officially" called markup language, but IMO clearly it should have been called language markup.

it also may match additional characters based on locale settings. For portability, safest bet is to not use shortcut classes.

which is why I don't consider it to be a language, but a system, a "template" (thank you fenway). I maintain that "language" was snuck into the name by marketing.

kinda off-topic but here's an example of using the 'e' modifier with preg_replace: $string = "A AA AAA AAAA AAAAA AAAA AAA AA A"; $string = preg_replace("~(\w{3,})~e","strtolower('$1')",$string); echo $string; output: A AA aaa aaaa aaaaa aaaa aaa AA A

dude, it's "markup language", as in, you are marking up a real language (english, spanish, etc...) not as in a coding language in and of itself. Maybe if they had made it htlm it would be more clear to you.

so basically what you're saying is someone can type "asfuckshole" and you replace fuck with nothing and you wind up with asshole? I suppose if you really wanted to address that, a recursive function would do the trick.

Seriously, do you want to really know how "language" got pasted onto the end of html? It's because back in the day real programmers got tired of listening to the designers and copy editors whine all day about making shit bold or a certain font size and them having to go through all this trouble to make it as such so they put in the work to make tags for them to wrap it around themselves and told them how to use them. Next thing you know those designers and copy editors fancy themselves as programmers because they now have this magical ability to make shit appear different on a screen. Can't tell the difference between them being the ones deciding what gets marked up, vs. a program deciding what gets marked up.

{ } are not operators in css. They simply mark the beginning and end of the class or id property block. In php, they also mark the beginning and end of something: code blocks, like functions, classes, loops, and conditions. They can also be used to specify character positions in a string. This is not an operator even in php. css has no operators because it is not a language. < > are not operators in html. They mark the beginning and end of an opening or closing tag. An operator is not the same thing as a tag. In php they are logical operators, meaning less-than and greater-than. Html has no operators because it is not a language. Operators are mathematical "verbs", like: + addition. a plus b - subtraction. a minus b * multiplication. a times b / division. a divided by b = assignment. assign a to b == positive comparison. a equals b != negative comparison. a not equal b && logical comparison. a and b || logical comparison. a or b etc... <?php ?> and <% %> are somewhat like <html> </html> in that they mark the beginning and end of code, yes. This about the only thing you (sort of) got right in your post. Yes, that would certainly be a killer "how can you argue with that?" point, to average joe who doesn't know any better. The obvious thing about the "l" in html for someone who does know better, is that it is a buzzword. If we were to look at the actual copy of a page as a "noun", html and css would be like "adjectives." php, asp, etc.. would be like "verbs" but they would also be responsible for the "grammar rules". html/css is used to describe things. php etc.. (languages) are used to make decisions and do things. Next thing I know you're gonna tell me ajax is a language.

$photo = substr($photo,0,-4); echo $photo; or $photo = explode('.',$photo); echo $photo[0]; or preg_match('~^[^.]+~',$photo,$match); echo $match[0];

I'm not disagreeing in general; one should at least learn basic html before php, if one is wanting to get into web design. But there's lots of stuff you can do with php where you never touch or need to know anything about html. In fact, the whole idea of MVC is that you don't need to mess around with html when you are coding, and you don't need to know how to program to be a designer. Knowledge of css as a prerequisite is somewhat questionable even under the best of circumstances, as ideally a coder should be coding and a designer should be doing the css. Do you consider bbcode on this forum to be a language? cuz I mean come on be honest, that's what html pretty much boils down to. html is not a language; it's a bunch of markup tags. You can't honestly put php in the same boat as html. html marks up static content through tags with attributes. css picks up where html left off, as far as attributes. php generates dynamic content through loops and logic. Pushes data around from files to pages to databases. Manipulates data with various functions both user defined and built-in. There's just no comparison.

well if they knew the answer they wouldn't be asking in the first place. p.s.- I don't really consider html and/or css to be a language...

Haha no, I do not have an official blog, but I do occasionally get asked that.. dunno though.. 9/10 times if my post is longer than like a paragraph or two, people summarily dismiss it as TLDR. Kind of a gray area. Depends on the context, who is making the decision, how the stars are aligned, etc... in general the safest bet would be to post the actual article you wrote. Some people don't wanna do that though, because of our ToS (nothin' special..just the avg. "if you post something you grant us full rights to use it blahblah" sort of thing) . Could alternatively put a link to your blog in your signature and then make a post mentioning to go to the link in your sig. Which is kind of indirectly the same thing, sort of. But whatever.

and to add scope into the lego analogy: You have a 2x2 brick well the point of scope is that you know that that 2x2 brick will always be 2x2 and won't magically or unexpectedly change into a 2x3 brick. Unless you intentionally make it that way, but then that in and of itself becomes a brick that would not change. Point is, scope enforcement (wrapping things in functions and classes, using getter/setter methods, etc..) allows for those lego blocks to be taken from your robot and used in your pirate ship, because you know it will fit just the same.

dude I feel you. It took me a very long time to really get past the "why bother, it just seems like a more bloated way of doing things" mentality. And 9/10 times the logic holds true, not because that's how OOP is, but because 9/10 times people aren't really coding something that really needs to be coded in that fashion in the first place. Or else, they aren't coding with true OOP mentality in the first place. Thing is, you are not really going to find any code examples of OOP being better than procedural (at least, not "simple" ones), because OOP is all about a state of mind and way of coding, and also, OOP mentality is on a larger scale than procedural. In order to understand OOP better, look at a normal procedural function. Why do you use functions? You have a bit of code that is highly reusable and instead of having to write it all out every time, you can just write it out once, wrap a label around it, and call the label (the function name). You can hand out your function to other people and they don't have to know what's going on in the function; all they need to know is what it does. This is pretty much the exact same idea behind OOP. So you ask, "But why not just hand them a bunch of functions, same thing!" Ah but here's the thing. Go back to your function. The thing most people tend to overlook about functions is scope. When you are inside a function, you are within a different scope. Variables created in a function have their own namespace. So for example: $x = 123; function blah() { echo $x; } $x will not echo anything in the function because as far as the function scope is concerned, $x doesn't exist. But if you were to do this: $x = 123; function blah() { global $x; echo $x; } The function will now echo 123, because you have specified that you want to use the $x from the global level. But this is generally considered to be bad practice. Why is that? It is bad practice because you are defeating the purpose of scope. You are creating a way to disregard the boundaries. You are making it possible for something outside of the function affect what happens inside the function. So why is that so bad? The reason why it is bad, is because the point of a function is that it's supposed to be a piece of reusable code that since you know for 100% sure what it's supposed to be doing every single time, you can abstract it away into that single label, and know exactly what's going to happen when you call it. But if you transcend scope, you can no longer 100% guarantee that. Something goes wrong, a bug you're trying to track down. Well it could be happening in the function but it could be because something is happening with $x somewhere else in your script. When you are debugging, your function shouldn't be one of the places you should have to look for the bug, because you should know 100% already what its supposed to be doing. It's like trying to debug your code by looking under the hood of the built-in functions in php, like for instance, if you have a script that goes through an array to do something but it's not working, do you look in to seeing if your (for example) in_array is really searching all the elements in your array, or do you just assume that it faithfully checks all your array elements, instead of only a couple? You assume it is doing exactly what it is supposed to. It accepts certain arguments, gets called a certain way, and that's it. I cannot set some variable on the outside to change what it does on the inside. This allows me to know 100% that it is going to do what it says it will do, regardless of what situation I put it in. This is the same thing that that should apply to a function you make yourself, and this is the same core idea behind OOP. The core idea of OOP is adding additional layers of scope, in order to abstract pieces of code, only on a larger scale. OOP is in concept the exact same as a function, only on a larger scale. Script vs. snippet, sort of thing. And bigger scale means more things to consider. When you code procedural style, you have an arsenal of functions that you use, but then a bunch of other code that actually uses it. Variables, loops, blahblah whatever. You make a login script or form validation script or whatever. But then you make enough login scripts for people and you quickly come to the conclusion that not only are the functions themselves reusable, but the whole damn script is reusable, minus minor tweaks. So you can wrap another label around it: a class; a collection of all the variables and functions you use. Create some arguments that can be passed to it to handle those minor variations. Which brings us back to scope. Just like with the function, you want to make sure that random things outside of that class does not affect what goes on inside the class. If it does, then you can no longer guarantee the class will do what it is supposed to be doing 100% of the time. So you can set "permissions" on things. Set it to where people can directly call or set a method (function) or property (variable) from outside of the function, or only from other things within the same class, etc... You have "getter" and "setter" methods in a class to retrieve or set a property value, instead of directly accessing the property, because that creates a scope, a boundary for those properties. If the only way the property value can be changed is through the setter method, this gives you guarantees everywhere else that that property is always going to be xyz (a certain variable type, certain string length, whatever the case may be), so that other methods or whatever will not have to all do the same thing. Like for instance, if you have two methods that use the same property, well if the property is supposed to be a string of 10 characters in a certain format, would you write out validation in both those methods, or would you create another method (function) to validate it, since its the same code being used over and over? That is in essence what that setter function is. The setter function's job is to take the raw value and make sure that the property only gets set as that 10 character string. Truncate it, cast it, pad it, call something else that spits back an error, whatever. Point is, in those two methods using that property, you don't have to deal with it, because you've abstracted it away with those getter/setter methods. Thing is, you are in fact sort of indirectly programming in an OOP style already, but just don't realize it. When you for instance try to call in_array, but pass it too many or two little arguments, or pass it the wrong type of data, you get an error spit back at you, right? Do you think that happens within the in_array function? No! in_array (and all other built-in functions) are in fact not really functions, but methods (in principle). We just don't have to do something like $this->in_array because it's already implied, because we can't work on a level lower than in the script that we send to the parser. Kind of the same principle as with javascript and being able to do document.whatever instead of window.document.blah. Point is, when we use in_array, it is actually one of those "getter" methods in the php core that first validates the arguments being passed to it. If things aren't good, it calls other methods that ultimately spit out an error or whatever. If its good, then it calls the real methods that do the job as described in the manual. Most people just don't think of it, and that's the point! All of that stuff has been abstracted away, so that all we have to think about and consider is the description and rules of engagement as specified in the manual. And that's the same thing with OOP. OOP as a way of programming is somewhat more complex than even this, but in my experience of seeing people struggle when they first start out (and in my own experience as well), the main stumbling block is scope. Once you really understand (or at least, make the connection, because I'm sure you understand scope just fine, on a single function level), the rest falls into place a lot easier.

well when someone is asking an html question they probably are new to code on any kind of level, and therefore don't know any better. What's more annoying is the other side of that coin: when people post html/css questions in the php help forum. While (IMO) it's understandable if an html noob mixes shit up, if you're at the point of coding php, you should know by now the difference between php and html. But even then, it's not annoying that they don't know; I rarely see html questions in php sections where I feel the user truly doesn't know. Real reason it's annoying is that the person does know, and they are purposefully posting in the php section because it's higher traffic and they want their question answered faster.

I didn't give you an example of how the code should be. I gave you an example of what your code outputs. Your OP code outputs as: [pre] <ul> <li><a href="Data"'123'>FILE</a></li> </ul> [/pre] It needs to output as: [pre] <ul> <li><a href="Data/123">FILE</a></li> </ul> [/pre] Or I guess with a backslash if you're using windows... This is how your quotes should be (change the / to \\ if windows) $display_block = " <ul> <li><a href=\"Data/".$_POST["sel_id"]."\">FILE</a></li> </ul>" ;

Do we need more people for what?