This is searchable archive of our old support forums, which operated from 2012 - 2016. To find out how to get support for your current theme, please visit our support page.

Recover content from crashed layout?

  • Creator
    Topic
  • #689
    ahcox
    Member

    Hi,

    Firstly, thanks for your work on these themes. I really like the look of Barely Corporate and in addition, yours are some of very few that look good in portrait on a Nexus 7 tablet (11.? 60 pixel columns may be the problem for them).

    Anyway, I made a layout with clicking and dragging twice and both times the layout tool started crashing persistently after I had started filling the layouts up with my copy. Obviously, long-term I would like the crashes not to happen, but for now, where is my content stored, and can I get it back? I am a software engineer: I just need pointing in the right direction.

    The content I want to recover was typed into the “raw content” of a Columns element set up with two 50% columns.

    Also, here is a clip of what I see in the layout manager after it starts crashing:
    http://clipboard.com/clip/LQV2k2SZfACPhUrrFG8XN1qvsxHy43V46Kee
    Any help with that?

    Thanks,
    Andrew

Viewing 9 replies - 1 through 9 (of 9 total)
  • Author
    Replies
  • #690
    Jason Bobich
    Keymaster

    Hello,

    I’ve honestly never heard of any kind of issue like this. This seems like some kind of issue with your WordPress site or your setup there on your server with your database. Why I say that is because the theme doesn’t actually do anything custom in saving this data, but maybe explaining this to you will help you to solve your issue or recover your data.

    The framework registers a custom post type called “tb_layout” and then each custom layout you create is a new post of this type. Then when you configure your elements, this is saved as a post meta (also known as “custom fields”) to that post.

    Realistically for WordPress, this is the same as if you created a new standard post and then added custom fields to it. So that’s why I’m having trouble making sense how you say it “crashes”. The only way for that screenshot to be possible is if all of the meta data for those posts were somehow wiped clean in your database?

    #694
    ahcox
    Member

    Thanks,

    The framework registers a custom post type called “tb_layout” and then each custom layout you create is a new post of this type. Then when you configure your elements, this is saved as a post meta (also known as “custom fields”) to that post.

    Interesting, I checked, and one of my broken layouts has no post metadata, and the other one has this for “elements”:

    a:0:{}

    and this for “settings:”

    a:1:{s:14:"sidebar_layout";s:10:"full_width";}

    I can’t find the metadata for another layout that does work okay though so I need to look some more if I want to get into this. Not why I came to wordpress for a site :-/.

    Thanks again,

    Andrew

    As an aside, is the layout storage format documented? It looks like it could be a terse way to build a layout in text.

    #695
    ahcox
    Member

    Hi,

    I found all the metadata. the elements are garbled for the two broken layouts. See the one below. It breaks off just where I had inserted a unicode character in a html hexadecimal form. It was supposed to make a scalable vector icon. I was seeing issues with losing data and character swapping beteeen the encoded form and glyphs in the edit box.

    Could this all be a unicode issue?

    Thanks,
    Andrew

    a:2:{s:8:"featured";a:1:{s:9:"element_1";a:3:{s:4:"type";s:6:"slider";s:10:"query_type";s:9:"secondary";s:7:"options";a:2:{s:9:"slider_id";s:35:"hoogli-gallery-call-to-action-users";s:10:"visibility";a:3:{s:16:"hide_on_standard";s:1:"0";s:14:"hide_on_tablet";s:1:"0";s:14:"hide_on_mobile";s:1:"0";}}}}s:7:"primary";a:4:{s:9:"element_3";a:3:{s:4:"type";s:7:"columns";s:10:"query_type";s:4:"none";s:7:"options";a:7:{s:5:"setup";a:2:{s:3:"num";s:1:"2";s:5:"width";a:5:{i:1;s:7:"grid_12";i:2;s:13:"grid_6-grid_6";i:3;s:20:"grid_4-grid_4-grid_4";i:4;s:27:"grid_3-grid_3-grid_3-grid_3";i:5;s:64:"grid_fifth_1-grid_fifth_1-grid_fifth_1-grid_fifth_1-grid_fifth_1";}}s:5:"col_1";a:3:{s:4:"type";s:3:"raw";s:3:"raw";s:457:"Benefits for Users
    [dropcap]
    #702
    Jason Bobich
    Keymaster

    Where you sad you inserted “a unicode character in a html hexadecimal form” — Can you show me a screenshot of exactly what you’re putting in so I can try to reproduce the issue?

    #705
    ahcox
    Member

    Hi,

    I did this sort of thing: http://clipboard.com/clip/LQUzFJMFJIZxFeda1GNIHaWAD4RFvNcR1tme

    Here is an example:

    [dropcap]👪[/dropcap]long came a monkey. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat 
    
    [dropcap]👪[/dropcap]long came a monkey. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
    
    
    [dropcap]👪[/dropcap]long came a monkey. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

    Run through Barely Corporate with some user css on top it looks like this:
    http://clipboard.com/clip/LQUzEUUjpeywQ4AELWajf56j38weam-PJGae

    Right now I am pulling in my column content from a separate page, which so far is working okay for this specific use. I’d like to be able to use the unicode-as-icon approach throughout however, so if somewhere between php/wordpress/themeblvd excaped/encoded unicode is getting messed up that would be worth fixing (other people who want a responsive site do this as well instead of bitmap icons).

    What I remember seeing yesterday was that after saving a block of text like the one above into raw content in a layout, it would have turned from

    👪

    into

    #706
    ahcox
    Member

    Wow, the raw unicode character seems to have killed my last post.

    This is what was in the box before I posted:

    http://www.hoogli.com/nl/temp/themeblvd.png

    (I do a CTRL-A, CTRL-C by reflex before posting anywhere)

    Is this forum built on WordPress or at least PHP?

    Best,
    Andrew

    #707
    ahcox
    Member

    I looked at the source of this forum page and my truncated post does just end at the unicode character:

    What I remember seeing yesterday was that  after saving a block of text like the one above into raw content in a layout, it would have turned from 
    
    👪

    into

    #713
    Jason Bobich
    Keymaster

    I’m really not sure on this one. You may just have to avoid that one or use the external page as the workaround as you’re doing. I wish I had a better answer that could shed some light on it. When that data gets saved (for a textarea option for example), we’re just using common WP builtin sanitization functions to ensure that it can be safely saved to the database, and then saving all that data with update_post_meta.

    Note: If you’re curious what the theme actually does to the text area option when prepping for saving it to the DB, see framework/admin/modules/options/options-sanitize.php and see the of_sanitize_textarea function.

    As far as this forum, it’s running bbPress on top of WordPress. bbPress is the official forum plugin created by WordPress.

    #714
    ahcox
    Member

    Hi,

    Thank you very much for all your answers and especially for getting back to me over the weekend.

    This issue seems to be outside the scope of themeblvd, so I’ll work around and hope for the best.

    Thanks again.

    Best,
    Andrew

Viewing 9 replies - 1 through 9 (of 9 total)
  • The forum ‘Barely Corporate Responsive WordPress Theme’ is closed to new topics and replies.