Forum Replies Created
October 8, 2014 at 8:04 pm in reply to: Unable to load Enfold Demo following WordPress v4.0 update #332662
Christian / Kriesi Team:
I suspect it’s a WAMP localhost or a configuration parameter. If I figure it out (or not) I’ll add another comment to this support ticket. Your attached screenshot with table layout is similar to the demo import and how it’s mapped on my end.
Thanks for your feedback. Enfold v3.0 is top-shelf and so is your support forum.
Tom ROctober 7, 2014 at 8:47 pm in reply to: Unable to load Enfold Demo following WordPress v4.0 update #331882
I tried your suggestion with increasing memory. It had no effect on what I’m experiencing.
I’m scratching my head that with the tens-of-thousands of Enfold customers that the Kriesi team hasn’t heard of this going on with v3.0. I wonder what I’m doing that could be causing the problem. But, again, it’s the Enfold demo data that is mapping the MySQL database so strangely (see my thread above). It happened again with the test of the demo here. In my opinion, something happens during the demo import placing critically important “siteurl” and “home” field data in the wrong places.
I hope someone from the Kriesi team takes a closer look at this. It must be hectic with the release of v3.0 and all.
Thanks, TomOctober 5, 2014 at 8:09 pm in reply to: Unable to load Enfold Demo following WordPress v4.0 update #330535
Thanks for your your reply.
I did two (2) follow-ups. The first one I installed a new WordPress v4.0 instance on my localhost dev platform. Then, I imported a MySQL database from a website that I am going to migrate to Enfold. I installed Enfold v3.0. The result; I was able to generate a homepage successfully.
The second follow-up was doing a the WordPress v4.0 “5-minute install” with Enfold v3.0. I successfully generated a sample page. Next, I did an Enfold Demo Import using the Default Demo. I am unable to run the demo on my localhost dev platform. I continue to get (after a considerable delay ) the “Connection was reset” message. I happened to check the database with the demo import, too. It has a very odd wp-options layout:
- Page 1 option_id 1 has an option _name of “siteurl”
- Page 2 option_id 2 has an option_name of “home”
All other WordPress databases I’ve ever seen have the option_name “siteurl” on page 1 of wp_options in option_id 3 and option_name “home” on page 2 in option-id 39 of wp_options. I believe you have some kind of demo import issue that would affect access wherever the demo site is hosted.
Please look into this further and advise. Your help is appreciated. Your theme v3.0 is otherwise a superb product from what I can tell.
Regards, TDRFebruary 17, 2012 at 12:44 pm in reply to: Fatal Errors Using Propulsion After WooCommerce 1.4.3 Update #64512
Sorry, after I refreshed my screen after sending the 2nd comment, your message popped up. I saved the Permalinks again and the fatal error went away as you suggested it would. Part of the problem I see with WooCommerce is getting use to its peculiarities. I have used other eStore plugins and things like a Permalinks refresh are unnecessary after updating the plugin. So, thanks for the follow-up. The problem is not a problem anymore. TDR :)February 17, 2012 at 12:33 pm in reply to: Fatal Errors Using Propulsion After WooCommerce 1.4.3 Update #64511
In anticipation of having problems with WooCommerce updates would you keep an eye on even the minor version level updates (i.e. v1.4.2 to v1.4.3 and so on) ? Perhaps Propulsion users should give you a heads-up on new updates and not install them until we hear back from the Kriesi team for a “thumbs-up” or “await a Propulsion update” comment. This is the second time just in the recent WooCommerce v1.4.X series where fatal errors are found.
The only way to have a bug-free Propulsion site using WooCommerce after a fatal error like this is to rollback WooCommerce and your MySQL database to the state before the attempted WooCommerce update.
Regards, TDRFebruary 5, 2012 at 5:56 pm in reply to: Maintain Top-Level Menu Bkgd During Its SubMenu Hover #61573
I don’t know why this support thread has fallen through the cracks. It does touch on a useability challenge with the Propulsion theme.
Ordinarily you can depend on a Kriesi theme to have a breadcrumbs feature to augment the main navigation menu. Even the Abundance WooCommerce theme offers it. But there is no such feature with Propulsion. I guess it could have something to do with it being a responsive design and all. Well, Kriesi navigation menus ordinarily do not maintain a background color or other distinction indicating where a user is in the navigation tree. The further down the navigation tree you are the more you’re lost. When site visitors are shopping you do not want them to have a sense of not knowing where they’re at. That’s one of the ways a site visitor gets derailed from the purchase path.
What can be done about this? If a breadcrumbs feature is not practical for a responsive design like Propulsion then, I believe, steps to further illuminate a site visitor’s location in the navigation tree should be considered. The theme’s underline of the top level parent disappears when you going beyond first-level submenu pages. To start with how about some suggestions to keep the top-level parent highlighted throughout their respective submenus?
Kriesi and Team:
The v1.2 update is installed, tested, and it works with WooCommerce v1.4.1. Thanks for the turnaround. :)
Maybe four (4) Propulsion users should be enough to confirm these missing arguments. I upgraded to WooCommerce v1.4.1, too, and the problems voiced above showed up immediately. The other problem as noted by blyerts is there’s no rollback scenario so it would seem ANY Propulsion user’s site will be affected until a fix is provided by Kriesi.
These argument errors look like they will be presented on ANY Propulsion site upgrading WooCommerce to v1.4.1. I have a localhost site running the Propulsion demo data. Following the WooCommerce v1.4.1 upgrade (running Propulsion v1.1.0) the same argument errors popped up as mentioned by all in this support thread.
Still, I am able to add products to the cart and go through a checkout but my site visitors (via Google Analytics) are almost unanimously dropping off once they reach the affected product pages. Hope Kriesi can turn this around ASAP. It’s costing us.
Regards, TDRFebruary 2, 2012 at 9:40 pm in reply to: Maintain Top-Level Menu Bkgd During Its SubMenu Hover #61572
Haven’t heard back from anyone so I’m sending this heads-up.
I thought I’d get your thoughts about the menu system, too. I’ve been developing with Propulsion for a couple of weeks. I like it a lot. With all the styling touches Kriesi adds to his themes I find the dropdown menu that appears in the smallest resolutions to be out-of-character with his usual creativity. Honestly, the vertical menus in Theme Blvd’s Swagger Responsive theme or their Breakout theme on Mojo Themes are so much more in keeping with what I’ve seen with the style of Kriesi’s themes. Please consider some enhancements to the menu system. That said, the theme is solid.
Please provide some thoughts on my original question.