H2S10: Self-teaching coding:

Hu: Coding and programming are distinct: Ox-lang: provide (a computer or other machine) with coded instructions for the automatic | performance of a task. Hu: at Che-WP, we define coding as a subset of programming, and recommend that programmers spend at least 2 years, learning the fundamentals of comp–sci, before they start writing code. A similar requirement is placed on the delineation between learning chess theory and playing games in Material in Chess.

Hu: Whereas coding is the act, granularly, of writing the direct input, to the compiler of a programming language, the general act of programming, relates to the design, of all automatic | tasks, to be performed by a machine, and this includes the creation of WordPress pages, architecting a coding | project, or creating the column headers, in a G-sheet.

H3S1: Massive data intake:

Hu: Learning to program, and each language, is analogous to the learning of verbal languages<ch.16-H2S1>; although there is a universal | grammar<r: Chomsky>, a massive amount of data, has to be absorbed, via osmosis, before the patterns can be extracted. See references for our 25 hour massive-intake playlist, which you can consume, passively. Fin.v-1

H3S2: Basic | logic:

Hu: The basic components, of logic, and all comp.sci-langs, are a) functions b) conditionals c) loops d) sets e) // cont.v-2

H3S3: Integrated development environment<IDE>:

Hu: In ’22, all applicable | coding is done on a computer; in order to write on a computer, one must master Word, but this is separate, from understanding of the English language.

H4S1: Repl.it:

Hu: Replit is a cloud | IDE that allows code to be written and executed within the same | environment, vertically | integrated, instantaneously, and with the potential, for calls, to other web applications. As a result, it is an ideal IDE, for novices, to write simple | scripts that interactively calculate.

H4S2: G.sheet-scripts: <x-ref WP.MIC-H2S4 H3S9>:

Post: Hu: It is highly | recommended that, in the beginning of one’s coding practice, that one writes code, only, from scratch, rather than attempt to alter existing code #, and one do so, in an IDE, without the opportunity to interfere in the function of an existing program. The design of the new program should receive | data in a detached | manner, and output | data cleanly, such as by API, to an endpoint. Many useful | applications can be made in this modular.micro–format<Turing>

H3S4: Write a proof, and then translate:

Hu: All functions are proofs, and there is no programming language that, presently, has the meaning–sophistication of English, at the latter’s best; therefore, coding is the process of translating a program, from its English | iteration, into a programming language, as of ’22. All functions have 3 components:

H4S1: Input:

H4S2: Calculation:

H4S3: Output:

Hu: Functions differ # only in the type of calculation that is performed. The model of H3S4 is generalizable such that one will be able to write programs in all | languages; once the 25-hour playlist is binge-watched, one should have a good grasp, generally, of what is possible, in modern | programming languages.

H3S5: Inter-scripting:

Hu: A significant portion of systems | coding, in which multiple | scripts, each in different documents #, have to inter-operate, is the management, dependency, and organization, of these scripts, into folders. IDEs generally come with a prescribed folder hierarchy, and this is part of the initial | technical debt of onboarding #<turing>

H3S6: Minimalism:

Wikipedia<a-r>: The concept of minimalist | architecture is to strip everything down to its essential quality and achieve simplicity. Hu: Terry Davis published an 80/20 red of all operating systems, since Unix, in just 3-mb<r: TempleOS, a-r>. While TempleOS is unusable, due to having to be run with VM-emulator, on most modern | machines, it is a testament that not | every line of code pertains # equal | weight. Similarly validated in MIC, a single | sentence of which, is worth about a chapter, even in the average | non-fiction book. As someone who has denser–thoughts, one need not compensate by extraneous | elaboration. Fin.v-1

H4S1: Off-load to human-IQ:

Hu: Material in Chess<MIC> will usher in a new era of human.IQ-revolution, and this should be accounted for, your career coding decisions. There are righteous milestones in adequate–IQ required to operate any system, whether from the level of a customer, owner, or admin, and there is no need, to attempt to undercut this milestone.

H4S2: Write only scripts with a high business | value:

Hu: There is absolutely | nothing that needs to be scripted. Before scripts, people completed work, with paper instructions, or even, if you can believe it, in their heads. Even as of ’22, there has not been a task, invented, that cannot also be completed manually, by a computer, running on an automated | script. Therefore #, a script is only worthwhile, if a certain calculation involving a) the $ value of the task, b) the time to perform the task, by a human, and c) the time to perform the task, automated, checks out, by a k.factor-analogy<turing-3>. Fin.v-1

H3S7: Troubleshooting, syntax, and error | rate:

Hu: Programming feels like # using Siri dictation to write a textbook, but one cannot edit the errors, and has to re-record, every time, an error is produced. You have never met a living | human who is less | intelligent than JavaScript, and the act of coding, in JavaScript, is being forced to converse with that human, and only that human, for 6 hours straight. That’s why only the least | intelligent individuals in our society are assigned to work at Google, because they alone can tolerate this burden, and, by virtue of being the least | intelligent, and reminded of it on a daily basis, with various forms of participation trophies, they uniquely find dopamine-joy, from finally, having a chance to feel superior. The fact that these individuals, proportionately, are also overpaid for their suffering, is a separate | topic, of economics.

H4S1: Troubleshooting:

Hu: The creation of modern | programming languages, since JavaScript, is a cry for help from developers that couldn’t learn it, or its ancestors. The cry for help is in the form of: “neither I can learn, nor be taught”, and the modern | language, forces you to speak to the level of their brain, almost irreparably | distorted, and most of what you feel as the difficulty, in interacting with this, is the sheer magnitude of difficulty, in understanding, how their brain can be structured the way that it is, as a marvel of nature. Fin.v-1

H3S8: Case.study-personal,dash:

H4S1: WordPress.plugin-dev: a brief lit-rev:

H4S2: PHP-lang, a brief lit-rev:

H5S1: HTML x PHP lit-rev: W3Schools: The form-data can be sent as URL variables (with method="get") or as HTTP post transaction (with method="post"). The default HTTP method when submitting form data is GET. Hu: All form attributes, such as the action attribute<H4S5 H5S18 H6S6>, are inserted, individually, following the form keyword, in the form header.

H4S3: Architecture-plan: high.level-outline:

Hu: My plan is to build a WordPress-plugin # that permits front–end | users to make post | changes, that are analogous, to what a backend | editor would be able to make. H5S1: Proxy | backend editor account: I will set up a backend | account, named dash–editor, that will have the role of page | editor H5S2: Remote | control: Front–end | users will be able to control dash–editor in order to update their dash–pages, and only theirs H5S3: Front.end-blocker #sec: I will install # a front–end | scraping mechanism to search for a secure | identity token, that can be manipulated with any browser inspect<Turing>, in order to display, and confirm, editing to the page H5S4: File.level–editing: All changes triggered by front.end-users will be, by the plugin’s translation, translated into direct edits to the page-file, in FTP, that are exact, to the changes | Gutenberg would | make, to produce the same visual | outcome: H6S1: Location-scraper: The plugin needs to identify the exact | location, in the page-file, that the change.edit-code will be inserted H6S2: Code.to-be,inserted: This will be hard-coded, based on a non-coding a/b-test of Gutenberg’s-E on page–files, triggered from the post–editor, with any changes, performed by basic | functions: H5S5: Limited | scope: While the front.end–editor will be WYSIWYG, to some extent, it would not be omnipotent, or even Guten-potent #, and will only contain the specific | changes that a user has to make from a template: H6S1: Change dock | order H6S2: Change link text: H6S3: Change link URL: H6S4: Change link open in new tab, or same tab H6S5: Add icons, 90×90 jpg or png only accepted, and either 9 or none, can be saved H5S6: Page–adding: users will be limited to 10 pages on the initial | signup, and can buy 100 pages for $20, going forward. H6S1: Users will add new pages by clicking on an unlinked icon, marked with [i] H6S2: The ancestor page will be automatically | linked in the back | button, and the new page, automatically linked, from the ancestor | icon H6S3: new | pages will come with 3 rows, of 3.wide-columns, already set to paragraph | block, each. H5S7: Auto.refresh-update,propagation: after users have logged their entire suite of changes to 1 post #, using our pseudo-WYSI # front-end, all changes, upon “save”-click, will be propagated, in one instant, to the file, and the front end page, refreshed, automatically, for the user, so that they can confirm, and begin using, their changes.

H4S4: Iteration and testing plan:

Hu: Repl.it supports PHP web server 10/10/22. H5S1: Based on the principle of # iterative | development, one must, separately, architect one’s own feedback loop, and make this as close to real | time as possible, and since the feedback loop is project-specific in its max-optimized<fbno> form, it’s part of the skill, of being a developer. H5S2: Repl.it provides an ideal, real | time, testing | IDE: and it should be used in the early | stages. Quite-possibly, I can use repl.it to design the front–end, including the change-blocker, and use dummy | containers<Turing> for the username–scrape, before swapping these out, with WordPress.specific-functionality, once I migrate, to native.plugin–phase. The more that I can build on repl.it the better, because using it, will produce code faster, and this may shape, to an extent, the app’s architecture also. H5S2: Plugin upload workflow: Hu:<r: Jakson>: to upload a private | plugin to wp-admin, and there’s limit, to how many times you can do this, on your own site, you need to directly | upload a .zip file to wp-admin/plugin-install.php; this file needs to contain, at least, one .php file, named to your liking #, that contains your custom | plugin. H5S3: How WordPress recognizes a plugin: <r: Jakson>: WP-dev<a-r>: the following snippet | block must be inserted to the top of your php document:

<?php
/**
 * Plugin Name: YOUR PLUGIN NAME
 */

H5S4: Hu: The feedback | loop that I will be using for this project # is 10-s, and has the flow: 1) render php file from IDE, Jakson recommends Visual Code Studio, but I will be using repl.it, 2) compression to .zip, on your computer 3) upload to wp-admin/plugin-install.php 4) activate 5) test, and repeat. H5S5: Testing | plan: I will be building a) modularly and b) step-wise, and, therefore, I can test the application, after every single function. I will write a mini.d-o,d<fbno><Turing>, underneath each function, and function comment, in my visual code-line architectural | plan, below, which I will gradually populate with code, but only after the entire plan, built-in with all applicable business | logic, has been written.

H4S5: Visual code-line architectural | plan:

H5S1: Non.coding-header:

// what is the PHP comment structure? See Atkinson.

The non.coding-header contains all elements that are used by WordPress to recognize the plugin as a plugin #, documents the function to the dev, and future | team, and otherwise accesses human | usability, before the E-having | portions are built.

Disclaimer: in the English run, I will not differentiate between programming languages, and will split off into separate.js or .php files after I review documentation.

H5S2: generate the icon overlay for the editing functionality on a personal.dash–post: icons will be pulled # from https://www.flaticon.com/ and set to 30×30-px<80% 10/10/22> H6S1: Edit | icon: transitions the page # to a different URL via actual redirect, in which the full suite of icons are displayed; displayed in the content area top right, orthogonally opposite to “back” icon H6S2: Save | icon: swapped with edit, when edit is clicked; clicking save has 2 functions: a) transitions the page to without an ?=edit post-tag, and b) causes the code updates generated by front.end-user,actions, on the edit page, to be inserted into the page file H6S3: Cancel | icon: an X, displayed just beneath Save, that does a) of save, but without any code edits propagated. Post: additional icons will be described in-line:

H5S3: text.box-generation: H6S1: On the edit | page, the link | text will be contained within a text | field, which can, and clearly can #, be edited, by the user. H6S2: The hyperlink | URL # will also be revealed, in a second text | field, beneath each link | text instance. H6S3: The list will be transitioned into a vertical | list, which is custom | generated, from the post file, by the plugin, without Gutenberg, using HTML-basics. H6S4: This list will be ordered, from 1-9, with a number displayed. H6S5: In the transition to a vertical | list, only the content area of the page will be custom | generated, but any HTML relating to the header, and the footer, will be preserved.

H5S4: Re-ordering | functionality: The #, associated with list | order, may be changed, and this change will cause an associated | reordering, using a 1-to-1 correspondence<ch-2>, in the backend | file. H6S1: Only numbers permitted; this field will only permit the entry of numbers H6S2: Only 1 digit permitted; this field will block the entry of additional digits, after 1 H6S3: No duplication; this field will block duplication, either upon save, or entry.

H5S5: Page | generation: When a text field contains text #, but no hyperlink, users will see #, on the edit screen, a + icon, next to that text; clicking this icon # will take users to a new | page, containing a form, in which the URL of the page from which they clicked + is prefilled, and users will be prompted # to enter a name for that page; a value of [i] will be automatically | added, to indicate that this page is internal. H6S1: When the user clicks “add”, on this form, a new | page will be created, in the wp-backend, containing a <Back button, which is hyperlinked to the previous | page, H6S2: 3 rows of 3 columns, set to paragraph | block, in Gutenberg | blocks H6S3: the previous | page, will also be updated, to hyperlink this new page, as an internal<H5S6>

H5S6: All user–entered links open externally: all links to pages that do not contain the wordpress.materialinchess.com domain will open in the same tab, by setting, while all links that open to a different domain, will open in a different | tab. H6S1: This setting must be applied, each time the user clicks save, to a field, after that field is checked, with a conditional function, that automatically overwrites whatever the setting was before, to avoid conflict.

H5S7: Page | list: Users will be able to access # from the header, a page, that displays a database, that contains a list of pages, that are assigned to their username; these pages will be hyperlinked, internally, from that page. H6S1: V-2: Users will be able to see a dependency | tree, dynamically generated, among the pages, on the page | list.

H5S8: Account | creation secret | key trigger: H6S1: Page-editing permission, the ability to # click a, edit icon, save, or even access a page, will be governed by the secret | key<H6S2: encrypted> assigned to the user, by their username; users will only be able to edit pages, that contain their user | key, and this key, will be assigned, permanus, upon any page | creation; moreover, the account creation mechanism shall | trigger the creation of the home | page, for that user, and this page, also, will have the key, automatically assigned.

H5S9: Login | redirect established: part of a series, of AAM-writes: H6S1: Upon account | creation, a URI redirect will be established #, from the home.page-link wordpress.materialinchess.com to the user’s unique home, which was generated, in H5S8, and this will be written, into the AAM-file, which stores URI-redirects.

H5S10: Access | restriction role assignment: Upon account | creation, users # will automatically be assigned to a role # that inherits capabilities and access from a user–restricted role, which means that # I will be running this app on a domain that has role | hierarchy, once I have enough users, to justify this cost<fbno><maybe-o>.

H5S11: Access | restriction, page-creation: Upon the creation of a new page #, access to this page will be restricted a) for visitors, and b) for the user–restricted role; however, this permission will be overwritten, for this user, only, the user who is assigned, the secret | key.

H5S12: Write to | page: When the user clicks save, H6S1: the existing | data structure #:

1. [text] | hyperlink <out/in>
2. [text] | hyperlink <out/in>
3. [text] | hyperlink <out/in>
4. [text] | hyperlink <out/in>
5. [text] | hyperlink <out/in>
6. [text] | hyperlink <out/in>
7. [text] | hyperlink <out/in>
8. [text] | hyperlink <out/in>
9. [text] | hyperlink <out/in>

H6S2: This structure needs to be mapped # to columns in Gutenberg, but these columns don’t have a 1-9 order, especially since # I’m using 3 distinct column | blocks, which means that my own IQ, in the plugin #, needs to intelligently re-insert these blocks, into the right column | slot. In a paragraph | block, which I’ve already created with <H5S5, H5S13>, there will be some container, within which, the text, and any HTML-markups, that will live in that paragraph | block, to be entered. H6S3: The HTML for a hyperlinked | text is W3Schools<a-r>:

H5S13: Writing of the page | creation function: H6S1: I’m not creating a template, I’m creating a page, nor can I use a template, besides the default, since the personal–dash lives in the content area, and the template, does not touch, the content area. H6S2: Generating a column: I can copy the code # for a page # that has exactly the setup I described<H5S5>, and paste this, in its entirety, to substitute the content area; I need to # write a function, that searches for the start of a tag, that precedes all of the content area, and a tag, that terminates, and paste, within this tag. The search function is a query that will loop through the text, until it finds the word // research, the first function to reach this granularity #

H5S14: Use HTML to lay out 1) the custom block and 2) the front end edit screen. Test this in Repl.it. Test hyperlinks.

• Write PHP or JS function that converts a link to _blank target, only if it’s external to current domain, which can be spelled out.
• Add a user input box.
• Add an edit button that transitions the page from one layout to another.
• Write to local files in the repl.it based on user actions, find the snippets, and name the files, for each feature, in the WP-files.
  • Find the folder hierarchy search function; some files will not have been created yet, but the time that I publish the plug-in, so they will have variable locations.
• I’m not going to be testing the function of AAM plug-in, for example.
• See how much I can copy paste from existing WP-posts, view source, and get going in repl.it

H6S1: HTML link template: <p><a href=”https://developer.wordpress.org/plugins/” data-type=”URL” data-id=”https://developer.wordpress.org/plugins/” target=”_blank”>dev-WP</a></p> H7S1: Tested in repl.it, in index.html; “dev-WP” is displayed on the front end, after clicking Run, and link goes to the correct URL, and opens in a new | tab. H6S2: Remove target=”_blank”, for a link that opens in the same tab. H7S1: Unable to test in repl.it, due to refusal to connect, on their end # H6S3: Row of 9 links:

<p>1: <a href="https://developer.wordpress.org/plugins/" data-type="URL" data-id="https://developer.wordpress.org/plugins/" target="_blank">dev-WP</a></p>
<p>2: <a href="https://developer.wordpress.org/plugins/" data-type="URL" data-id="https://developer.wordpress.org/plugins/" target="_blank">dev-WP</a></p>   
<p>3: <a href="https://developer.wordpress.org/plugins/" data-type="URL" data-id="https://developer.wordpress.org/plugins/" >dev-WP</a>[i]</p>
<p>4: <a href="https://developer.wordpress.org/plugins/" data-type="URL" data-id="https://developer.wordpress.org/plugins/" >dev-WP</a>[i]</p>
<p>5: <a href="https://developer.wordpress.org/plugins/" data-type="URL" data-id="https://developer.wordpress.org/plugins/" >dev-WP</a>[i]</p>
<p>6: <a href="https://developer.wordpress.org/plugins/" data-type="URL" data-id="https://developer.wordpress.org/plugins/" >dev-WP</a>[i]</p>
<p>7: <a href="https://developer.wordpress.org/plugins/" data-type="URL" data-id="https://developer.wordpress.org/plugins/" >dev-WP</a>[i]</p>
<p>8: <a href="https://developer.wordpress.org/plugins/" data-type="URL" data-id="https://developer.wordpress.org/plugins/" >dev-WP</a>[i]</p>
<p>9: <a href="https://developer.wordpress.org/plugins/" data-type="URL" data-id="https://developer.wordpress.org/plugins/" >dev-WP</a>[i]</p>

H5S18: HTML form code: H6S1<r: W3Schools, a-r>:

<form action="dash-edit.php">
  <label for="1-text">1. Text:</label><br>
  <input type="text" id="1-text" name="1-text" value="WP-MIC"><br>
  <label for="1-url">1. URL:</label><br>
  <input type="text" id="1-URL" name="1-URL" value="https://www.wordpress.materialinchess.com/"><br><br>
  <label for="2-text">2. Text:</label><br>
  <input type="text" id="2-text" name="2-text" value="WP-MIC"><br>
  <label for="2-url">2. URL:</label><br>
  <input type="text" id="2-URL" name="2-URL" value="https://www.wordpress.materialinchess.com/"><br><br>
  <input type="submit" value="Save">
</form> 

W3Schools<a-r>: An HTML form is used to collect user input. The user input is most often sent to a server for processing. Hu: According to W3Schools, the input from a form, in HTML, is typically sent to the server, and in our stack, PHP is the server–side | programming language # W3Schools: H6S2: The HTML <form> | element is used to create an HTML form for user input: An <input> | element can be displayed in many ways, depending on the type | attribute.

Type	Description
<input type="text">	Displays a single-line text input field
<input type="radio">	Displays a radio button (for selecting one of many choices)
<input type="checkbox">	Displays a checkbox (for selecting zero or more of many choices)
<input type="submit">	Displays a submit button (for submitting the form)
<input type="button">	Displays a clickable button

Hu: For our | build, the only input | types # we will be using, are 1) “text”, and 2) either a) “submit” or b) “button”, for saving, and cancelling, the inputs.

H6S4: Hu: The unit form block consists of a label line and an input type line #; W3Schools, in their default function #, adds a <br> command, to separate these in HTML, into 2 separate lines. The id attribute defines the unit as a name, allowing this form, to be referenced, and provided, with its name, to the server. W3Schools: The for | attribute of the <label> | tag should be equal to the id attribute of the <input> element to bind them together. H6S5: HTML side of the 2 way handshake: Hu: the user’s action to submit # the HTML form will trigger a request, to be sent, from the user’s browser, to the server, causing the data, in the form, to be delivered, and processed, by the server. In order for this 2.way-interaction to be possible the HTML form has to # give a hat tip to a specific .php file, containing the function that processes the data in the form, which contains a reciprocal hat tip, and the id attribute of the form, to accept the data. Therefore, fields that are all sent, simultaneously, by one submit action, should be grouped within the same <form></form> envelopment # H6S6: W3Schools: The <input type="submit"> defines a button for submitting the form data to a form-handler. The form-handler is typically a file on the server with a script for processing input data. The form-handler is specified in the form’s action attribute [D.1-below]. H6S7: W3Schools: Notice that each input field must have a name attribute [D.3-below] to be submitted. If the name attribute is omitted, the value of the input field will not be sent at all.

<form action="/dash-edit.php">

name="1-url"

Hu: In the example above #, the name and id attributes of each input # were named the same, but this does not need to be the case,<sick.life-hack>: whereas the id attribute is used internally to HTML, such as to connect to the label, the name attribute is used, when the input is referred, external to HTML # H6S8: W3Schools: When autocomplete is on, the browser automatically complete values based on values that the user has entered before [D] // test this later

autocomplete="on"

H6S9: W3Schools: enctype: Specifies how the form-data should be encoded when submitting it to the server (only for method=”post“)

H5S18: Extracting the existing | value, to be displayed in the field for all fields, in =edit.html, from post.post-number.html: When users click to edit, they are expecting # the fields, in =edit.html, to be pre-filled, with any text, and links, that already exist, in the list, in post.post-number.html. Both pages # have a numbering | system from 1-9, and so, the text of 1), from post.post-number.html, should be mapped to the value=”” attribute, for the 1-text input, in the form, of =edit.html.

H5S19: Custom block creation: It will be easier # for me to create a custom block, composed of columns and paragraphs, modular, and updatable, even with WordPress updates, but this will make a single block, and simplifies the creation page flow, and I won’t run into clunky issues with icons, which would allow users to add one at a time, and inserting and reordering won’t interfere with WP-syntax, rendering the front end appearance on ?=edit will also be easier. Name=Dashboard. Make it a block with front end insertion by admin, and can be edited, v2-build settings for admin to edit. This also minimizes the chance that admin edits will break the feature # fundamentally correct. 50% of the new block will be code from WP-columns, and WP-paragraphs. <r: LearnWebCode, a-r>

H5S20: Database_interaction: A difficulty # in my implementation is that the post_file is stored in MySQL | format, in the WP-db, and it’s not clear #, whether this is an HTML-file. I do not want to # make significant changes to the architecture | of this database, as this is # outside the scope, anyway, of a plugin<architecture><Turing>. Therefore, the ?=edit version, of each | post, needs to be spun up on.the-spot, and stored, somewhere, and somehow, temporarily, as its life will last, until the user clicks save, or cancel, either in our side, or in their browser. H6S1: Brief lit-rev of browser | editing implementations: Hu: The edit | page, of my implementation, is a sort of template #, and can be implemented as such # <I.am-lit,rev, fbno>, as a file, in wp-files, which is where the plugin will go # H6S2: Concerns about incompatibility with WP-db existing | architecture: when I do ultimately # write into the WP-db, the format, of what is written, cannot break that architecture; therefore, I need to, elsewhere, define a custom | block type<H5S19>, refer to it with the

<!-- wp:paragraph -->

tag, and read the documentation, on creating custom | blocks, to make sure the data structures generated are standard.

H5S21: The WP.rendering-function: It’s clear from <WP.MIC-H2S30> that # post-content, for an entry, in wp_posts, in the WP-db, does it 100% match what one would see, if one clicked view.page-source, on that page, from the browser, and it’s the latter, that your browser is using, to render what you see, on the page. That means that there is a predecessor | render<Turing>, that takes the data-structure from post-content, and generates the HTML-file in view.page-source # This render is done live, when users request a page, because the full version, that is seen, from view.page-source, does not exist anywhere, except within the user’s browser, when the page is called. The render must involve some files in WP-files, and likely, is a combination, of the actions of HTML and PHP. The actions must be #, based on our knowledge of Site Editor, <WP.MIC-H2S2,H3S5.H4S4>, involving the page template assigned to the post, and this is likely the primary handler, of the predecessor | render; this page template file is in HTML.

H5S22: Custom.rendering-function, for ?=edit: when the ?=edit page is loaded #, I will follow an analogous | workflow; however, instead of # rendering the page with one of WP.template-HTML, I will use my post.post-number=edit.html file, inside the plugin folder, to render the view.page-source view, and this will require the edit | icon to load my file, from the plugin folder, to trigger my | template. This template, will, like the WP–template that renders post.post-number.html, or, =syn view.page-source, extract | data, from the WP-db. This means that in repl, my post.post-number=edit.html file needs to interact with a db-file, rather than a hard–written HTML-file. H6S1: Lit-rev, how WP-templates are structured, and how they render:

H5S23: Architectural-design:

H5S24: WP-sever:

WordPress sever: Look at where I can find some PHP frameworks: account, template, render, forms, etc. MySQL. Just do it and sell it back whenever "they're ready" like ditching Stl, writing the book, and selling it for $80 rt 3-m of equity for pennies. Still going to be on Dreamhost, subdomain, just without a WP-install. Check their docs for a db/server install. Drop kpop for now, and launch dash.material in chess.com. Swap social off WP also, and I can use the same account database. The thoughts cannot occur to me, unless I forsake the heathen. 

Cont: when the user clicks edit on the former HTML page, a request will be generated to the MySQL-db, to the same path as that former page, but by the universal dash-edit template. That template will be written in php/html, and stored in the files, not the db. I need to move the content to a MySQL database, in repl.it. Separately from this, I need to generate a display template, that serves the page, when it's not in edit mode. There will only be these 2 templates, and the hierarchy is established by the user's edits, making this the first recursive application, on the level of UX. 

Can I make this a local app, or do I need WP to run PHP? Lol. Lateral pivot if it's a web or local app tbh. 

I can keep using the WP user database. If I can generalize it to not care about the display template, then I can write the edit template however I want, and let the WP.default-workflow continue serving that page whenever. The edit button can even be a regular text, and there may be enough tutorials to cover this. The interactions are between the edit template, my server, and the database, totally modularized, from usage, which can be completed with normal WordPress. I never lose time; other people lose equity. 

Lit-rev: I need to find a plug-in that generates its own page(s), and a tutorial, such as Woo(?!), or maybe, not by Automattic 😬. Even the plugins that edit the page are serving a different template part. Next question: where does AAM plug-in store the restriction data? It must be in association with each post, in which case, it would be in the database, but does it have its own table? See if Vasyl has dev-docs. 

I don't need to create my own MySQL .db for WP, but would like to, for practice, on repl.it; find something that can open .db on desktop. I'm gonna have to really step up the copy-paste, lmao. The way I copy pasted the href stuff was great, minor edits. 

H5S25: Fork ideas: I need to find the simplest, and yet, still well-written plugin, that H6S1: generates a new page, from an existing | entry in the database, and H6S2: writes to the database, to edit the content, of a wp_post entry. H6S1: Maybe this, but has 100x code I need; would have to isolate, by reading, the specific functions, and extract only those, but still, maintaining the core thread: https://wordpress.org/plugins/wp-user-frontend/ H6S2: The aforementioned plugin # has edit of an existing page, functionality. H6S3: I need to be able to read this plugin, and find 25/5,000 lines of code, to insert, and increase my PHP literacy, while H6S4: subverting by lack of literacy #, here, by using logical deduction, to narrow my search to pinpoint #

H5S26: Reading front end:

Reading Front End: perhaps I can work backwards, from the one line that writes the database, after the user clicks save, on a post edit. I need the entire preceding flow, from when the user clicked to edit, and from these 2 endpoints, I have at least 90% of that half of the plug-in, without any access management yet. Key question though: does it generate its own edit page, without a WP.theme-template? Test it out on the front end. 

I'm also looking for the code in PHP that receives input from the HTML form, see if W3 schools explicitly states the syntax for that. In 1000 lines of code, if each MySQL request occupies 15, and 70% are such requests, there are ~47 requests, and I'm looking for about 2.

For page creation:
- Write the author
- Write the date
- Write the link back, which could be in the content area
- Edit the back link page, to link the new page
- Possibly different database: manage the user restrictions. 
^ Front End plug-in also allows users to create pages. 

2 main workflows to copy pasta: editing, and page creation. 

Architectural decision: I'm going to build a 100% working plug-in, with no page creation functionality, that only allows you to edit an existing personal-dash page. 

My goal at the end of the day 10-12-22 is to find the 2 functions, and get something into the PHP document. Then, I want to set up a db file in repl.it, with that data structure, so I can begin mock working on a simulation. The core functionality that I want to test and have working, is the entire flow from the users submission of an HTML form to the insertion of the data from that form into a my MySQL database. Next, I want to build the delivery of that data from the MySQL database to a different HTML page, which serves as the display template. This would be in the form of a read query, rather than an edit query. It may be useful to write this basic task using W3 schools as a template rather than the code from front end Plug-in. Key question: how do I get a MySQL database file into repl.it? And if I can't, I'm moving to Visual Code Editor. When I downloaded the database, it was unzipped in .db file. A .db file is just columns and rows like an Excel spreadsheet or a CSV. Look at what WordPress plug-in developers use, because they are also working with HTML, PHP, and.db; I'm pretty sure you can just upload a .db file into repl and leave it in the folder. You would just need to know the file name, and refer to it in some PHP file path; I can narrow down my search in Front End plug-in by only looking for blocks of MySQL requests that contains the specific file path that I can ascertain to the column that I want to have edited which is wp_posts. Later, when I push from the repl demo into a staging plug-in #, I can simply update the file path to wherever the folder and database is in WordPress. 

Can I use phpMyAdmin to generate a 1 column database, with 5 entries, save it, and upload it to repl to test? The ability to edit the database during the testing process would also be optimal. 

H5S27: Look into Cloudflare:

Look into Cloudflare. Does WAMP have PHP my admin? Next step: repl to WAMP migration. Web does not have JavaScript. DevKinsta? Research WordPress and JavaScript. Next steps 1) PHP inputs to MySQL, and 2) HTML forms x PHP. I can totally run an online course with this as the project.

At this point, I'm leaning towards a full swap of the contact area. Does the update statement already do this?Remember that validation is only handled on the form side.  At this point, I have 80% of the syntax of writing the MySQL query down, between specifying the exact address, and understanding the syntax of the update statement, and having a WP-specific template to work from. 

Next: getting the data from the HTML – form to PHP: W3schools has a specific tutorial for this. 

I need to figure out how to specify the wp_comment column on a specific post. 

I'm getting dumped the data in the entire form, containing 1 through 9, text and URLs. When data arrives in the PHP aircraft, it may not be in the correct order. The data has to be input into the database in the correct order, so that the user will see the icons in the correct order, as this is a key user expectation. #ux-research. I can freeze the numbering on the HTML front end, to force users to put the icons in the correct order, such that there is no need for re-ordering in any part of my program. In version 1: I'm going to launch without re-ranking. 

Render a db from a DevKinsta instance and copy this into www-wamp # as the db file. Repeat this, with a db from my actual site, and manually attempt to edit it # with the correct dash-change, then re-upload the database<risky>, in a staging server, and load the page, manually, and see if the change was propagated, to the front. Then, package what changed it, in a plug-in folder. 

Check phpMyAdmin db-creation functionality, rather than using any WP-db, for iterating # 15-min in TechStudio82. After the database is created, additional changes to increase its functionality can be made just through PHP edit commands. 

The first $servername = line, in php, goes right under <?php. PHP pages can be directly displayed, which means HTML is not a necessary-req for any display, it's a markup, of display. 

4 hour vid: JS is what is used # to create Gutenberg block types. I'll probably do this within DevKinsta #s-r 

H5S28: Generating a test | database w/ phpMyAdmin:

H5S29: Establishing a db-conn, our first PHP code: <x-ref WP.MIC-H2S30>

<?php
$servername = "localhost";
$username = "root";
$password = "";
$dbname = "dash-test";

// Create connection
$conn = new mysqli($servername, $username, $password, $dbname);

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

?>

H5S30: PHP handling of html-form, our second PHP code: <x-ref WP.MIC-H2S31> Per the advice of several WP-devs, I have also adopted Notepad++ at this point, in my dev<a-r> H5S1: Add method=”post”: Hu: First, we will update the HTML file in H5S18 with method=”post”:

<form action="dash-edit.php" method="post">

H5S31: Establish segmented micro-tests:

Hu: In order to better trouble-shoot code, I need to progress, understanding what the code does at each segment # and running tests, running # to know which component, exactly, needs repair #

H5S32: Splitting post_content into 18 different columns #:

X.ref<WP.MIC-H2S30,H3S5> Hu: Posed with the option to write a | scraper | function, to differentially # read and write data, into a conglomerate | post_content db, or simply # split the db into multiple | columns, one for each discrete | form entry, I opted for the latter # Therefore, I will be writing each variable, as defined in the isset() | function, of dash-edit.php, into its own column #

	$text1 = $_POST['text1'];
	$url1 = $_POST['url1'];
	$text2 = $_POST['text2'];
	$url2 = $_POST['url2'];

$text1 will be updated to column-text1, $url1 into column-url1, etc.<Turing> Let it be established | thus, that since this decision, which was made with column | creation | mouseclicks in phpMyAdmin, is also a form of programming, since it meaningfully | substituted # the function of code, in a php-file.<X.ref-WP,MIC.H2S37>

H5S33: Select statement for text1, first attempt:

<?php $sql = SELECT text1 FROM wp_posts WHERE post_ID = 1?>

Hu: This select | statement will be used to load # data from each of our 18 hypertext | columns into their proper | display on a user’s personal | dash | page. However, it’s not clear 1) Whether we need to re-establish require database.php for every php-enclosure #, and whether this select | statement alone, without an echo, or so forth, will display the text and link, on the html-page.

H5S34: Update statement for text1, first attempt:

$sql = "UPDATE wp_posts SET text1= $text1 WHERE post_ID=1";

Hu: The update statement exists on dash-edit.php, which takes the form submission from =edit.php and processes it to push.to-db, while the select | statement exists on non=edit.php #, and draws the input from the last update. These constitutes the core dash-loop #

H5S35: Passing the post_ID:

Hu: Each | dash-page will be assigned a unique post_ID, which will be the composite # of the user_ID of creation #, the layer, and the count, within that layer # H6S1: We will write a high-IQ post_ID generation algo, in the page–creation | workflow. H6S2: The post_ID will be stored in the display_version of each page, in the php-file, as a hidden | variable<Turing><#natty-sec> and this will be written, during the page-creation | process. H6S3: That post_ID<Turing> will be used in select statements, in that same file, to draw from the correct table-row, and also passed #, via call, to the edit.php, and passed to the post_ID row-call, of that script-file #, also.

H5S36: SELECT statement, 2nd attempt:

<?php require 'database.php'; ?>

<p><a href="index.html">Back</a></p>
<p><a href="post.post-number=edit.php">Edit</a></p>
<p>1: <a href="<?php 
	$sql = "SELECT url1 FROM wp_posts WHERE post_ID = 1"; 
	$result = $conn->query($sql); 
	$row = $result->fetch_assoc();
	echo $row["url1"]; 
?>" data-type="URL" data-id="https://developer.wordpress.org/plugins/" target="_blank"><?php 
	$sql = "SELECT text1 FROM wp_posts WHERE post_ID = 1"; 
	$result = $conn->query($sql); 
	$row = $result->fetch_assoc();
	echo $row["text1"]; 
?></a></p>
<p>2: <a href="<?php 
// the require statement propgates <WP.MIC-H2S35>
	$sql = "SELECT url2 FROM wp_posts WHERE post_ID = 1"; 
	$result = $conn->query($sql); 
	$row = $result->fetch_assoc();
	echo $row["url2"]; 
?>" data-type="URL" data-id="https://developer.wordpress.org/plugins/" target="_blank"><?php 
	$sql = "SELECT text2 FROM wp_posts WHERE post_ID=1"; 
	$result = $conn->query($sql); 
	$row = $result->fetch_assoc();
	echo $row["text2"]; 
?></a></p>   

Hu: Tested and working, in this manual–write | version, to display both the correct text | display, and URL-hyperlink, also with the correct target attribute as of 10/16/22.

X.ref-WP,MIC.H2S38-H3S6,H4S1

H5S37: Update statement for text1, 2nd attempt:

<?php
require_once 'database.php';
$text1 = 'Nose';
// This statement declares a variable, to prep the db-call, but does not, in itself, run a db-call. 
$sql = "UPDATE wp_posts SET text1='$text1' WHERE post_ID=1";
// This statement is needed, referring to 'database.php', every time code is to be run, to the db # 
$conn->query($sql);
?>

Hu: Notes: I fixed an issue # with the variable | reference in line-5, by placing $text1 inside single quotations #, and remembered to include # the ; following the variable | declaration in line 3. Finally, I added $conn->query($sql), which actually runs the req, calling upon the $conn variable, in database.php. This code, as-is, worked, in updating text1 in row-1 to Nose, and now, needs form–input. I will attempt to accelerate | development by adhereing to the modularized.build-flow: that I designed in<WP.MIC-H2S39,H3S3.H4S4>

H5S38: HTML form w/ post to php + dynamic pre.fill-load from db:<Turing>:

<!DOCTYPE html>
<html>
<body>
<?php require 'database.php'; ?>
<!-- // Form submission issue: when an apostraphe is included, text does not enter into db, and there's no feedback for user #
Try WP.MIC-H2S35 H3S3 H4S6 later # -->
<form action="edit-mysql-redir.php" method="post">
  <label for="text1">1. Text:</label><br>
  <input type="text" id="text1" name="text1" value="<?php
  // the updated text is not displayed, immediately after clicking save; the page has to be refreshed
  // however, I can circumvent this, by re-directing users back to the display page, following refresh # 
	$sql = "SELECT text1 FROM wp_posts WHERE post_ID = 1"; 
	$result = $conn->query($sql); 
	$row = $result->fetch_assoc();
	echo $row["text1"]; 
  ?>" minlength="1" maxlength="18"><br>
  <input type="submit" name="submit" value="Save">
</form> 
</body>
</html>

Hu: This code generates a simple form, with a single input field, label, and a submit button, that reads “Save“. The text | box of the form also pre-fills # with the text, from the db, recycling my SELECT code from H5S36, that already exists # in that table. H6S1: To minimize page.creation–load, dash-edit.php should be a general page, that every post.post–number redirs-to.

H5S39: mysql-edit-redir.php:

<?php
require 'database.php'; 
// Most users have an isset function to fill the $_POST variables; I'm declaring it off the bat, which means it's always
// declared <see-below>
$text1 = $_POST["text1"];
$url1 = 'https://www.w3schools.com/php/php_mysql_update.asp';
$text2 = 'Bridge';
$url2 = 'https://www.w3schools.com/php/php_if_else.asp';

// This statement declares a variable, to prep the db-call, but does not, in itself, run a db-call. 
$sql = "UPDATE wp_posts SET text1='$text1' WHERE post_ID=1";
// This statement is needed, referring to 'database.php', every time code is to be run, to the db # 
	$conn->query($sql);
$sql = "UPDATE wp_posts SET url1='$url1' WHERE post_ID=1";
	$conn->query($sql);
$sql = "UPDATE wp_posts SET text2='$text2' WHERE post_ID=1";
	$conn->query($sql);
$sql = "UPDATE wp_posts SET url2='$url2' WHERE post_ID=1";
	$conn->query($sql);

header("Location: post.post-number.php"); 

?>

Hu: If you noticed, I changed the action attribute from dash-edit.php to send data to this page; by default, the form also redirs # to the page specified by the action attribute, indicating that HTML does not want you to # establish a redir via a workaround, and, moreover, it believes that # the form processing, including MySQL-UPDATE, should occur, on that separate file. Now, on this file, I have an instant | redirect<Herbison,a-r> in the header | function, which means this file is invisible; it loads, in a flash | second, simply to run the MySQL-deposits, and also, at the same time, serves as a transition, thought space and otherwise #, back to the display | page<Turing> H6S1: In general, I think it makes sense, for a background page that runs a cornerstone | function, to be physically loaded, even symbolically<thought-space>, and guided as an intermediate through this instant | redirect | method.

H5S40: Horizontal scaling first:

Hu: Before I go ahead and fill out the rest of these docs # with the additional form fields, I’m going to build the rest of the features out first # at their most basic; once I have the entire horizontal chain, confidently, ringed together, then I can vertically fill out each page<visualization><architecture><Turing>

H5S41: Page.creation-func:

Hu: It may be easier, since I plan on creating a smart.post-ID<fbno><Turing>, to also run my own access management; I also plan on running my own db, also # H6S1: 5 broad strokes: each page.creation-action will a) generate a new page–ID, using my smart | function<fbno> b) INSERT a new row into the db, c) register the back | link in that db, from the clicked | page, d) register a forward | link, in the previous | page, along with text e) redirect # users to that new page.

H6S2: Some UX considerations: The normal | form allows users to add, change, and delete multiple rows, and cross entries, at the same time, whereas the page.creation-func should be limited to 1 new page, per action # Therefore, we have to take special consideration, in recycling the Save | button from the edit | form. H6S3: We can also # place the create | icon on the display | page, to make its action more immediate, and draw a distinction, between editing, and page creation, which is a completely different workflow. UX-wise, the 2 are similar, with a slight edge, until more nuance is added, to separating creation, from the dash-edit.php entirely; backend | wise, it will also save us some trouble, if we can minimize further touches # to dash-edit.php # In the current state of PHP, <20, flexing up to 100, of code, per file, is most | tenable<uh-oh!>

H6S3: The back | link is also editable; if this is the case, and if page_creation opens in a new | tab, then we can simply # manually request users place a back link, and this will also a) teach them how personal–dash works, and b) allow pages to be re-mapped, although I think instances of this are rare. In the long-run, having the ability # to edit the back | link is fundamentally | correct, and people will perform large-scale refactoring, righteously, as they work out their brains, especially at the higher, less-determined l.o-a’s<ch-8> H7S1: The editability of back | links also removes our need # to automate this, which cuts down on our code | load.

H6S4: Delineating smart_ID from dynamic_ID; each | page needs to know # which db-row to load from; this was not a requirement in our single page, single row tests of UPDATE and SELECT above, but will become necessary, as new page creation is worked into the flow.

H6S5: Smart–UI: I also need to # limit page creation to only slots, that are not already occupied by text and links.

H5S42: Creating a $post_ID variable, and plugging this into our SELECT and UPDATE statements:

Hu: The first basic test, is to see if, on a per | page basis, on dash-edit.php, and post.post-number.php, we can define a post_ID variable, and use the value assigned to this variable, rather than a hard–coded | number, to complete the SQL-queries<Turing>: the initial | post_ID will be simple, with a value of 1.

// Declared in our global requirements section:
$post_ID = 1
// Called # in a SELECT statement line:
	$sql = "SELECT text1 FROM wp_posts WHERE post_ID = $post_ID"; 

Hu: After testing a single SELECT instance, and passing, I have now propagated the $post_ID call to the other 3 | active | instances.

H5S43: The post_ID variable can be dynamically | pulled from the URL:

Hu: I was just made to remember<fbno> that I will not have more than 1 instance, at all, of post.post-number.php, and that the data for each | unique | page, to trigger the loading # of that page, from the db, needs to be stored in the URL<WP.MIC-H2S42,H3S3.H4S8>, read there for more details, on the following code-snippets #

action="edit-mysql-redir.php?post_ID=<?php echo $post_ID; ?>"

Output: http://personal-dash/edit-mysql-redir.php?post_ID=1, which is correct ✅

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

// URL syntax: http://personal-dash/dash-edit.php/?post_ID=1

//Global $post_ID variable declaration:
$post_ID = $_GET['post_ID'];

H5S44: Static MySQL-INSERT to add a new row as a page | instance<r: WP.Learn-SF,10/17/22><WP.MIC-H2S30>

<?php 
require 'database.php'; 
$sql = "INSERT INTO wp_posts (post_ID, post_author, post_title, text1, url1, text2, url2) VALUES ('2', 'blind', 'p.dash-2,entertain', 'ITZY.YT', 'https://www.youtube.com/results?search_query=itzy', 'Twice.YT', 'https://www.youtube.com/results?search_query=twice')";
	$conn->query($sql); 
?>

H5S45: Next task: 1) design UI on dash.edit.php that when clicked, triggers page.insert-inc.php. 2) Redirect page.insert-inc.php to the new created page, after creation, by linking the post_ID to URL.

H5S46: Next task: tracked logged in user, and separate tb write, for each user # 1) Launch a new table in db, corresponding to user_2, “dash.chae-posts”

H6S2: Create a manual | variable, corresponding to the current user responsible for the browser | session, but without any browser | dependency yet, from memory, that is used, to write to the table differentially. H6S3: Since I have now # separated each author to his own table, I no longer have an author column; therefore, the variable in<H6S2> will determine which table to write # H6S4: As a consequence of this determinancy, I will need to include the username of the author in the tb-name, of each dash.[author-username]-posts. H6S5: wp_posts has been renamed to dash.blind-posts. H6S6: Note that the $session_author # cannot be pulled from the URL, since with public–dashes, you may be viewing # a post written by a different author, and this feature relates to editing. H6S7: In accordance with preceding, I will define 2 global | variables:

$session_username = 'blind';
$post_author_username = $_GET['author'];

Hu: The former | username will be used # to check whether the session | user has permission to edit the article; if so, his username, in the top line, should match the $post_author_username. If there is a match, and the user edits, the second variable # will be used, to write into the correct | database. H6S8: The current post_author_username will be retrieved via $_GET from the URL, which will now have this structure:

Pages: 1 2