H2S41: Web-URL code design, data-storage:

Hu: For db-extrapolated systems, each type of page has only 1 instance in FTP, but as many instances, as there are rows, in the tb, in the db #, associated with that page–type<Turing>

H3S1: URL-design can circularly store without existing:

Hu: 100,000 web-pages don’t exist on Google, 100,000 db–rows do, and each page, associated with each | row, are only accessed, when a specific | URL, which triggers the retrieval of that row from the db, is entered, and sent, as part of the client.side–request. This means that these rows, can exist, and we can say that 100,000 web-pages exist, even if these links have never been visited, and the HTML-versions, never rendered #

H4S1: URLs must persist through page-load:

H4S2: URLs must allow for appends that contain specifying | data:

Hu: URLs must specify a categorical, load that categorical, and still provide specifying | data, for that categorical | template to be able to # load the correct | content from the db.

H4S3: URLs point to and represent data location:

Hu: In education | science<MIC.ch-20>, it is known that # memory is distinct from the retrieval | pathway, to that memory. Analogously, the data that is stored is distinct from its location, which, as a URL, also specifies the path to reach that location. For example, a URL can specify a local path, which never needs to traverse the routered | web, or a web | path. Therefore, there are 5 elements that co-exist, in the URL-case: H5S1: an address, the URL H5S2: a memory, that is to be retrieved H5S3: a physical path, to that memory, as specified by the URL, relative to the starting point’s self-awareness H5S4: an interface that provides that starting point and H5S5: the location of the memory, which is pointed to, by the address.

H6S1: There are 2 | types of locations that can be pointed to by a URL: a hardware | location, or a MAC | address, and these are typically domain names or IP-addresses, by nomenclature and H6S2: a software | address, like the location of a file, containing a script, in a Window’s directory<all>, or a grid, in a SQL-db<WP.MIC-H2S30>

H5S5: URLs can be used as destination specifiers<Turing>and identifiers; the identifier use case half-overlaps<WP.MIC-H2S74 et al><fbno>with firewall | architecture, as firewalls use these names to determine | identity, and, generally, hardware is the one-to-one | correlator in the identity | layer<sec>

H5S6: URLs are stored at transit points: Hu: a strong retrieval cue is located where what is retrieved is to be applied #; analogously, URLs are stored H6S1: wheren # data is expected transfer in script-exec, pointing destination, H6S2: listeners of inbound-data, like Apache<H3S7>, containing a white or black | list to check | against.

H3S2: URL external.lit-rev:

Hu: I would say URLs are as fundamental an aspect of the tech | stack, and can be just as feature-rich#, as the entire server–side, but it can also be considered, to an extent, to be an extension of PHP.

H4S1: / division as the URL.append-mechanism:

Hu: On my local WAMP-install, I have validated # that http://personal-dash/dash-edit.php/ and http://personal-dash/dash-edit.php/post=3 will redirect to the same page, since I have not<10/17/22> built any variable–pull | functionality yet. This indicates that the inclusion of the # / is a built-in URL.append-mechanism, on the level of HTML, and the browser, that will continue, most–critically, loading the same page | template, from our www-files # // insert-quote

H5S1: Moreover, it should be noted that the URL-append persists for the session, prior to clicking off to another page #

H4S2: $_GET lit-rev:

See if posts.php in wp contains any URL secrets 

How do they generate the next URL

https://youtu.be/seMel-MkVKo
- need to concatenation, add on to the string:
- I may need to generate a full URL one time, of the new page, from the created.on-page # 


- basic flow for appending existing html url redirs

Ken Swartwout: https://youtu.be/J4kNbMnrGas
- identical implementation: he uses a URL, generated via concatenation on a previous page to trigger differential database retrieval on a general content-post page<Turing>
- ^ Is the URL request itself a $_GET? Makes sense if so <80%>

https://youtu.be/afhePzFcwdE
- Demonstrates the format for adding a variable manually into a url and still being able to access w/ get
- Add a quick how to learn from tutorials, combine docs and videos, but this is not learning per se, this is avoiding troubleshooting 
- For now, focus on getting the URL, as a simplest single numeric, and not on creation yet. 
- Later, in the creation step, write the insert function first, which will create the post_id parameters into the db, and then generate the url from there, to secure, so users cannot manually manipulate the url during creation. 

profgustin: https://youtu.be/Hx60yNb43fw
- Generating URL without form, and also not typed, coded generation, and from a previous file.

H4S2: Correct | format for multi.$_GET<Turing>:

W3Schools: test_get.php?subject=PHP&web=W3schools.com

Hu: Note that URL-variables # are separated by an ampersand, and this prevents the $_GET retrieval from pulling everything after the first = # as a single | string.

H3S3: A PHP variable that pulls from a URL-append #<Turing>

The key to the design of personal | dash is a URL that can be called upon to supply the value # for the $post_ID variable, and this URL, for each page, also needs to be created, upon the page | creation mouse | click<WP.MIC-H2S10>

H4S1: Db-insertion, as the first step of new page creation:

Hu: A db-insertion needs to be made, into the MySQL-table containing pages.as-rows, on the final step of page creation, as the first step #

H4S2: A URL does not need to be created, separately:

Hu: Once the page exists as a row, the URL does not need to be created; however, a hyperlink should be generated, for the user’s convenience, and possibly displayed, and this hyperlink, can be dynamically generated, by pulling from the db.

H4S3: A new ID needs to be generated:

Hu: At some point in the page creation process, the system needs to calculate the correct | value for a new_ID, for instance, by checking the last row in the db, and appending+1 to the post_ID of that row, or using some other function, or sequence of functions, to perform a computation. This computation will be completed on some page, that is redirected-to, from the page, on which the user confirmed the new page creation, and will occur, prior to the INSERT-statement<Turing>

H4S4: Pages need to be structured # to dynamically pull the post_ID variable from the URL append, that is typed #

H4S5: The URL_append needs to be passed, to all subsequent page variations, such as dash-edit, and mysql-edit-redir:

Users will, at times, travel from post.post-number.php, which will now take the form of post.post-number.php/post_ID=3, for example, to dash-edit.php, and therefore, dash-edit.php, needs to also carry this append, in the form of dash.edit.php/post_ID=3; a scraper can be built, mutually, between each of these 2 pages, to scrape for that post_ID; there needs to be a way to pass this inheritance to other pages, in a subsequent click-through chain.

H5S1: /post.php?post=1117&action=edit, ?p=1117, h2s41-web-url-code-design-data-storage/ Hu: WordPress has several different types of url-appends, the first, for editing post=1117, the second, for displaying, and the third, an alternate URL, for the display.

H5S2: All internal | redirects, that we know # will be to another page, in the edit | chain, can carry a dynamic elements, that quotes the post_ID, of the page, or the post_ID, that is currently used in the URL. Since all $post_ID variable will be pulling from the URL already, we can also insert that variable, into the redirects, and append via dynamic | pull<Turing>

<!-- After implementing $post_ID, and URL appends, the next link will need to call the $post_ID variable, as an append #  -->
<p><a href="dash-edit.php">Edit</a></p>

Hu: We won’t need any session token, to automatically append, as of yet, because we can built this in pseudo-hard, by appending to each redirect | URL, a variable call, to $post_ID, which will itself be defined, by the URL of the current page, as a lossless | form of append-prop # You may have noticed at this point, that I always do the max-red, as a property #hire-me. A PHP-encapsulation, containing the variable | call, can be inserted, after .php, in the a href quote #<Turing>

H5S3: URLs that take users to pages that correspond to a different tb–row do not need append | propagation:

Hu: In p-dash, other URLs, including internals, are hard–coded, by the user, into their own interface; here, the append link will break, and users will assume the new post_ID, of the external; this switch is built into the UI-design, and does not need to be additionally | coded<Turing>

H5S4: post.post-number.php will be purely an empty URL pull:

Hu: This page, since it’s the initiation of our edit-seq, will never inherit, except from edit-mysql-redir, when the edit-seq loops back to the beginning; in all other cases, it will be novel | linked, by hard-code, within a p.dash–slot. However, we would still like to automate this, as a pseudo–luxury, and start users off with the hyperlink in hand #

H4S6: Fundamental | syntax for a $_GET variable call:

$post_ID = $_GET['post_ID'];

Hu: This single line var-decl # will pull the value following post_ID=, in the URL, and assign that value, to a php–var named # post_ID, which is passed to # all instances in which a value for the post_ID column, in my db-tb, is required, for MySQL-queries<Turing><WP.MIC-H2S10.H3S8-H4S5,H5S43> X.ref: profgustin, YT.

H4S7: URL syntax for a $_GET variable call:

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

Hu: With the variable | def re-mapped from a hard–value of 1 to the dynamic | definition $_GET[‘post_ID’]; , the page will now give # an error, if it is accessed # without a valid GET-value in the URL; currently, the only valid such value is 1, since we have only 1 row in our db.

H5S1: Error 1: page accessed as /dash-edit.php/ with no appends:

H5S2: Error 2: page accessed as /dash-edit.php/?post_ID=2, but there is no such ID:

Hu: Later #, I will need to redirect these invalid URL entries, back to the previous | checkpoint.

H4S8: Propagating the URL.append-syntax<H4S7> to subsequent pages in the chain:

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 ✅

Hu: Each URL’s append | line has a consistent aspect #, ?post=, and this will be hard-coded into the HTML; what follows, is the dynamic | value, and this will be fetched # from the current URL, since we are simply propagating the current URL, into the next URL, and this can be done, by transitioning to PHP, and once again, referring to our $_GET variable #<Turing>

H5S1: Intermediate processing pages, that are not displayed # to the end user, may not need to propagate the append #

Hu: However, if that intermediate page, is the only pathway to linking to the next<ch-13, portal systems>, then it may still need to carry the propagation, even in its silent | URL.

H5S2: URL.append-function,call without php-encapsulation:

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

Hu: On edit-mysql-redir.php, the redirect is automatic, which means it’s not associated with a hypertext | link, that has an HTML component; we can simply set the post_ID parameter in the URL directly equal to a variable | call, with $-included #, and there’s no need to add a php-encapsulation, since we are already in PHP #

H3S4: Using URL parameters to propagate persistent page settings:

Hu: Case study<WP.MIC-H2S44,H3S3> URL parameters, which are $_GET and pushed, can be used to propagate a setting, such as search bar display, or header setting, on a website where users can swap out their own header persistently; the setting can also be ghost-transferred, across pages where there’s a hard-override, with a silent | variable<Turingx15>

H3S5: Automatic.scroll-down via URL parameter:

Hu: Particularly useful at WP-MIC, and with MIC #, I would like to be able to # hyperlink to specific sections, in a long blog post, by specifying the heading, in the URL // add-research

H3S6: URL.migration-paradigm:

Hu: Whereas db-migration is simplified by db-conn.php, which stores, one time, a unique connection to a db, simplifying server migration, to a live-db, to a few lines of changes, to just the db-config, in that file, URL-migration can be more complex, when there are hard.coded-redirects in the thousands+, and the lead-params need to be changed, from local to live. It would be optimal to have some variable, that is remotely | defined, control this variable | portion only, such that URL-migration can, likewise, be abstracted to a single.line–change<Turing>

H4S1: Global variables:

Hu: The global variable feature can also be used to once defined | variables, which can be used to control a large number of cases, such as $session_username and URL prefix.<WP.MIC-H2S45> Create a global | variables include, first one is the URL prefix global, has 2 versions, one for https and one for C: maybe threaded. Do one for https for now as well, just for scaling | security.

H3S7: URL-handling in Apache:

<WP.MIC-H2S114>: Apache has several layers of URL handling; one, it processes incoming | URLs, which can be in the form of IPs<Turing>and determines access | policy. Second, it determines the URL of links in the prefix #<sounds-kewl><fbno>

Public case: http://71.126.6.14/personal-dash/login.php
Error case: http://71.126.6.14/login.php
Private case: http://personal-dash/login.php

H4S1: Business-req<WP.MIC-H2S62>

Needs to recognize visitor as localhost or remote.to-router, and give a slight variation of URL, or as a recognition in the $_SESSION variable, which can be established upon landing to http://71.126.6.14/personal-dash/ with a variable.controlled-URL, this is half part of access-management H2S5 x H2S41<H3S1-H4S3>

H4S1: A revolving-door case for URL-handling:

Hu: This here<Mark-H!>is a complexity | hinge due to a 2-sided URL-handler; the identity of the incoming | MAC determines the handling of the destination | pointer, unless a universal | case can be invented<Turing>This is the challenge inherent in permitting use, equivalently, of the same files, via local and router-remotes.

<a href="../login.php">Log-in</a>

Hu^: The code | snippet in index.php is my implementation for URL.destination-specification to the login-page, which worked fine enough under local.only-conditions, up to 12/11/22. However, as a result of a new.working–cooperation with Ahyeon Cho<WP.MIC-H2S62>, I need this page # to also be accessible, with correct URL-behavior, when users access using the public-IP: http://71.126.6.14/<WP.MIC-H2S74>

Hu: It would be unwise to a) rewrite the entire script or b) create 2 versions of the same file, just to create | accommodation for this URL-case, since in proportion to total length, URL-specs are 3-5%<Turing>Again, I either need a conditional | toggle or a universal.case-invention; this necessity is consequent of me<WP.MIC-H2S37>being the pioneer into<WP.MIC-H2S70>

Above, the public case specifies that all public visitors, for the duration of their visit, need the prefix

http://71.126.6.14/

leading all URLs, on every service, and specifically:

http://71.126.6.14/personal-dash/

as the prefix, for all pages, within the personal-dash service. The error case is how users are directed when the log-in button is clicked, for external visitors only, from the public-side; if this URL is manually corrected, the correct destination can be reached. This error occurs only for public-visitors, as for local visitors, the personal-dash segment of the prefix is correctly | appended, every time, such that users stay within the service.

It is difficult to specify an absolute | path to address this issue; as you saw, my current path specification is relative, and this, in conjunction with a pseudo-bug, or just an unprogrammed backlog task, on the part of Apache, triggers the error #

[D, 3]: overall attention management this game was good, particularly on the central.p-clustr,management.

References:

https://tryphp.w3schools.com/showphp.php?filename=demo_global_get