October 29, 2014 at 7:32 pmParticipant
fyi => On this page: https://aesopstoryengine.com/developers/
“Universal Aesop Theme Hooks
Aesop add-ons and Themes are entirely modular. This means that all of the add-ons work with all of out themes.”
I’m guessing it’s “our themes.” not “out themes.”
=> same page as the typo above.
Section: Load Extended CSS Support
I have to be honest, ya lost me here. Is this one useful after using Deactivate Styles? That is, there’s no way to turn off individual styles, so you have to turn them all off, and then select which one you want back on?
=> Did I miss skim the code or is the component-gallery not plugable?
=> component-collections (.php) -> ~line 121
<p class=”aesop-collection-meta”>Written by <?php echo get_the_author();?></p>
Maybe the “Written by” shouldn’t be hardcoded?
=> I’m curious, is there a reason the components aren’t classes? My thought / wish being that inheritance would be an easier more natural way to make changes / customizations. I mean, even if I had to make a copy and then extend it, at least then, if that component updated it would be more possible to just replace the parent class and hope it still worked, but at least it would be a start. On the other hand, now if the original class gets updated I have to sort out how I might have to refactor. Kinda? Sorta? I hope I don’t sound like a critic. I’m just fond of inheritance as a way to make “stuff” more customizable for others.
=> Moi? I think I might consider recommending people use mu-plugins for storing customizations. Granted, if the customizations are theme specific but if they’re developer / team decisions then not “hiding” them in each theme kinda makes better sense, I think. Maybe? Such an approach might be able to create an after-market for ASE components. That is, “Here ya go Nick, my Parallax module does Y and Z instead of X.
Well, thanks again for listening. I’ve got more ASE reading to do 🙂
p.s. Nick I like the new editabilty of the shortcodes but I was thinking the properties would be decoupled (?) from the actual shortcode. For example, the shortcode would be only [ase ase_id=”some-unique-id]. That’s it. No values in the shortcode itself.
Then below the WYSIWYG there’s a post meta with a list of the various components I’ve setup with the properties and the editing being done there. So the shortcode has the unique_id which then goes to the list to get the value it needs to render that shortcode. There could be post specific shortcode. But also shortcode – via an AJAX search? – that could be user across any / all posts.
The shortcode is simply the “key” and where. Everything else is in the DB. Does that make sense? If not, let me know and I’ll try to explain again.
p.s. #2 – Yeah, I know, you’re just getting started. Pardon me if I’m being pushy. Sorry. 🙂October 30, 2014 at 10:56 amParticipant
With regards to the p.s….
What I think I’m suggesting (over the longer run) is that the components properties become json and all the component “construction” is done client-side, tho’ server side could still also be available..
Now the shortcode is nothing but a placemarker with a unique id. That shortcode becomes a div or a span with a data-attribute for the ase_id. That id is picked up client side, along with the json and the markup magic is built from there.
I think in a WP API world this makes a lot of sense. Heck, it might even be possible to skip the shortcode and just insert the div / span into the_content. Furthermore, once things move beyond / outside the WYSIWYG, this also still makes sense. This is more or less independent of the_content. In fact, the brunt of this is probably transferable to just about any CMS. Maybe? 🙂
Note: I’m not saying this approach is easy. Not at all 🙂 But it does make more sense, at least to me 🙂November 5, 2014 at 10:51 pmKeymaster
Hello again Mark! I have corrected the typo and added a line to the extended css support to provide a bit of info on what it’s used for.
I’ll bring the rest of this to Nick’s attention. Thanks!