On the twenty seventeen theme if you have a un-ordered list and you use your editor siteorigin-editor it pulls in the themes .widget ul li class underlining everything and it shouldn’t do that. If I replace the siteorigin-editor to you html editor and just copy my code over the issue goes away but then the google translator from jetpack will disappear if you add the wordpress text widget instead all the issues are resolved. siteorigin unnecessarily stores way to much information into my database I’m 80% done now so I’m stuck with it but its quadrupled its size all with entries from siteorigion and there is no way to tell if you or how your verifying these entries into the database are there even cross checks being done. Its very heavy and high in resources timing out your php from time to time. some of your widgets display contents in only rows without proper columns such as siteorigion features. I installed this plugin to save time and honestly it has cost me more time than it has saves and I could have built the entire site without it by now. Very buggy very heavy high utilization way to many entries into the database Also if you have applied custom CSS to your widgets and then add one more later all your widgets and rows etc end up with new ID’s because your using a time stamp method that is not a good choice by the way. Also some of your widgets bleed your styles outside of the delimiters of the widget itself. what is right with the plugin? I find no less then 5 more issues with it daily. Your even using fairly common classes that conflict with basic themes.
site origin is having more than one issue
This is our free support forum. Replies can take several days. If you need fast email support, please purchase a SiteOrigin Premium license.
Hi Domenick,
You can prevent the widget class from being added to widgets by navigating to WP AdminSettingsPage Builder. Open the Widgets tab and untick Add Widget Class. The widget class is added by default for consistency with themes.
The Custom HTML widget is a standard WordPress. We don’t make any modifications to this widget so it would appear the Jetpack Google Translate functionality isn’t compatible with that widget – this is likely intentional on Jetpacks part.
Each SiteOrgin Page Builder post will have one post meta which is where the data is stored. Each revision will also have this post meta to allow you to restore SiteOrigin Page Builder data using the standard WordPress Revision functionality. This data is required to be stored like this due to technical limitations imposed on the standard WordPress content field. No other data is added for pages/posts.
Consider clearing your revisions (you’ll need to use a plugin to do this) or imposing a limit of the number of revisions allowed per post as that will cut down on all data associated with revisions which are where the bulk of the data is.
It sounds like your reaching your hosting plans general resource limits. By default, most websites will have a very low memory limit (typically 32MB or 64MB) and it’s highly recommended you increase this amount as only a very basic WordPress install will be able to be used with that amount of allocated memory. WooComemrce (for example) recommends at least 128MB of memory but ideally 256MB – we agree with those recommendations in general and it’s highly recommended you increase the memory limit to avoid these sort of issues.
Increase PHP Memory – WPBeginner
If you would prefer not to use the SiteOrigin Features widgets columns, you can add one SiteOrigin Feature widget to a standard SiteOrigin Page Builder column and repeat this for the rest of the columns you wish to add them too. This widget was built with a custom column system to ensure ease of use and cut down on editing time.
It’s recommended you either set a row/widget id or class instead of use on automatically generated ids as those ids are intended to be used internally by the plugin. These ids aren’t based on timestamps and are instead based on row/widget placement so making adjustments to placement of rows and widgets can result in this id changing.
Can you please provide an example of this? We haven’t received any other reports this so we really need more information. We would highly appreciate a link to where we can see this issue as that will allow us to investigate this issue directly.
I am not reaching my plans limits by any means I have my own solid state farm that is PCI compliant. Disabling the widget class makes sence to me.
It doesn't address the reason you use the time stamp for your ID's I use my own CSS sheet and so it doesn't bother me much most individuals however using a site builder are not going to know how to do this correctly and may loose allot of work when adding in a new widget at a later time. I typically don't use WordPress it just happens that's what my client is used to. There is just to much of the unnecessary. Like a script for every plugin etc and if it doesn't get placed in the right order creats issues so on and so on. Building this on my own platform I would have no need for a database this side it's rediculas. It can create migraty issues for the untrained as well. Most providers cap there databases at 1gig and they would need to know how to trim the fat I would say. We also didn't address the CSS bleeds. I understand you want people to use your product however your product is better suited being utilized when needed and allowing the use of the word press plugins over your own. Your own being an option when needed. For example what purpose is there to using your editor widget instead of the WordPress one? I would default to there's unless needed. The easier it is to use for your end user the better off it is sometimes less is more. I used a :not statement to prevent the class conflict. A simpler solution would have been to just have that class called origin-widget instead just saying. Thanks for the quick response however and sorry for my frustrating remarks.
I do wish I new of that setting in advance I'll go and remove my review of your product because of your quick response and addressing some of my concerns
Hi Domenick,
Thank you for confirming your setup. Hitting the memory limit is a common cause for timeouts so that’s why I suggested looking into that. Based on your setup though, it’s unlikely that’s causing it. WordPress, by default, limits any sort of real information about errors but that can be changed by adjusting a few settings. Can you please edit your wp-config.php file and set WP_DEBUG to true.
Then add the following PHP after WP_DEBUG line:
For information on the above configuration options, please refer to this page. The next time an error occurs, if it’s related to PHP a record of it will be included in your WordPress debug.log file which is found in the wp-content directory. If this file isn’t present, there hasn’t been a PHP error yet.
Each row, cell, and widget will have a custom id generated based on the row id, cell id, and widget id. These ids will change based on the placement of where the row/cell/widget is on the page. These ids are not based timestamps and will only change if the row, cell, widget placement is changed for that specific id.
We don’t directly mention that you shouldn’t use the automatically generated ids so I’ll reach out to Andrew and he’ll add a note about this in the documentation.
Are you using a minify plugin? I ask as you shouldn’t need to worry about when our assets are output as WordPress will automatically handle that. If you are using a minify plugin, unfortunately, this is unavoidable as minify plugins typically don’t use the same ordering as what WordPress uses so you may need to reorder things to get them to minify correctly.
Can you please elaborate on this issue? We haven’t received any reports of this issue so we’re not too sure what issue you’re specifically facing. Ideally, an example of this issue would be much appricated.
We offer more control and provide additional functionality than the base WordPress Editor.
I’m sorry about that! We’ll look at ways we can better expose users to this setting.
This setting was introduced to allow for better consistency with themes. We’ve found a lot of themes include widget specific styling and make use of the widget class to apply this styling so without widgets without the class could potentially have vastly different appearances when compared to widgets added to the sidebar. Does that make sense?
That's simple it's 3:15 here and I haven't went to bed so it will need to be in the morning sometime habe a good night guys.
Yes you do offer more functionality but is that a choice you need to make for your users or for them to make? I would imagine allot of your users perhaps don't know what to do with that functionality lol
Either way my opinion is just that mine and I'm sure you have your reasons as well I was always tought there are more ways than one to slice a cake ?
I'll get back to you guys with more information to go off of. How did your update for gitterbug go? I personally don't use it I think it should be called gutterbug lol
Hi Domenick,
We provide our users with the tools (ie. functionality) and it’s up to them to decide how they use them or even if they use them. We outline how to use the functionality in our plugins documentation:
Page: Getting Started With Page Builder
Page: Getting Started
We’ve also intentionally designed the SiteOrigin Widgets Bundle around the idea of all widgets being completely optional so users are able to deactivate any widgets they do not wish to use.
We prepared extensively for WordPress 5.0 so there were very few overall issues as a result of the update.
We’ve introduced two blocks that will allow users to use our plugins inside of the Block Editor (ie. Gutenberg).
The SiteOrigin Layout block is the full SiteOrigin Page Builder interface in block form.
The SiteOrigin Widgets block allows you to add SiteOrigin Widgets Bundle widgets directly to the block editor.