H2S47: PHP and HTML multi-threading:

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

<!-- Write your comments here // http://personal-dash/testing-progress/threaded.echo-test.php?post_ID=1 -->

Hu: With the correct URL input, this code works #, to display an edit link, and redirects users to the correct URL, with append: http://personal-dash/testing-progress/dash-edit.php?post_ID=1; both test cases, are requirements.

Hu: Now, a third requirement: to be able to turn on and off the display of this word, with a generalized condition. CM H5S1: One possible implementation is to place the reigns of the entire button, which is currently out of the control of PHP, under the reigns of PHP, and this would allow ease of control, with a conditional. However, simply wrapping this entire statement, and enveloping it in PHP:

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

Hu: Leads to the following error: Parse error: syntax error, unexpected ‘<‘, expecting end of file in C:\wamp64\www\personal-dash\testing-progress\threaded.echo-test.php on line 3. The logical cause of this error is not completely clear. Previously, I had HTML code, in a document that is suffixed .php, and the HTML registered properly, as far as I could tell. Here, the primary change # has been to now include that entire code block, of HTML, which encapsulates a php-encapsulation, into the php-tags, also, but now, this returns a syntax error. This indicates that there is still a delineation between PHP’s reading ability, which is only php-code, and HTML-code, is not recognized, even though nominally, it can be, by Apache<Turing>, even in a php-file. As a matter of fact, it appears that any code that is in a .php file, in a WAMP-install, is by default, read as HTML.

CM H4S1: PHP is a preprocessor:

<Lengstorf, Leggetter pg-26> PHP is a preprocessor, which means that it does its calculations and data manipulation prior to the page being rendered. This means that PHP code is embedded into the markup, and the server reads the PHP | and replaces it with the proper output <multi.thread-defd!> before it delivers the markup to the browser.

H3S1: Using echo to display HTML, but only inside single quotes:

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

Hu: This also works, but for a different reason. When we place some HTML-code inside of single quotes, and as the output-line of an echo command, it will once again, be read as HTML, which means that lines recognized as strings, which is what the single quotes indicate, can still be processed as HTML, establishing a sort of exclusion zone, within PHP. PHP is willing to generalize what is inside # the quotations, and print it, as whatever, and in fact, what is printed, is the Edit button, with hyperlink, and not the string, as-is. This behavior is not necessarily intuitive, from just looking # at the code, a problem in itself #

H3S2: Seeking a merger #: Using echo<potentially> to display HTML, but with a php-encapsulation; multi.level-threading:

Hu: We want to be able to # variable control the display of this icon, and this is the reason we need to reign the HREF under PHP #; however, we don’t want to lose the dynamic | aspect of the URL, which draws from the $post_ID variable. Test:

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

Hu: This code deceptively displays an edit icon, but, insidiously, does not work, completely, because the underlying URL produced leads to the wrong output destination #: http://personal-dash/testing-progress/dash-edit.php?post_ID=$post_ID, whereas we need # /testing-progress/dash-edit.php?post_ID=1

Hu: This indicates that, despite being within the php-tag<illegal!>, the $post_ID variable, which previously worked, such as in edit-mysql-redir<WP.MIC-H2S10>, this variable call #, is being processed as a string, rather than a dynamic #

header("Location: post.post-number.php?post_ID=$post_ID");

Hu: Above, the syntax of an inclusion # of the $post_ID variable call, simply, when there is no php-inclusion that surrounds.

H4S1: The problem crux, defined:

Hu: Granularly, even to know what to search #, we have to define, that we are looking for a proper way to php-encapsulate in HTML, or, encapsulate, in HTML, that is already itself encapsulated, in PHP.

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

Hu: Our earlier suspicions of an underlying incompatibility between HTML and PHP<police!><Turing> is revealed, when we attempt the most intuitive solution, and the URL, now leads to: http://personal-dash/testing-progress/dash-edit.php?post_ID=%3C?php%20echo%20$post_ID;%20?%3E

This means that # our ability to re-activate PHP, inside of an HTML-area, has been blocked, for some reason, and this is associated with # the fact that this particular HTML-area, is inside a php-tag, rather than directly inside the doc-general # Why? God knows, but we need to work around this # This is a clear | violation 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> Being able to circumvent this issue will have significant payoffs, like a 2-3x increase in coding speed, and a general avoidance of troubleshooting, via prophylaxis, and not building on top of this, to avoid high.systembreaks, but continuing to build modularly, so that we can get right back #, when PHP-core fixes this #

H3S3: PHP echo lit-rev:

Hu: Let’s take a look at documentation around the echo function to see if we can find any leads:

H4S1: Echo is a string | function:

<PHP.net>: For even more powerful string handling and manipulating functions take a look at the Perl compatible regular expression functions. For working with multibyte character encodings, take a look at the Multibyte String functions.

Hu: Strings are not meant to have # dynamic | properties, nor encode for anything, other than a string of text, that is displayed, WYSIWYG; in fact, strings can be interpreted as # the fundamental unit of WYSIWYG #<Turing>. This means that even the manifestation of this line:

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

Which displayed the correct answer, albeit via an invalid | hard | code, is a hack, because it’s getting PHP to display a string, as dynamic | HTML. That’s not to say that PHP cannot support this, at some point, but when it does, it will not be with the echo function. Unsurprisingly, we can’t take this hack one step further, nor any steps further, because PHP does not have scalability for hacks<local-Turing, fbno>

Hu: Right now, we can apply a calculation stop<ch.8-9>, and look for a different way to handle this conditional.

H3S4: The HTML hidden attribute:

Hu: The correct way to hide an html | element, that you want to reveal, conditionally, is by using the hidden attribute that can be applied to W3Schools: any HTML element. Browsers should not display elements that have the hidden | attribute specified. The hidden attribute is a boolean attribute.

<p hidden>This paragraph should be hidden.</p>
<p>This is a visible paragraph.</p>

Hu: Only the second line, in the above code, will be displayed, to the end user.

H4S1: Security consideration:

Hu: Note that the hiding of the edit | icon is purely cosmetic, and for the user’s benefit, as the pathway to the edit | page, can be typed manually into the URL, and it’s our PHP.header-redirect<Turing> that is truly | responsible for the security, in this case #

H4S2: JavaScript can remove the hidden attribute:

W3Schools: Then, a JavaScript could remove the hidden attribute, and make the element visible.

H4S3: PHP can also remove the hidden | attribute:

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

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 phptag, even if inside of a php-doc<insight!> Also, note that the <p> tags, in which the hidden | attribute are placed<alignment!> are, incidentally, remote, and, in fact, as remote as possible, from the meat | content, which allows us to control this, non-interferentially #, with the URL-portion.

H4S4: Add the conditional:

<WP.MIC-H2S49><WP.MIC-H2S50> Hu: I decided to Fancy things up a bit here, but creating a dynamic | dependent conditional, that also includes from another doc; you can see the full implementation at H2S50.

if ($output != 1) {
	echo 'hidden';

Hu: All you need to know here #, is that I’ve maintained the syntax of the echo | statement, and enveloped it in a simple | conditional; some additional processing is done to generate the $output<H2S50>; this now, depending on $output, will allow me to turn the link, or any other HTMLelement, on, or off. Fin<s-fbno>

Post: This implementation can non-redundantly be used to control , independently, any number of html attributes, since they are linearly | adjacent, and there would be no overlap, among the php-encapsulations; the control can be via # conditionals.

H3S5: Conditional multi-threading:

Code contributed by Dr. Ben Dunkle, Canisius University:

$output = logged_in_binary(); 
if ($output == 1) {
<a href="../process-redir/log.out-redir">Log-out</a>
<?php }
else { ?>
<a href="../login.php">Log-in</a>
<?php } ?>

Hu: My conditional button display implementation depends upon editing the hidden attribute, so 2 separate HTML-lines needs to be managed, with 2 separate conditionals, and any overlap needs to be eliminated, by logic.condition-management. Each conditional is controlling the hidden attribute, not the HTML code # for the entire button. Therefore, each conditional can be binary only: show, or hide, this button. I cannot have a trinary conditional that will show, or hide, the other button. However, since there is no php-enscap right now, at least to the index.php-redir, I don’t have to # control a hidden attribute, I can control the entire HTML.code-line, with the conditional; this would allow me to # show one line, or the other, completely. I can also potentially remote control 2 instances of the same conditional, with a meta conditional, that branches in a conditional tree Right now, I will start with controlling the 2 buttons separately, to allow the flexibilty # of php-encap in each URL, later, and I will write them manually, without a meta-controller.

The reason that I was concerned about “control the entire HTML.code-line, with the conditional” was because I had some issues with multi-threading before and there was the possibility # that I would have to forsake the ability to add further php-encaps to other attributes, as the URL becomes more sophisticated, with the website.

However, your implementation leaves <a href=”../process-redir/log.out-redir”>Log-out</a> completely outside of PHP, which just amazes me, as I didn’t think it was possible, for the control to work that way, because you had previously closed the php tag. I must not completely understand this multi-threading still, but it is an interesting use case.

Therefore, I will adopt your implementation, and continue my investigation of multi-threading behavior between PHP and HTML. Fin.v-5.

<php.net>: In this example PHP will skip the blocks where the condition is not met, even though they are outside of the PHP open/close tags; PHP skips them according to the condition since the PHP interpreter will jump over blocks contained within a condition that is not met. Hu: It’s important to note that p-1) the PHP-interpreter<WP.MIC-H2S61>, in php-files, is dominant over any HTML-interpretation<Turing>, and that p-22) the interpreter, after skipping, will seek the next conditional | clause, in this case, the appearance of else, in a php-encap, to finish its logicalexpectation<Turing>; it will not c-1) terminate its logicalexpectation of the continuity of the conditional structure, even when it meets ?>, and this is the key | point #

H3S6: PHP x HTML x JavaScript:

Hu: Below is an example of a unique multi-thread: 1) PHP echoes an HTML button, which onclick calls delete_forward() 2) delete_forward() is a JavaScript function 3) The delete_forward() function is subsequently defined, and contains the HTML location.href property # 4) The URL definition, in location.href, contains 2 dynamic php-encaps #<Turing>

echo '<button onclick="delete_forward()">Confirm</button>'; 

function delete_forward() {
	location.href = "mysql.delete-test.php?author=<?php echo $_SESSION['username']; ?>&post=<?php echo $_GET['post_ID']; ?>";

H4S1: JS.processing-logic:

Hu: Anything outside of <?php ?> encapsulating-tags # are echoed to the browser as a general-HTML, and the browser will know to read any HTML, which is itself encapsulated<script></script>, as JS, and all of this, occurs independently, of any code that is php-encapsulated. Support for JS-code is determined by the browsermodel, and version, that the user is running, in the client.side-computer, that loads the script-output #

A sample browser-compatibility chart, predicting whether a JS-property will run.<dev-Mozilla a-r>

Hu: Whereas we control # the phpversion that is installed on our server, we have 0 control over the JS-version that is supported by the user’s localbrowser. This should factor in, significantly, to our programming-selections.

H3S7: Loop.multi-threading:

<php.net>: For outputting large blocks of text, dropping out of PHP parsing | mode is generally more efficient than sending all of the text through echo or print. Hu: Here’s @bendunkle ‘s escape concept, applied to a for loop, with slightly higher complexity, but executes well to generate:

<?php for ($x = 1; $x <= 9; $x++) {
	$url_column = 'url' . $x; 
	$text_column = 'text' . $x;?>
<p>1: <a href="<?php echo select_single_grid($post_author_username, $post_ID, $url_column);?>" data-type="URL" data-id="https://developer.wordpress.org/plugins/" target="_blank">
<?php echo select_single_grid($post_author_username, $post_ID, $text_column);?></a></p>

Hu: The ability to escape from PHP to the HTML bulk, but still have php.encap-includes for dynamic URLs and so forth, is a really powerful feature for generating concise code.

H4S1: While version of H3S7-main #:

$x = 1;
while ($x < 10) { 
$url_column = 'url' . $x; 
$text_column = 'text' . $x++;?>

Hu: With no other changes, this loop | header will produce the exact same outcome as the for version, demonstrating that while is more basic than for<Turing!>








Realtime Web Apps by Lengstorf and Leggetter, via Apress.



Leave a Reply

Your email address will not be published. Required fields are marked *