Forum Replies Created
-
AuthorPosts
-
August 28, 2013 at 11:35 am in reply to: Genesis 2.0.1, Yoast SEO, category headline and archive settings do not save #59249eric1508Member
Sure thing Mark. Glad to help out and ultimately keep Dynamik as bug free as possible. 🙂
Eric
August 27, 2013 at 6:02 pm in reply to: Genesis 2.0.1, Yoast SEO, category headline and archive settings do not save #59137eric1508MemberHey Mark,
This was in fact a Dynamik bug that cropped up with Genesis 2.0.1. Gary just pointed me to the Genesis change that triggered the bug and I've since fixed it and will be pushing out a Dynamik update soon. Sorry for any confusion with this and thanks for providing all the info to help us get to the bottom of this.
Eric
eric1508MemberHey anitac,
I do appreciate you taking the time to direct people our way if it looks like they're having a Plugin issue and I certainly don't have any expectations for you to provide any personal support, though I appreciate your desire to help the end-user resolve their issue either way.
Having said that, it appears you don't quite understand what I'm saying here. In this particular case, for example, if you were to suggest that they de-activate the Plugin, see if that solves their issue, and then use that as a way to determine whether the Plugin is the cause of the problem then you're missing my point. If, like in this case, it's the end-user's Custom CSS that's causing the issue, and by de-activating the Plugin they are de-activating the Custom CSS that's causing the issue, they're getting a "false positive" with regard to thinking it's the Plugin that's at fault.
A better direction would be to suggest that the end-user backup their Custom CSS (this is a simple mouse click in Extender Settings > Import/Export) and then temporarily remove all of their Custom CSS and re-test the issue. Chances are they will see the problem go away and then they can just re-Import their Custom CSS and then remove various sections until they find the styles that are causing the issue.
Or alternatively, they can just post their Custom CSS into a thread on our support forum (linked to in my previous post), letting us know what issues are being caused by it, and we'd be happy to help determine what tweaks to make. But really, at that point we're not talking about "Plugin support", but just general CSS/HTML/Responsive tweaks between the Child Theme and the Custom CSS added by the end-user. But like you guys, we're always happy to assist where ever we can.
But just to reiterate my point, Genesis Extender only adds a few styles to the front-end of the site and none of these styles should have any effect on the Child Theme itself. So if styling issue are reported and Genesis Extender is a part of the equation than most likely we're dealing with Custom CSS added by the end-user through the Genesis Extender Custom CSS tools, not the Plugin itself.
Eric
eric1508MemberI'm actually the developer of Genesis Extender and I wanted to mention two things.
First of all, if anyone does find what seems to be a bug or conflict between Genesis Extender and a Genesis Child Theme by all means email us as linked to by anitac.
Secondly, regarding:
"I have had several people email me personally about using that plugin and it’s the plugin, not the theme."
I just wanted to point out that this particular issue and most likely the others noted by anitac came about not because of the Genesis Extender Plugin itself, but because of Custom Styles implemented by the end-user THROUGH the Plugin's Custom CSS feature.
So to say that this is a Plugin issue is not an accurate statement as the Plugin has no control over what kinds of Custom Styles the end-user implements through it's styling tools.
So by all means we're eager to refine and fix issues and conflicts as they come about, but I think it's equally important to clarify when something is not actually an issue with the product and just needs some clarification as to where to be careful when customizing your site using it.
And as I mentioned, if a potential issues does arise you can either contact us via email or even better, you can post your questions in our support forum where our support team will be happy to assist.
Eric
eric1508MemberWe really didn't officially "announce" it anywhere, in terms of promoters or other websites. We instead pushed it out first to our own community of Catalyst and Dynamik members who have since spread the word through various means. You could say it's been a bit of a grass roots effort. 🙂
We do, however, plan on pushing promotion of it a bit more down the road.
Yeah, it's funny because even though I myself can hard code all the bits that Extender does for me, I still prefer to have it done for me. It's just a lot faster in terms of work flow for me, but I totally understand how many coders would prefer to just code things themselves. And yes, our biggest target market are those non-coders who like the control and flexibility of something like Extender where they're not tied to their developer when it comes to doing fairly common design and structure customization on their websites.
Eric
eric1508MemberAs you know, with anything that is written with code that interacts with other code and runs on hardware that interacts with other hard ware you run the risk of having something go wrong and then dealing with the domino effect of a possible crash or down time of some kind. Whether you're dealing with Themes or Plugins or WordPress itself. And of course once you add the imperfections of human interaction you're dealing with a ticking time bomb. 🙂
So of course there are always concerns with trying to keep things up and running and fully functional 100% of the time, but there will inevitably be some glitches. But for the most part they are few and far between and when they do arise we are 100% behind help resolve them, especially if they are the result of something needing adjustment in our own code.
I would say the vast majority of update situations (whether with WordPress or the Genesis Framework) are not going to cause any issues with Genesis Extender and generally we catch things that might as we beta test both WP and Genesis before they release to the public. But when they do occur we're on it.
To give you an example of this, the one thing we missed with regard to one of the last Genesis updates was their changing of the way they call in the stylesheets for Child Themes. So when the Genesis update came out the Genesis Extender Custom Stylesheet ended up being called in above the Child Theme's stylesheet instead of below it like it should be, meaning that some of the Custom Styles that had been implemented by the user were no longer overriding the default Child Theme styles.
We caught this the day this Genesis update was released and pushed out a fix within 24 hours.
The funny thing was that a day or two later another Genesis update was pushed out with the note that it was to fix an issue with the way the previous update had changed the way stylesheets were being called in, which was causing issues with some Child Themes.
So in this case it was the Genesis update that partially caused the issue and not only was Genesis Extender affected, but some Child Themes as well.
So this is all just to say that stuff happens, and that's not 100% preventable, but who's behind the product and their track record of staying on top of that "stuff" is the key. And in my example I just showed that both Genesis devs and our team are fully behind the Themes and Plugins we produce.
Eric
eric1508MemberHey Keith,
That's a good idea, but the implementation would be tricky. Not only am I not sure of a "clean" way to focus that specific functionality onto the Genesis Extender "Deactivate" link (though I have some ideas), even if it was properly implemented it would not account for a "Deactivate All" action that could just as easily be taken in deactivating Plugins.
Eric
eric1508MemberHey guys,
With regard to manually transferring code from Genesis Extender to the Child Theme itself this could certainly work and most of the customizations are hard coded and located in the /wp-content/uploads/genesis-extender/plugin/ directory.
So yes, this is certainly a possibility, but I'll have to look a little closer and see what the best ways of doing this might be. I've even considered adding a "Code Creation Only" settings or something like that where you could just use Genesis Extender to create the hard coded files, but not actually take effect, allowing you to copy/paste directly into your Child Theme, but this is just in my head at the moment. But I've added this to my "List" for potential future additions.
Thanks for all the feedback thus far. 🙂
Eric
eric1508MemberHey Joseph,
I hear ya! 🙂 Yeah, as I mentioned it's kind of a catch-22 since one of the key characteristics of a WP Plugin is that it "goes away" when it's de-activated, but one of the huge benefits of Genesis Extender comes by way of being a Plugin (i.e.. being able to work with any Genesis Child Theme).
But like I said I'm open to looking into possible future solutions if a viable one comes along.
Eric
eric1508MemberHey guys,
I'm actually the developer of the Genesis Extender Plugin and one of our members pointed this thread out to me in our forum so I thought I'd stop by and see if I could address any concerns you have.
First, know that Genesis Extender, though fairly mature in its development in terms of refinement, is quite a new product (currently at v. 1.0.2) so there's plenty of room to grow. So even if there are things that you would like to see refined or expanded upon there's a good chance that they will be in the future.
But for the most part I just wanted to introduce myself, let you know I'm happy to answer any questions you might have about the Plugin and hopefully clarify any concerns that may be keeping you from exploring it further.
Regarding the concern about what happens when the Plugin is de-activated. Yes, if you de-activate Genesis Extender then anything the Plugin was affecting (ie. Static Homepage Widgets, Custom Content Areas, Custom CSS, etc..) will, at least temporarily, disappear. I say temporarily because the settings and files will still be in place so once re-activated everything should return as it were before the de-activation occurred.
Now I understand the concern here, but the reason behind this is that this is just the nature of Plugins. They are supposed to "go away" when they are de-activated and this is how Genesis Extender acts. But of course without it being a Plugin you wouldn't have the HUGE benefits of being able to use it with any Genesis Child Theme.
Having said this, we can certainly look further into the possibility of providing an option that keeps the affects in place, even after the Plugin is de-activated or maybe a way to "lock" it into place to prevent clients from causing issues, as one of you noted in their concerns. But that's not something that is currently in place, of course.
What I can say for sure is that the majority of people who use Genesis Extender find it to be a huge time saver and a must-have tool for their Genesis powered websites. 🙂
Eric
-
AuthorPosts