Reflect the current URL in the browser navigation bar #5
Comments
Yes, that would definitely make sense only in the context of the |
This is now easy with It could also work in a seamless mode via The ServiceWorker would have to be smart about handling different types of requests:
|
adamziel
changed the title
|
It has been done in this commit: bloqifi@352190c#diff-92f163a9d50e1c25a44764089df3a996a8ce10e7315f7f9ebe5d89554d52e245 |
|
@krishenriksen good explorations! One tough nut to crack there is handle page refreshing. I haven't actually tested that commit, but I noticed it doesn't alter the service worker code, which means that refreshing the page or sending someone the link will display an error page – see my previous comment in this issue. Do you have any ideas how to approach that? |
|
@adamziel I am looking into page refresh, but an obstacle we / I must overcome first, is storing the db in indexeddb, so any page refresh will maintain changes. |
|
@krishenriksen I’d say data persistence is a separate issue from refreshing the page after pushState. Definitely worth addressing, too! Using IDBFS instead of the currently used MEMFS could help with that one. |
ghost
mentioned this issue
|
Now that we have persistency, it would be great to work on this. This would mean that Playground could allow for a useful seamless mode and alos be more resistent to accidental reloads. If you reload the whole page in the browser by accident then we could at least navigate to the same page back again. |
akirk
added
[Type] Enhancement
|
@akirk Counterpoint: you couldn't refresh the page to scrap your temporary site and start over from the same blueprint. We'd need a different behavior for temporary sites and stored sites, and that sounds confusing. |
What if we introduce subdirectories The idea is that you could go to |
## Motivation for the change, related issues **This is a WIP draft at the moment. Looking for feedback on the direction I'm taking here.** The new SQLite driver requires the `DB_NAME` constant to be set. This is to be able to store the correct database name in the information schema. However, some WordPress site backups and exports don't include the constant in `wp-config.php`. This happens with hosts that inject the database configuration in a different way. Even though we could probably emulate it dynamically in the SQLite driver, this may be non-trivial, e.g., in cases someone joins on the `information_schema.tables` table, etc. Making sure that the constant is defined seems to be easier, and should also improve the compatibility with any plugins that rely on the `DB_NAME` constant to be set. --- This was discovered when importing a site backup without the `DB_NAME` constant in Studio: ``` Fatal error: Uncaught Error: Undefined constant "DB_NAME" in /var/www/html/wp-content/mu-plugins/sqlite-database-integration/wp-includes/sqlite/db.php:64 Stack trace: #0 /var/www/html/wp-content/db.php(37): require_once() #1 /var/www/html/wp-includes/load.php(683): require_once('/var/www/html/w...') #2 /var/www/html/wp-settings.php(133): require_wp_db() #3 /var/www/html/wp-config.php(85): require_once('/var/www/html/w...') #4 /var/www/html/wp-load.php(50): require_once('/var/www/html/w...') #5 /var/www/html/wp-blog-header.php(13): require_once('/var/www/html/w...') #6 /var/www/html/index.php(17): require('/var/www/html/w...') #7 {main} thrown in /var/www/html/wp-content/mu-plugins/sqlite-database-integration/wp-includes/sqlite/db.php on line 64 ``` Related: - Automattic/sqlite-database-integration#40 - Automattic/sqlite-database-integration#44 ## Implementation details ## Testing Instructions (or ideally a Blueprint) 1. Boot Playground (`npm run dev`). 2. Export the site into a ZIP. 3. Remove the `DB_NAME` constant definition from the ZIP. 4. Import the site without the `DB_NAME` constant set. 5. Verify that a `DB_NAME` constant was injected (TODO: describe how). 6. Export the site ZIP and have the `DB_NAME` constant defined in `wp-config.php` (TODO: is this required?).
At the moment, the top URL bar only says index.html, and all the navigation happens inside of an iframe. It would be great to have a feature that would update the top-level navigation, perhaps via
pushState. It needs to be optional because updating top-level navigation doesn't make sense in contexts like runnable code examples.The text was updated successfully, but these errors were encountered: