search

WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.52k stars 4.21k forks source link

Flaw of storing the absolute path instead of the relative to the WP install directory #6509

Closed jstillings1 closed 6 years ago

jstillings1 commented 6 years ago

Issue Overview

No back up software will be over come this flaw of storing the resolved absolute path instead of the relative to the WP install directory path and will require your file structure to match on the restore. Which is a huge issue if moving from a Non ssl to a ssl site, or have a cloud media accelerator on.

Steps to Reproduce (for bugs)

  1. Try to back up a Gutenberg site and restore it elsewhere.

  4. This testing was done on a sandbox on a live host that is a shared plus account at hostmonster.

Expected Behavior

I would like a back up to be able to be restored in a different hosting environment and not fail and cause days of work.

Current Behavior

See below

Possible Solution

a work around might be to store the WP_settings Variable for ABS path instead of it resolved. A fix might be to include the entire media INSIDE the Json blob serialized and do away with the attachment pages? This would allow a site's content to be entirely backed up by grabbing the DB file. I did not research how gutenberg is storing the css for its json blobs, so that might have to be addressed also if this fix was the pick.

Screenshots / Video

Related Issues and/or PRs

Todos

Blog on this issue is found here.

[http://www.jeremiahstillings.net/wp/day-1-with-gutenberg/]()

`

Welcome to Gutenberg!

Test 1 is to see how the editor stores its data

WP is very easy to use. BUT hell to back up. Over my years of using wp, I have dumped more sites unintentionally then I care to admit. How does this happen? Well in wp classic, the core data is stored in the WP SQL database when installed. SO naturally everyone thinks if we back up the data base we got our SITE. Dead wrong. Unless you are using vanilla wp, your theme choice and plug in choice is going to dictate what you actually need to back up. Back in Dec of 2017, I was trying to migrate  WP site from a host with a SSL cert to a non cert host. Easy right? Back up the database! Oh how wrong I was! This site was using a few  nice modern features. Avada theme by themeforest. Revoultion slider. Contact form 7. Yep if all I grabbed was the database, I would have lost ALL of the data that is the actual site. Avada stores is front end options in a JSON file, but I still do not know which one and where. Since it can take about 3 hours to set up this front end, we NEED To be able to save those. Avada has this feature where they allow you to EXPORT the JSON file and then later IMPORT it into your new WP install after the theme has been loaded. Wait what? Your telling me the theme does not store the site in the wp database? No they do not! This is the PRIMARY reason for Gutenberg’s focus in phase 1 being the Editor.

Where Gutenberg' s editor stores its data was shocking!

I had  secretly hoped that the brains behind the change would be placing the DATA in the DATABASE! Cause DUH it makes sense. Yes indeed the data is stored in Json Blob from inside the _posts table
LOL it just took me three minutes to figure out I couldnt hit enter at the end of that picture and continue. HAHA Welcome to blocks! This new unification of data storage is a sweet breath of fresh air. As a developer I do not have to spend HOURS figuring our how this theme stores its data and options.

The critical flaw

WP has been about the conical tag forever. The media attaching to a post type is something that very few end users even see. What happens when the Json Blob is storing this conical tag for the attachment post? Yeah, if your like me you saw it already. You are married to your file structure, and your SSL choice. No back up software will be over come this flaw of storing the absolute path instead of the relative to the WP install directory if your file structure does not match on the restore. Now what can really complicate things is the media setting in Settings Media. There was this cool feature to add year and month to your media upload conical... not so cool now.

Your media in Gutenberg

Right now in the beta plug in, media a pointer is stored in Json blob in the _post_meta table.
Yup you saw it! _wp_attached_file is a conical but it is relative which is cool, but see that year and date there in the path? Since this is a pointer, this means any restore will have to have the identical file structure. File Structure Issue Which means you can NOT just save the WP Database and call it a day, and I do not now why they are not storing the media in the data base, but they are not. Any backup, restored without the exact same file structure will cause  the famous white boxes of death in the media organizer. This is the attach page post

One step in the right direction, one step back.

I am super happy to see the editor placing the data in the database, but the use an absolute path in the Json Blob is a dangerous thing. I am hoping that perhaps future releases of Gutenberg will address the media issue I presented.

Side note:

I wrote this post in my sandbox, but since the new editor renders in real time HTML5, I was able to select all and copy  the Visual data and paste it into this word press classic site and Not even upload a single image, due to the ABSOLUTE PATH...

LOL maybe this is a way we can start to check copy rights on images lol.. Just saying.`

danielbachhuber commented 6 years ago

Hi @jstillings1,

Thanks for the suggestion! Making this type of change isn't on the Gutenberg roadmap right now, so we'll keep your idea in mind for the future.

jstillings1 commented 6 years ago

Thanks @danielbachhuber I believe Gutenberg will solve this issue in due time, happy to see it being kept as an idea for the future.

aristath commented 6 years ago

I just saw this issue and wanted to make a note... What is said above for the Avada theme is completely inaccurate and false. The theme saves its options in the options table in the db just like any other theme or plugin. The export/import as JSON is a convenience, it's not the way the data is stored. Data is stored in a serialized array in the db just like it should. Saving the options as a json file would be inefficient and costly as the site would have to read that file on each page load and the theme would depend on the WP_Filesystem just to get its options.