H2S39: Troubleshooting library:

Hu: Troubleshooting is not QA, although it can be a subset; we do QA when we are confident, on some level, that our features are working, and we challenge testers to find issues that have not yet been unraveled, in the default test cases. On the other hand, troubleshooting, we may perform, in the process of coding, in order to discover a fundamental error in our understanding, or application, of programming languages.

H3S1: PHP error library:

Hu: One way to troubleshoot is to search for the error: in php-docs, or on a forum | site, like Stack-Overflow:

H4S1: Parse error: syntax error, unexpected T_STRING in ‘page URL’:

Hu: This error seems to arise, as a result of the left to right, up to down reading property of the php-compiler; as the compiler is reading, in a particular line, and this error is typically | associated with a single | line, the first line in which such an error occurs #, it will reach a character, or word, that is recognizes as logically | incompatible, by its minimal.IQ–standard, with any of the previous | code; the syntax word, in the error, confirms that the error is categorical, that the next character, or word, is not within an acceptable | category. H5S1: Check php-docs, for the specific | statement that you are trying to write #, and specifically check that word, as well as the syntax around it, framing the word, for any discrepancy. H5S2: Non-specification: Although this error specifies a line, as well as a specific word, it will not specify, if there are multiple occurrences, which occurrence created the issue # H5S3: Reduce redundancy: attempt, if possible, to isolate single | occurrences of the problematic | char #

H4S2: Fatal | error: Uncaught Error: Object of class mysqli_result could not be converted to string:

Hu: This is a much more specific | error that specifically relates to the usage of PHP to make a MySQL query, possibly involving a variable | assignment #

H4S3: Notice: Array to string conversion:

$sql = "SELECT text2 FROM wp_posts WHERE post_ID=1"; 
$result = $conn->query($sql); 
$row = $result->fetch_assoc();

Hu: Even after all of this processing #, the output in $row is still an array, and PHP cannot echo | print an array, directly, without some sort of loop | extraction; W3Schools: If there are more than zero | rows returned, the function | fetch_assoc() puts all the results into an associative | array that we can loop through. The while() loop loops through the result set and outputs the data from the id, firstname and lastname columns. Hu: The above error will be displayed, if we attempt to echo $row; directly, from this point #

H4S4: Notice: Undefined offset: 0

Hu: Crime assessed # for attempting to assign to a variable # the index number of an array variable, like in Python:

$actual_result = $row[0]; 

H4S5: Error: Cannot use object of type mysqli_result as array in

Hu: Attempting to print # index 0 of whatever is in $result, which PHP recognizes as data of the type mysqli_result, is invalid, without first running fetch_assoc()<H4S3>

$sql = "SELECT text2 FROM wp_posts WHERE post_ID=1"; 
$result = $conn->query($sql); 
echo $result[0]; 

H4S6: An if conditional executing commands conditionless-ly #

Hu: An error.message-less error #, this one can be tested, by separating the conditional construction # itself, from the effect H5S1: Condition syntax H6S1 :Is my condition triggering all the time, or do I have an issue with the syntax? Change the condition, to a manual toggle, and test H6S2: Am I lacking an E, due to the condition failing to trigger, or an issue with syntax? Change to an echo statement, and test #

H4S7: Undefined index: post_ID in

Hu: One time, when this error appears, is when we have a $_GET retrieval:

$post_ID = $_GET['post_ID'];

Hu: but our URL does not contain a corresponding variable in the form of, as in this case, explicitly, ?post_ID=[value]. To fix this error, we need to either comment out this retrieval, or add the append, to our URL.

H5S1: header(“Location:

Hu: The header function is for the purpose of loading a header, and only consequently, via a pseodu.built-in,hack, which is officially supported by PHP, does it accept # URL, for the purpose of a redirect. However, bear in mind, that we are in PHP, not HTML, as in an a href link; PHP seems to only accept links, that have the http:// format, for redirects, whereas the include statements, previously, accepted absolute paths # with C:\

// working example:
	header("Location: http://personal-dash/post.post-number.php?post_ID=$post_ID");

Hu: Note that the header redir can also accept relative | paths.<WP.MIC-H2S35,H3S3.H4S6-H5S1,H6S1>

H4S8: This site can’t be reached:

Hu: If you have the correct URL, but are getting this error, check if WAMP-crashed. Alternatively, check if you have a header-redirect that, for whatever reason, may be producing a mistake #

H3S2: Strategic echo placement:

Hu: X.ref<WP.MIC-H2S10>

H4S1: Commenting out echo statements:

Hu: Case study: since I store my db-conn in a separate file #, database.php, and I have an echo statement, there, to confirm if the connection request is successful, this statement, will also be printed, every time I require database.php<illegal>. Therefore, what I can do, when I’m not actively testing database.php, is to comment out the echo statement, to avoid this cross-echo #<Turing>

// Check connection
if ($conn->connect_error) {
	die("Connection failed: " . $conn->connect_error);
	} else {
	// echo "Connection successful!";
	}
?>

H4S2: Valid db-updates as an echo test<Turing>

Hu: Programming with a db # is an added exponent of complexity, but can also help reduce complexity<duality! fbno> by providing an additional testing parameter.

H4S3: Echoing $conn->error;

Hu: There’s no need to add 1) isset 2) if conditional to a simple echo statement to check a $conn->error:

	$conn->query($sql); 
  // echo $sql; 
  // echo $conn->error;

Hu: The first line will print the request itself, which is not necessarily necessary #, as this is simply the value that you auto-assigned # to the $sql-var. More useful is the second line, which is a built in error check by PHP.My-SQL, and you can conditionally | turn this on and off, by yourself, with comments<Turing>; this also prevents the $conn from being run twice, or having to put the $conn inside the conditional, which is simply wrong.

H3S3: Reverse engineering conciseness in troubleshooting:

Hu: In the modern state of programming #, conciseness is a luxury, that, due to the constraints of software | design, and various internal | content incompatibilities, it pays # to be extremely verbose at times, even copy pasting hard-coded, un-scalable solutions, and detach the hooks, only when you’re confident, that the feature is working at the core thread<Turing>; we cannot be frivolous when it comes to, even, being extremely redundant, but this can always be resolved, with an internal | library<Turing>

H4S1: Mental preparation for false-surprises:

Hu: A false-surprise in troubleshooting is when you write a line of code that works, but the fact that it works, indicates a fundamental flaw about the programming system. However, if you attempt to preclude yourself # from false-surprises, which can do, as a chess-player, you may never find the “practical | solution“<sued>, so in programming, we have not reached the level of ethics, that is inherently built-in, to chess. H5S1: A slight variation of this, is expecting to something not work #, as you cringe, but it may be the only way, that it can work<max-red><colloquial!>

H4S2: Modularized build-flow:

H5S1: Hard-code the fundamental | action, especially when this action, affects the db, or some other script; test of your hard-coded implementation can have, regardless of the content, the category | of E that you wish to have<McLuhan> H6S1: You should be able to boil down the fundamental–E to a single line of code, a bottle-neck<Turing> H5S2: Test the E, now, with a variable, rather than a hard-coded value # H5S3: Make the updating of the variable dynamic, by making the variable’s value, determined by, a db-call, or form-entry; H6S1: 2 possible dynamic | inputs # to a variable’s value are db-call, and form-entry. H5S4: Dynamic form/db-input, from a different | file containing the trigger H6S1: After we have the dynamic | flow down within a single file flow, we can then segregate the trigger from the processing by moving the form, for example, to a different file, and use the action attribute, to trigger the processing | file, and re-test.

H4S3: Don’t test anything in your dev-docs:

Hu: Develop an internal | push-process, in which all new features, and the smallest levels of sub-features, are first developed in a testing document, and is bulk-pushed to the dev-doc, in a completely reversible manner, such that the decision to keep, is binary. In other words, you will leave the dev-doc in a working manner, and one click, copy paste<not-that!><rap!><fbno> the code update, from the test–doc, where it was working. H5S1: A staging test-doc: to test compatibility between the new code, and existing code, should be implemented, and keep in mind, even the transition between this, and the dev-doc, needs to be tested. H5S2: Clearly define the working condition, before initiating the testing phase. H5S3: Place all the testing-progress docs into a separate folder, to remember, which docs are dev-ready, and which are still being tested.

H5S1: Create an archive | folder, for docs that have passed a test. H5S2: If the tested doc is an include, then that tested doc, can be directly pushed to dev-live, and perhaps, a backup saved #

H4S4: Increasing testing granularity, 10x, every time you have an error<x.ref: qtum-MIC>

H4S5: For a larger | feature, enact segmented | pushes, as well as multi.segmented–testing, where multiple features are pushed to dev–live, at once, and either tested and approved, or reversed, in bulk.

H3S4: Known flaws, pain points # in PHP-design:

H4S1: Some variable declaration statements, the lines containing, are also responsible for running a command, eg:

	$result = $conn->query($sql);

H4S2: MySQL statements run into naming | errors, if the table-name contains periods, and possibly dashes. Best to stick to simple names, consisting only of alphabet characters, underscores, which seem to be the least controversial notation in general, and numbers<dumb!>

H4S3: Violations of the transitive–property: We need to understand, generally, that a violation of one of the 10 commandments of logic is most likely not isolated; we know that this is a 3rd.order-abstraction issue, and it could be the case, that transitive.property-violations occur, at every 3rd.order-abstraction, in PHP, HTML, both, or only the merger, or that the transitive-property in general, breaks, at every level.of-abstraction here, but insofar as the transitive-property itself includes 3 variables, at minimum, most likely, this is a problem that is limited to 3+ abstraction<MIC><WP.MIC-H2S47>

H4S4: Explicit limitations:

Hu: A limitation is not necessarily # a flaw, but it may be experienced as such, when that limitation is imposed, in order to make possible, a feature that would be otherwise too complex, with the intention of patching that limitation up later. A limitation is explicit when a particular usage is blocked, explicitly, with an explicit | line of code.

H4S5: Implicit limitations:

Hu: An implicit limitation is an unsupported | syntax, and is a limitation, due to the lack of explicit support. Understanding whether a limitation, such as<WP.MIC-H2S47> is the first step to contributing or working around it, and a knowledge of the source code, to some extent, becomes necessary, as one advances, in development.

H4S6: Limitation by complexity ceiling:

Hu: By far the most common type of limitation, is one of complexity ceiling, as evidenced, and can be pointed out, by one whose IQ exceeds the ceiling, by the fact that the problem has many potential solutions, but none exists, in code. Facts and knowledge can be taught, and thousands of universities contribute PHP-devs, but there’s only one 🔑 for resolving a complexity ceiling: MIC.

H4S7: Multi-threading limitation<Turing>: don’t put a php-encapsulation inside of another php-tags:

<p <?php echo 'hidden'?>><a href="dash-edit.php?post_ID=<?php echo $post_ID; ?>">Edit</a></p>

X.ref-<WP,MIC.H2S47-H3S4,H4S3> Hu: A beautiful | solution that is coherent with the designs of PHP, HTML, and even JavaScript, in its exclusion<lol!>, and efficiently applies the php-enclosures only around # the aspects of this HTML-string<high-IQ!><fbno> that are intended to be dynamic, while sidestepping the cross-stringification<low-IQ!><fbno><not.string-theory!> between HTML and PHP. There is no unintended | functionality here, and is scalable, as long as ⭐ we never place this entire block, from <p> to </p>, inside of a php–tag, even if inside of a php-doc<insight!> Hu: The key to this implementation is that HTML is the only thing that surrounds the 2 sets of php-encapsulations; outside, this exists naked.on-the,page, directly, inside the php-file. This is the limit<10/22> to multi.threading-complexity that PHP can handle, at the moment.

H3S5: Testing conventions:

<!-- dev.live-URL http://personal-dash/post.post-number.php?post_ID=1 -->

Hu: Placed at the bottom of my .php, outside of any PHP-tags, as an HTML-comment, I have specified the dev.live-URL, which I use for testing; this is important, because I have tags in the URL<?post_ID=1>, and will add more later, that are required for testing, and this is not obvious, from the file name itself<Turing>

H3S6: Occurrence rate of expected behaviors:

Hu: A high quality troubleshooting and prophylaxis should result in at least a 90%+ rate of expected behaviors, on the part of code, and the dev.test-level; if one is experience a lower rate, then this system needs to be improved, before significant development can continue<Turing!>

H3S7: HTML-library:

Hu: If an included | doc contains # an HTML-comment that is not wrapped up with –>, it may wipe the HTML, on an including | page<security-flaw!>

H3S8: MySQL-library:

H4S1: Apostrophe in UPDATE:

<WP.MIC-H2S30>: This issue plagued p-dash from 11/22-12/22<history>:

SET notes='{$_POST["notes"]}'

edit-mysql-redir.php takes the posted | content from dash-edit.php, which posts, directly from the source | input and inserts that input directly as a string into the MySQL-command. Therefore, when an apostrophe is found in the input, there will be # an early | termination of the quoted | enclosure, and most likely<100%>it is the text, all of it, ensuing the first in.line-apostrophe, that is causing the error.

H5S1: Auxiliary | testing: In the same save post and edit-redir, if “test” is written to a previous line to the one that contains an apostrophe, then that line can be written, while the line that contains an apostrophe, remains blank in db.

H5S2: However, if the order is reversed, such that the line that contains the apostrophe occurs earlier in the UPDATE order, the subsequent line, containing only “test”, also will not be written. H5S.1-2 indicate, in coordination, that the script is executing | sequentially, and is not all.or-nothing<WP.MIC-H2S61>

Solution space: Basically, I need MySQL to not read the in.line-apostrophes as clause | terminators: or MySQL can clause | terminate with a different char, but Occam’s<ch-20>points us to trying the former | first. Hu: CPU-considerations: I would prefer not to have to parse and reparse and rather, use a format that HTML knows to render into an apostrophe in the endpoint; however, it would also have to know to reciprocally write the apostrophe into that form, in the starting | point.

H5S3: Quotation | error:

The insertion of a quotation | mark in a slot creates a different | error, but one without any explicit | error prompt from PHP-MySQL, in orange. Moreover, this error reproduces differently, on dash-edit.php, and post.post-number.php, 2 places where what is written is retrieved with select_single_grid, a function–defined in mysql.query-inc.php:

return $row["$column"]; 

Hu: The error can likely be traced to the last | line in select_single_grid, which returns the variable column, which was defined in the

$sql = "SELECT $column FROM dash_{$post_author_username}_posts WHERE post_ID=$post_ID"; 

On dash-edit.php, the error is severe: the line is clipped after the first | instance of a quotation usage; however, on post.post-number, the entire line is displayed without incidence, which is curious, because they both call the same | function in mysql.query-inc.php:

<td><input type="text" id="text<?php echo $x;?>" name="text<?php echo $x;?>" value="<?php
	echo select_single_grid($_GET['author'], $_GET['post_ID'], $text_column);?>" minlength="1" maxlength="200"></td>

^ Hu: The code to select $text_column in dash-edit.php.

<td><?php echo $entry_count_9; ?>: 

<?php $url = select_single_grid($post_author_username, $post_ID, $url_column);
if (check_private($url) && $check_edit_perm_bool != 1) {
	echo "🔒:";
	} else {
?>
<!-- check_private controller target start -->			
			<a href="<?php echo $url;?>" data-type="URL" <?php if (array_key_exists("url$entry_count_9", $attributes)) { 
			if ($attributes["url$entry_count_9"] == "_blank") {
	echo 'target="_blank"';
	$internal = 'off';
	}
} else {
	$internal = 'on';
	}
 ?> ><?php $display_text = select_single_grid($post_author_username, $post_ID, $text_column);
			echo $display_text?></a><?php if ($display_text != "") {
				if ($internal == 'on') { 
			echo '[i]'; 
			}
		} 
	} ?>
<!-- controller target end -->		
</td>

^ Hu: The code to select $text-column in post.post-number.php is significantly | more | complex because the text is displayed inside <a href rather than alongside the link as a string, on dash-edit.php. Somehow, this logic causes the error to not be reproduced. Note that # any text containing a quotation is written to the db correctly because the initial clause | setter is with an apostrophe, and so, a quotation is not recognized as a terminator, although both apostrophes and quotations can be established as setters in MySQL-statements, generally<righteous>I believe<70%, defd>that apostrophes and quotations are interchangeable as setters, but must match as terminators, in PHP as well<Turing>, and this key principle would allow me to standardize; however, switching from apostrophe to quotation in the UPDATE-statement on edit-redir will likely cause a write | error either way, so most likely, I need a general | escape solution.

H6S1: The quotation | error does not reproduce in the notes input, on both dash-edit.php and post.post-number.php:

H5S4: The general | escape solution can either # escape individually, which increases the chances that parsing and reparsing will be required in the current | paradigm<unrighteous>or a mass | escape, from the beginning of the text to the end, that can serve to HTML the desired | final, since the HTML–interpreter seems a bit more infallible than MySQL<iterations!><Spartz>

H5S5: //

H5S6: Existing solutions lit-rev:

H6S1: WordPress: quotations and apostrophes can be inserted into the db in WordPress, which also uses MySQL-PHP:

<!-- wp:paragraph -->
<p><strong>Hu</strong>: Troubleshooting is not QA, although it can be a subset; we do QA when we are confident, on some level, that our features are working, and we challenge <strong>testers</strong> to <em>find issues</em> that have not yet been unraveled, in the default test cases. On the other hand, troubleshooting, we may perform, in the process of coding, in order to discover a fundamental error in our understanding, or application, of programming languages. </p>
<!-- /wp:paragraph -->

^The data-str of a WP-block.

neighbor\’s

^WordPress uses a \ preceding each ‘, blocking its incorrect interpretation, which means they must have a parsing, and re-parsing function, before, and after, each UPDATE and SELECT, respectively, which is wasteful.

Create 2×2\”

^A same \ is used before each “, without | differentiation.

\n

^WordPress also uses this arbitrarily and inconveniently selected notation for a line break in db, which is later assembled in the incorrect order; in order to de-parse this correctly, we would have to seek and destroy<CoD>the \n first, as a string, before the \, else we’ll be left with a bunch of lone–n.

H7S1: The WP-UPDATE statement:<WP.MIC-H2S30,H3S2.H4S2-H5S1>

H7S2: The WP-SELECT statement:<WP.MIC-H2S30,H3S2.H4S3-H5S1>

H4S2: Closed pointing bracket tags:

Hu: A related, but non-identical | error is the insertion of any enclosed bracket tags, such as<ch-51>, which will disappear from display in HTML, but can be written into MySQL without issues #

References:

https://www.w3schools.com/php/php_mysql_select.asp

https://www.php.net/manual/en/function.header.php