PHP debugging techniques: some suggestions

[Guest LH91325]

In reading some recent topics it has occurred to me that many beginners are tackling complex languages without having the benefit of some basic programming skills. It's easy to become enthused abouut a programming language, perhaps PHP, and then see the challenge as learning how to write PHP. But that's not the challenge! Writing in any language is almost the same. The main problem is understanding programming techniques. Two of the basic skills are organization and debugging. Organization is the concept that your program or website is a big box, and that is composed of smaller boxes. There is some basic level where the boxes are simple, and they get used often in the bigger boxes. Sometimes these boxes can be made into functions (if they're used often enough). The problem that many beginners face in asking for help on a forum such as the current one is that they blast out a bunch of code, quite possibly a bunch of HTML and PHP and MySQL queries, and surprise, surprise, it doesn't work! They post a few hundred lines of code on the forum and ask for help. We all know that there's bound to be 2-3 dozen problems ("surprises") in the code. Few want to tackle helping newbies with such a huge job, particularly for free. I have a few ideas that may help. My examples apply to PHP but you can do the same thing in every language. (Every language has a "Hello world!" example, right?) I find it difficult to not admire the LAMP platform (Linux, Apache, MySQL, PHP), all of them open source and free to use. Buy a server (or PC), pay for your Internet connection, download the four LAMP components, and you've got a remarkable publishing platform! And only out the cost of hardware plus the cost of your Internet connection, no purchased software necessary. So let's start: Organizational problem #1: Make your big problems into little problems! Don't write 200 lines of code and then ask us why it doesn't work! Instead, write 10 or 20 lines of code and get that to work. Other things being equal, 20 lines of code will have 1/10 as many bugs as 200 lines of code. You are 10 times as likely to write good code if you write just a little not a lot, and 10 times more likely to have willing volunteers on the forum help you find out why it doesn't work. Conceptual problem #1: You're asking for help in the wrong place! Ask for help on the forum and you may get help in hours, days or sometimes weeks. But ask your code the same questions and you may get answers in seconds or minutes! The remainder of this post will address how you can ask your code to tell you why it won't work. Organizational problem #2: Start out simple. Don't write a whole mess of HTML, PHP and MySQL queries and then ask yourself (or the forum) why it doesn't work. Write a few lines, test it, fix what's broke, then add more code. Don't add more complexity until you get what you've already written to work. This is the stage where you can expect help from an Internet forum. PHP debugging techniques: Start out with "Hello world!." Here it is: <?php echo "Hello world!"; ?> Upload it to your server and see it in your browser before you proceed. You won't be doing any debugging until you have basic connectivity established. Maybe you named your index file index.php.html ... There's no point in writing 200 lines of code to discover this. This one line will let you know you have a problem and you don't need the other 199 lines of code. Does your PHP code have branching? (if, switch, while, for...) Put in debug statements. When your server is 3 timezones away you have no idea if any particular code executed. A simple echo "Awk!"; will tell you execution got to a particular statement or line. If you see "Awk!" in your browser then it got there, otherwise not. This is just an extension of the "Hello world!" concept. Dump your variables. If you have a variable $awk and you don't know what it's doing, ask your code to tell you: echo "awk: $awk";. Expand this concept for multiple variables or a single variable at multiply different places. Just change the comment to indicate the variable or point of execution. You can put this in comments too, to not disturb HTML code rendering: echo "<!-- awk: $awk -->"; Use your browser's View->Source to see your debugging comments, and your page rendering remains intact and undisturbed. More complicated variables? Perhaps arrays? Use PHP's print_r or var_dump: echo print_r($some_array, true); If you like, put it in a comment as shown above. Also, print_r is more structured and easier to read if viewed in source. Don't want to put it in your HTML or comments? Or is there a problem with doing that? (I've had that often.) Put your debug statements into headers: header("Awk: huh?"); or header("Awk: $awk");. I sometimes do this using Firefox and it's Live HTTP Headers Add-on. You can see your debug information by looking at the HTTP headers and not disturb anything on your site, works great for production sites where you don't want a bunch of debug stuff to show up on visitors' page views. (You may need output buffering if your code emits HTML before your debug statement. You can't add headers after any HTML is sent. You can enable output buffering until you send your debug header and then flush the buffer and continue as usual.) PHP queries? Write your query in the form $query="....." and echo the query, perhaps to HTML comments. I presume there will be variables there, rendered into their exact values when your code executes. Cut 'n paste that from your View->Source to a query line in phpMySQL. Then you can see why MySQL is complaining about your query. Don't do raw queries. Write an interface routine and run all your queries through that. Add debug code so that you can see your queries in comments. I have mine under an admin cookie so that visitors don't see my debug stuff. Here's my code:

function do_query_db($query) {	global $context;	$time = microtime(TRUE);	$result = @mysql_query($query);	$context['db_accesses']++;	$context['queries'][] = $query . ' (' . number_format((microtime(TRUE) - $time) * 1000, 3) . ' ms)';	return $result ? $result : false;}

I have an exit function that is called at the end of every site access. It checks for my admin cookie, and if an admin then it echoes a debug section including the value of $context['db_accesses'] (how many accesses the page needed) and a print_r of $context['queries'][] which as you can see gives the full query plus the execution time in milliseconds. Yep, I'm proud of thinking up that twist! (I also track how many scripts are included, and which ones.) This is all under an admin setting that I can turn on or off depending on if I'm debugging code, but in any case site visitors never see it. Well these are just a few of the techniques. Perhaps other experienced programmers can add their own ideas too.

Edited May 12, 2012 by LH91325

[thescientist]

Very nice. I really hope a lot of (or at least one) member(s) take head of the good advice here. It's always what we say over numerous threads, but at least now it's nice to have all the good debugging practices in one place. Maybe it could eventually get pinned. Maybe you can expand upon what you have to include some tips for debugging forms like you have mentioned in another thread. That always seems to throw a lot of beginners for a loop because for whatever reason, they never think that there's something wrong with form or the PHP, because as you so well stated, they don't approach it in steps. They just put the form (HTML) and PHP together and never check that the form is even submitting right in the first place.

[Guest LH91325]

Thanks for the compliments TS. Not so sure about pinning since the people who need pinned topics the most are usually the ones who won't or don't read them. The surest way to get a topic ignored is to make its title: "Read Before Posting." Pin that! It occurs to me that I forgot a few ideas I had intended to include in the OP. 1. In addition to all the above, you can write debug information into a text file. Get a nice debug routine written and debug it and get it working for sure, and then you can include it as a function in your code you're writing. It can be as simple as a function debug_write_to_file($string) which opens a debug.txt file and adds the string then closes the file. You can call it like this: debug_write_to_file("awk: $awk"); or debug_write_to_file('awk: ' . $awk);. Then either FTP the file back to home and open it to see what happened or just http://example.com/filename.txt 2. Do the same thing except you put it in a MySQL table instead. I have this incorporated as a permanent part of my code, where I use it for debugging or sometimes I don't know if an error ever happens or could happen so I just leave a conditional call.

function write_error_journal($type = 'unspecified', $comments = 'none') {	$date_time = date("Y-m-d H:i:s ", substr(microtime(), 11, 10) - (3*60*60));	$query = sprintf("INSERT INTO error_journal (`type`, `unix_time`,  `date_time`, `comments`) VALUES ('%s', '%s', '%s', '%s')", $type, substr(microtime(), 11, 10), $date_time, $comments);	do_query_db($query);}

You can call this with write_error_journal('debug', 'awk = ' . $awk);. Then you can use phpMySQL and just look at your table to see what happened. For multiple events just set $type to different labels. Date and time provide additional information, and you can include anything you like in $comments including variables or whatever. This routine is a bit more complicated than necessary but more information is always better than less information when debugging. I like raw UNIX time in seconds since 1 Jan 1970 00:00 UTC because it's so unambiguous. But I included a human friendly Y-m-d H:i:s too. (The 3*60*60 can be interpreted in English as "my shared hosting service server time is 3 timezones east of me!" ) In any complicated website you should include debugging sections as part of your permanent code and then turn them on or off depending on your needs. And also it helps to cookie it on a production website so that only the admin sees debug information. (Sites with high traffic or critical information like financial data should use separate test websites and not expose customers to potentially buggy code.) 3. You can email debugging information to yourself. My site does that too, for exceptions. Get the email code working first, then selectively call that if some kind of exception occurs. This is of more use tracking down rare errors than in daily debugging of code. You can email yourself a reminder to look at your error_journal table to see what happened. 4. Conditional debug: Add debug code like if ($debug) { /* debug code goes here */ }. Then insert a line at the top of your file, $debug = true; or $debug = false;. (The latter is really unnecessary since undefined is equivalent to false.) Then you can turn it on and off to see if you're getting there yet. I usually use this method when I need to flip back and forth between debug and non-debug code. I usually delete this kind of code after the main function is working. The main point in this topic is that there are almost unlimited ways to get debugging information from your code. You don't need to rely on getting help from an Internet forum when your code can help you directly to find and remove your bugs. Just tell your code to tell you what's happening. An additional benefit is that your code won't snap back at you for asking too many questions!

Edited May 12, 2012 by LH91325

[thescientist]

Not so sure about pinning since the people who need pinned topics the most are usually the ones who won't or don't read them. The surest way to get a topic ignored is to make its title: "Read Before Posting." Pin that!

at the very least we would always be able to have a consistent thread to give newbies a link too. Something that could be easily maintained, updated, and relevant.

[boen_robot]

<< Topic pinned >>I've pinned it for now, and also, if you don't mind... I've made some "headers" for the sake of easier reading.Maybe we can rework it later, but this is good even like that.BTW,

Organization is the concept that your program or website is a big box, and that is composed of smaller boxes.

I think exactly like that, and used to think anyone who ever went into programming thinks in the same way, but after seeing Temple Grandin's TED talk, I'm not so sure. The better programmers (pattern thinkers), sure, but probably not all.

[Guest LH91325]

I've discussed leaving some debugging code in place. You can use it to monitor the performance of your website, including your Apache server, PHP script execution and MySQL accesses. Did you ever wonder how long it takes your page(s) to load, how quickly pages are served, which scripts are executing, exactly what MySQL queries were performed, and how fast your MySQL server is? Maybe some of your queries are really inefficient and add a whole bunch of time to that necessary to serve your pages. Humans may get annoyed if your site loads slowly, and at least Google says they include site performance as one of the criteria for page ranking. With suitable debugging code left in place you can answer all of these questions. I'm going to use my own site code for these examples. First off, every service on my site starts with my index.php script and the following code. You can adapt the idea to multiple PHP pages if your site is served by multiple scripts:

	$context = array();	$context['unix_time'] = substr(($curtime = microtime()), 11, 10);	$context['microsec'] = substr($curtime, 2, 8);	$context['page_loads'] = 1;	$context['pages_loaded'] = array();	$context['pages_loaded'][] = __FILE__;

You can call this array anything you like. I got variable the name from a forum software I used to work on. The idea about the array with named indexes is that you can fit anything you want in the array, there's always room for more debugging or system state information. I put all the visitor's header information in that array too, UNIX time, request method, URI, remote IP address, client name if resolved, ISO 2 letter country code (from my IP to CC database), user-agent string, my decode of the user-agent string (Firefox, MSIE, Google, Yahoo), referrer, etc. After the content has been sent my script adds the HTTP response code (200, 404, etc.) and writes it to my MySQL logging table, including how long the entire process took from first script access until content sent and operation logged. My log shows how long every transaction took, very interesting when wondering how your website is performing. My site has just one main script: index.php which all traffic goes through (including error documents, so I can log them too). This type of site is commonly called a dynamic HTML generator. It figures everything "on the fly." My index.php starts with the code above, collects as much of the logging information as it can right at the start (and reads in my $settings[], the only other global variable used, initialized from a settings table in my database), and then analyzes the type of request to determine which of a couple dozen scripts can handle the job. (There's a common script too, with all the common functions that are used in every script.) Along the way it adds any additional information to the $context[] array. (There's just these two globals, both arrays. Good code minimizes the number of globals, because that reduces interaction which in turn reduces the likelihood of bugs. Admittedly two arrays isn't quite the same as two simple variables, but it works for me.) Not all the data I stuff into this array is necessarily used. It's put there in case I need it later, which depends on the context of what happens next. Thus the name of the array. Each sub-script starts out with the following code:

$context['page_loads']++;$context['pages_loaded'][] = __FILE__;

That adds the name of the include file (script) and keeps track of the number of scripts loaded. As it turns out every access to my site uses exactly 4 scripts. The first three are always the same, and the last one is specific to the type of access. My error handler is one of those, the place execution always ends up if nothing else applies. (I'm using my .htaccess file to funnel errors into my index.php.) Here's the final function that puts it all together. This function is always called at the end of the execution of the last sub-script, and it's called right after the second to last operation which is the logging function that writes the results of the site access to a MySQL logging table.

function script_exit() { 	global $settings, $context; 	if (!defined('ADMINISTRATOR')) exit;	if (empty($settings['show_footer_stats']) || !$settings['show_footer_stats']) exit; 	$now_sec = substr(($curtime = microtime()), 11, 10);	$now_msec = substr($curtime, 2, 3);	$start_sec = $context['unix_time'];	$start_msec = substr($context['microsec'], 0, 3); 	$elapsed = 1000*($now_sec - $start_sec) + ($now_msec - $start_msec);	if ($elapsed < 1000) $time = $elapsed . ' msec';	else $time = number_format($elapsed/1000) . '.' . $elapsed%1000 . ' sec'; 	$additional = "\n\n<!--\npages loaded:\n" . print_r($context['pages_loaded'], true) . "\n";	$additional .= "queries:\n" . print_r($context['queries'], true) . "-->\n\n";	echo "\n\n" . '<html><body><p><span style="font-size:10px; color:blue;">' . "\n" . $time . ', ' . $context['page_loads'] .		' page loads, '  . $context['db_accesses'] . ' queries' . "\n" . '</span></p>' . $additional . '</body></html>';	exit;}

It starts out seeing if the site visitor is the administrator, i.e. me. ADMINISTRATOR is set early in execution by a cookie that only I have so this fails for ordinary visitors and this debug section terminates. Next it determines if I have the debug code switched on, a setting called 'show_footer_stats'. I can turn this on and off from a configuration page (a form) that updates my settings table. The code continues to execute only if it's the site administrator and the debug code is switched on. It continues on to calculate how much time elapsed (milliseconds or seconds) from the very first script load right up to this final act of the script. (I keep my times in UNIX seconds and separately in microseconds, for reasons unimportant to the example, you could just as easily store the full microtime() and calculate on that one number. In that case use a float variable.) Then it calculates a debug summary. It shows the total access time in seconds or microseconds, the number of PHP script page loads, and the number of MySQL queries. Here is what that part looks like in real life:

33 msec, 4 page loads, 11 queries

This shows up as the last thing on any page, but only for me the administrator. (That was a pretty nice access time. I often see accesses in the 100-200 msec range.) You may have noticed that this constitutes a second <HTML><BODY>.....</BODY></HTML> in the document's HTML code. Certainly this is a gross violation of HTML coding standards, but visitors never see it, it's just debug code, and it works. (It's ironic I was just yesterday criticizing a beginner's site for having multiple HTMLs and BODYs. The truth of the matter is that almost any rule can be violated if the reasons are right. No site visitor will ever see this malformed HTML code.) The rest of the action occurs only in the source code because it's enclosed in HTML comment delimiters. This is partly because usually I don't need that information, and partly because the print_r is much more nicely formatted when you view source. Here's what the page's HTML source code looks like:

pages loaded:Array(	[0] => /...../htdocs/websites/example.com/index.php	[1] => /...../htdocs/code/main_code.php	[2] => /...../htdocs/code/common_functions.php	[3] => /...../htdocs/code/some_script.php) queries:Array(	[0] => SELECT * FROM `settings` (0.884 ms)	[1] => SELECT * FROM `html_content` WHERE `doc_root` = 'auto' (0.934 ms)....	[9] => SELECT * FROM `html_content` WHERE `doc_root` = 'html' AND `doc_name` = 'index' (1.230 ms))-->

First of all, I've deleted some of the information because it's not important for the example. I may have changed a few names to protect the innocent. Finally, the logging operation is not shown because I don't normally log administrator accesses. I can turn that part on and off from my settings. You can see from the first array that my index script loaded. It initialized a few variables as I've shown in code snippets, it sets the 4 necessary values to connect to the MySQL server, and then it jumps to (includes) my main code. The main code does a few more things and then it includes the script with my common functions. The rest of the processing is to determine what kind of access is being requested, in order to determine which final scrip is needed to get the job done. Is it the index page? Is it a content page? Is it my robots.txt file or perhaps the sitemap.xml file? Is it an image? Is it CSS? Or maybe it's one of my admin functions, perhaps asking for my configuration page. Or maybe it's an error and the error handler is required. In the case of this example it was an access to the site index, and something I've called some_script served it. The last two things that script did was to call the logging function and then call the script exit function that we're presently discussing. Let's look at the MySQL queries. Note that the example is a bit unusual because as I said I don't normally log my admin accesses. If it had been a real visitor some of the accesses would have been UPDATE accesses, including #8 which would have been an INSERT into the MySQL main logging table. The first MySQL access is loading the entire settings table (a hundred settings?). The code loads all of the settings into one $settings[] array, well worth the 0.884 milliseconds. The next MySQL query loads several or a dozen text-html strings that almost all accesses use, including my common header and common footer appearing on every page. It goes on to show every other MySQL query (and the time for each) right up until the script decides that I was asking for the index page, so it loads the HTML code for the index, slaps on a header and footer, and ships it off to my browser. The End. Well I guess I've been typing an hour and I hope I didn't make any mistakes because I'm too tired to proof read this. I've started this topic with a simple debug statement echo "awk! to tell if your code actually loaded, all the way to a level of rocket science where the debug code tells you loads of information about script loading, MySQL accesses, how long everything took. With a variety of these techniques you can find out almost everything about anything that your code is doing. To summarize the topic, everybody faces code debugging problems. When you are a professional working on the job you won't have the time to ask your colleagues to debug your code for you, and you won't have the luxury of posting a question on the Internet and waiting a few days to see if anybody wants to volunteer to debug your code. A professional must handle any and every coding problem that develops, and must solve all their own problems usually by themself with no other help. On the job the only thing you can do is to ask your code what the problem is. The way you do that is by including debugging code. The examples I've used above range all the way from novice techniques to advanced/expert techniques. You should understand that I've given only a few dozen examples while in fact there are limitless ways to debug code and to write debug code. You should constantly think about your debugging problems and then you pick good questions you wish you could ask--and then you ask your code to tell you the important answers you need to fix the code and get it running. You'll learn more from debugging your own code than you will by having somebody on the forum feed you the answers to debugging problems. And as I pointed out, in the real world a programmer almost always has to solve all their problems on their own. The quicker you learn debugging techniques the faster you can move up the beginner-intermediate-advanced scale. Go ahead: ask your code to tell you why it isn't working! Ask good questions and your code will give you good answers.

[Guest LH91325]

<< Topic pinned >> I've pinned it for now, and also, if you don't mind... I've made some "headers" for the sake of easier reading. Maybe we can rework it later, but this is good even like that.

Actually I do mind. I get annoyed when people change my posts without asking first. I formatted my post the way I wanted it to be formatted. ETA: Okay I fixed it back... I just spent more than an hour writing the next post, and I got it exactly the way I wanted it, too. And we aren't going to rework anything later. If there's any reworking to be done to my posts I'll be the one doing it. Okay, enough said, sorry to snap at you. I hope other members will have some interesting debugging techniques to add to the topic. As I said, I've given just a few examples of debugging techniques. There's infinite numbers of ways to debug code. Edited May 12, 2012 by LH91325

[boen_robot]

When I said "we" I meant "the moderators", and I don't mean (necessarily) editing your post, but rather, write a new topic that retells your points (perhaps even directly copy&paste portions), and unpin this topic afterwards (... and give you credit where it's due of course).Do consider some headings though... for most people (myself included) a blob of text is very (and I mean very very) difficult to read. Headings give you something to look forward to, plus they serve as "bookmarks", should you read the text in more than one sitting. Headings are in fact the main thing that lead me to even mention the word "rework". Other than that, I only needed a skim to see you have gold here, but that's just me, since I'm already aware of this stuff. Your target audience (beginners) wouldn't know that - they'll just say "later", and that "later" will never come.

[Guest LH91325]

Organization is the concept that your program or website is a big box, and that is composed of smaller boxes.

I think exactly like that, and used to think anyone who ever went into programming thinks in the same way, but after seeing Temple Grandin's TED talk, I'm not so sure. The better programmers (pattern thinkers), sure, but probably not all.

There have been arguments about proper programming methods ever since the first programming language was invented. However... Problems are always big problems with littler problems wrapped inside, and even littler problems inside the littler ones. Call them bugs if you like. It's much easier to solve little problems (fix little bugs) and then work up to the bigger ones. The problem with many of the posts requesting help in this forum is that the person with the question posts a great big gob of code that obviously has tons of bugs, an infestation! They would get help quicker if they posted smaller questions about less code. Or they can get help the quickest by figuring out their problems and bugs on their own. The way you do that is by hierarchical design. There's another programming concept that is in much dispute: top-down design or bottom-up design? I've done it both ways. Group projects almost necessarily have to be top-down. Otherwise all the workers each start building their own house of cards and when it's time to fit on the roof the walls don't match. The kind of techniques I've described can be applied to whole projects, or can be applied to modules that are part of larger projects. All my own projects are small, individual projects, so I stick with what works best for me. I write a little nucleus of code. I get it working. Then I use it as a building block to make bigger things. Here's another debugging concept: the test fixture. Let's say you're designing a function. Doesn't matter what it does. Write a bunch of code and put your buggy function into a larger mess of code and you may have all kinds of problems, interaction, interface problems... Instead write some test code, only the minimum necessary to call your developmental function and then tell you what the function returned or what it did. You can set some variables to test values and then pass them as the arguments to your function, and then display whatever the function returned. You can put debug statements inside your code too. Once you have your function working with your text fixture you can cut 'n paste the function into a bigger body of code, secure that you've already debugged it and it probably will work with the main code. Your test fixture can also serve as a nice application example if somebody else is going to use your code in their code. It shows how to call it and what you get back.

[Guest LH91325]

Do consider some headings though... for most people (myself included) a blob of text is very (and I mean very very) difficult to read. Headings give you something to look forward to, plus they serve as "bookmarks", should you read the text in more than one sitting. Headings are in fact the main thing that lead me to even mention the word "rework". Other than that, I only needed a skim to see you have gold here, but that's just me, since I'm already aware of this stuff. Your target audience (beginners) wouldn't know that - they'll just say "later", and that "later" will never come.

Thank you for the advice. I may have neglected to mention that I have written and had published articles in computer programming magazines going all the way back to C Users Journal. As it turned out they published my articles exactly the way they were written. Too bad they didn't pay better or I would still be doing it!

[boen_robot]

Here's another debugging concept: the test fixture....

A small correction: The term you're actually talking about is "Unit test". "Test fixture" is one part of unit testing (the "setUp" and "tearDown" and similar stuff...).But anyway... you're starting to get a little too advanced now.

I may have neglected to mention that I have written and had published articles in computer programming magazines going all the way back to C Users Journal. As it turned out they published my articles exactly the way they were written.

I don't doubt your ability to write great stuff that people can easily understand if they read it. I doubt the average internet readers' attention span, taking my own (and every fellow student at my university) as a base for this doubt.

[ckrudelux]

<< Topic pinned >> I've pinned it for now, and also, if you don't mind... I've made some "headers" for the sake of easier reading. Maybe we can rework it later, but this is good even like that. BTW, I think exactly like that, and used to think anyone who ever went into programming thinks in the same way, but after seeing Temple Grandin's TED talk, I'm not so sure. The better programmers (pattern thinkers), sure, but probably not all.

Great ted talk!

[boen_robot]

<< Topic unpinned >>I've left a link to it though from a new "tidy" version.

[Guest So Called]

You've stolen 95% of my original article and then you represent me as a contributor? As a mere contributor??? Fine. You can forget about my future support in the forum, you plagiarist. You should be embarrassed to claim authorship of articles created by the real author.

[Guest So Called]

Please cancel my membership in this forum.

[boen_robot]

I've changed that to

Closing note: Based on earlier writings by "So Called" in this topic.

Happy?If not, how would you like me to phrase it?The only reason I initially phrased it as "Some content based" is because a few points are entirely new (HTTP debuggers...), entirely rewritten (View Source...), while some are heavily cut out or simply altered beyond their original intent (var_dump() instead of plain echoes...), or simply contain minor edits not previously stated explicitly (almost all other points), so "some content" seemed like a fair statement, combined with the fact I actually link back to this content.The way this phrase goes is entirely unimportant to me (it's not like I didn't even mentioned this content...), but if it's so important for you, I'll phrase it any way you like. There's no need to act like a prima-donna about it.

[Guest So Called]

What part of cancel my membership account do you not understand? Are you both a plagiarist and stupid too? I spent hours writing my article and you've stolen my content. Go to H E L L and cancel the account. I'm not going to participate any more. I'm done with your forum.

[boen_robot]

For f###'s sake! The intention was never plagirization!!!!! :glare:I'm sorry if it looks that way, and if you stop acting like I've stolen a toy or something, you'll realize I'm trying to make up for this accident (because that's what this IS). I didn't settle out with the intention of "stealing" your content, but with the intention of improving it (by means of adding those things you hate so much - headings), for the benefit of people who wouldn't read through all of your damn content as it is currently. The alternative was modifying your original post - an alternative that you lashed out from the start, yet apperead to agree with a brand new post that's based on your content, with credits in it. OK, maybe "Some content based" was a poor choice of words for crediting you. I apologize for that, and would like to fix it, if you let me.This topic is now pinned, the other is unpinned... as before. Happy now?

[justsomeguy]

This forum is not for posting "articles" and claiming ownership about whatever you post, it's for helping people learn. That's the only goal here. All of us are volunteers, there isn't a single person regularly posting on this forum who gets compensated in any way for what they do. We appreciate contributions from anyone who wants to help but if you're going to be abusive and overbearing then I'll be happy to delete your account myself.

[boen_robot]

I've swapped the topics back now. I see no reason not to, since that credit IS given, even though the forum is not about that.

[justsomeguy]

Yeah, it's pretty rough, he spent all of those hours. I wonder how many hours you and I have spent over our 30,000 combined posts and 6+ years answering questions here. Anyway, if people want to write articles, and claim credit for them, and not allow anyone to improve upon them, the place to do that is your personal blog. This is a collaborative forum, the goal here is to learn. Often that means taking something that someone else did and improving it. Edison didn't invent the light bulb, he improved on work from a lot of other people. That's what innovation is, seeing a good idea and seeing how you can make it a better idea. None of us stand alone, we're here to help each other. If that means improving on work that someone else has done, great. Whatever moves us all forward. In fact, I wish someone would rewrite this with up-to-date code and techniques. If someone wants to do that, I promise I won't call you a plagiarist and insult your intelligence. Anyone could have written that, it's not an industry secret.