November 7, 2014 at 7:45 amParticipant
This is really really annoying. I always suspected it had something to do with me, but I can’t seem to keep certain bits of content from disappearing altogether when I Save changes. Entire paragraphs.
It’s terribly frustrating. What can I do?November 7, 2014 at 11:49 amKeymaster
Sorry to hear Boris. Do you mind elaborating further?
What theme are you using? I assume Kerouac? Version of Aesop Story Engine?
If you have any available links that would be helpful too.
November 8, 2014 at 2:09 amParticipant
- This reply was modified 6 years, 5 months ago by Michael Beil.
Latest Aesop, yes Kerouac. The link is storyfall.nl/interreg.
I think I may have figured out why, and it’s a treacherous thing. Components in the updated Aesop are represented by a black block in the editor that takes up a single line. I noticed how they tend to invoke/insert white empty lines (in the WYSIWYG editor) below themselves too. I found these annoying and assumed them in error so I often mindlessly deleted them. But I suspect now that deleting these white lines actually causes valuable code to be deleted, a problem which the editor then solves by deleting the crippled code – taking chunks of content with it.
Does this sound clear? And plausible? All I know is, since I stopped deleting the ‘random’ white lines, the story content has stayed intact too. I’ll need a different approach how to delete them in final cleanup. Probably through the text editor. At least there, WYSIWYReallyG.
November 8, 2014 at 8:45 am
- This reply was modified 6 years, 5 months ago by Boris de Jong.
The components do not insert white spaces. Only one, the content component, will insert a blank space after the component while in the visual editor. This is to ensure that the content escapes itself. I went through and tested each component and none of them add additional space, except for the content component. If you’re finding each component adding space, can you provide a screencast or let us know how to replicate this?November 8, 2014 at 9:41 am
I just came across this myself. It’s pretty edge case and hard to reproduce unless there’s two components back to back. If you click into text mode you’ll see this which is a white space. Deleting that fixes the issue for now.
I’ve re-opened the original Github thread on this and you can follow along here:
https://github.com/bearded-avenger/aesop-core/issues/127November 13, 2014 at 10:22 am
Not sure if it’s the same things but I’m having problems with editing a component via the edit button (and not the actual shortcode text itself).
I’m using a PC. Chrome or FF.
I click edit; the ASE “editor” overlays; I do the edit; I click Save; but the component’s short code is mucked up and perhaps even went MIA a couple times. I then have to redo the component.
btw, I think this is why I’d like to see the component’s args (as currently) stored in the shortcode) be stored / manipulated elsewhere and only a shortcode id be maintained in the actual content. Just me?November 13, 2014 at 10:26 am
The overlap stuff was fixed on the last version I believe. If you’re running into this issue can you create a bug report with the exact steps that we can take to replicate the issue? Here’s that bug topic if you’re curious:
P.S – If WordPress gave us a way to additionally store them somewhere we’d likely utilize it! But we’d like to stay as close to core as possible. Ya know, one day they may want to buy us out and use some of our tech! 🙂November 14, 2014 at 10:02 pm
1) I’ll try to make note of the pattern when it happens. I’m on the later WP repo version. Do you suggest we start pulling from GH to be more current?
2) Actually, I 98% certain you can do it now with PV (plain vanilla) WP
Each shortcode’s properties would be post meta (or perhaps all the ASE components could be an array to be stored as a single post meta? whatever. But these is a way to store it).
While this probably isn’t the ideal UI / UX just hear me out, please…
Imagine a post meta box below the WYSIWYG – think Yoast’s SEO but different – that’s a list of the ASE component for that post. Every time you do an ASE Insert Component, the shortcode continues to go into the_content as it does now. But instead with this new and improved approach the only variable / property in the shortcode is a unique id. The rest of the meta data (if you will), gets added to the list in the meta box.
Note: I’m not saying the shortcode properties in the post meta_box could be edited there. They’d probably just be display only – and perhaps just the main properties would be displayed. That said, the Edit link would do what it does now, the ASE modal will layer over, the properties will fill in, and the user would edit. The difference is, the properties aren’t coming from the shortcode.
When the_content is output the [shortcode ase_id=”some-unique-id”] gets replaced with <div id=”some-unique-id”></div>. That’s it server side.
The rest of the ASE “meta data” gets passed down as either JSON or maybe even via localized (or similar). The point being, the client side js reads the JSON, builds the component, finds the id selector and appends it. There’s nothing really groundbreaking about that. In fact, that’s kinda where WP is headed, eh? 🙂
As mentioned previously, now that ASE is JSON driven, a lot of the future (?) headaches with shortcodes go away. In fact, instead of inserting a shortcode you could just insert the <div id=”some-unique-id”></div> and skip the short code. The point is, the client side js just needs a marker (aka selector) for each component. The js can do all the necessary magic if it has the selector and the JSON for that component.
Finally, I think this also allows for a couple other advantages:
1) There can be a library of “default” components for a given install that can be search – via AJAX? – within the metabox mentioned above. So instead of having to build from scratch, there can be a library of pre-configed building blocks, so to speak. Maybe along with Edit and Delete buttons next to each component in the ASE meta box list, there’s a Save To Library option?
2) If I want to *temporarily* remove a component, I can. The properties would remain safe & stored in the metabox list (until I delete them). When I want to put it back, all I would need is an input with the shortcode that I can copy from to re-paste into the WYSIWYG. So if I’m trying to decide between two or three different layouts / designs I can manually “A / B” test for my boss, or whoever. It’s not really the current all or nothing. Actually, there could also be a checkbox next to the Save to Library for Display / Don’t Display. This way I can turn components off (or no) without deleting, etc.
3) I would think backwards comparability is easier as well. “The marker” (with the unique id) is 100% independent of its properties. The properties are also all on their own (as good data / model should be). It’s then up to the js to make it work. And that’s where the logic should be any way.
Yup. I think it’s VERY possible in the current world of WP. In fact, I think this approach is #BadAss 😉November 14, 2014 at 10:11 pm
p.s. And if you REALLY want to push the envelop (which may or may not attract Automattic), this is a step in the right direction “Beyond the WYSIWYG” and the_content. With this model / approach the_content is more like a storage blob. It’s more or less just the raw structure of what’s to be presented. The actual content is meta data.
Sure, you *might* still have a WYSIWYG but at this point (in the future), it’s just another ASE component type. Now you’re story building start with a raw / empty canvas, and it’s a series of drag & drop boxes that sit on top of (so to speak) the_content. Want to move a picture? Just drag it up. Want to pull something out, but not delete it? Just drag it off the live area / story canvas.
I can be you. Or it can be someone else. But someone IS going to do this, eventually. I mean, a lot of this is already being done, just not for WP. A D&D page build is not really anything new. What’s new is having story-centic components and having it play nice in a WP universe. All VERY doable. Heck I’m just above average and I think with some help I could make a go at it – and you’re far better than I am at this type of dev, right? 🙂
Just sayin’ 🙂
November 15, 2014 at 9:27 am
- This reply was modified 6 years, 5 months ago by Mark Simchock.
Thanks for the feedback. I’m not so sure storing all of the attributes in post meta would have any advantages over it’s current implementation, other than the fact that it would then technically be consuming more resources. the post meta table isn’t exactly the most friendly when it comes to large scale applications.
I’ve come across the need once, to access an attributes value from a shortcode, and one of our devs got around it with a regex in TinyMCE.
Regarding a div…a client can break their site with a missing <. You can"t break your site with a mal-formed shortcode. All of this, would be a complete rewrite. We'd also loose the API of the Shortcode that we're utilizing. We'd also loose the has_shortcode function which we rely on a lot. I realize this could be mimicked with individual rejex patterns, but I can't help but think of that old saying, "if it ain't broke, don't fix it." With that aside, we're already looking ahead towards the next big version of Aesop, and we've mostly got our minds made up of leaving TinyMCE because of how limiting the environment is. This, is when we move out of the backend, and into the front of the site. Anyways, thanks again for the feedback! Nick