Tonight, trying it on a new site (with a slightly flaky server) I received a fatal error when I tried to activate the plugin. No other message, just ‘Fatal error’. I tried again and it worked the second time. Thought I’d mention it in case it helped anyone else.

Apache version 2.2.15
PHP version 5.2.13
MySQL version 5.0.92-community

Glad it worked out Rob and thanks for the information on SSL. Now I will know what to do when I need to set up SSL pages. 🙂

Shiba
THANKS! The second option worked. (although I found that line of code on line 159)
Anyway, for SSL, all you need is to have all relative or fixed URLs, or if the URLs are absolute, they need to use the HTTPS protocol. Then of course you need the certificate properly set up, but in terms of a page’s links/URLs, it’s that simple.
Thanks again!

Hi Rob,
#1 can be done but it will be a relatively big change. I will need to alter all the URL constants and replace it with a function instead. Also, testing would be an issue since I don’t run any SSL pages.

I will add it onto my to-do list but I likely won’t get to it for a while.

To do #2 edit the shiba-widgets.php file. Go to line 218 –

wp_enqueue_style('shiba-widgets', SHIBA_WIDGET_URL . '/shiba-widgets.css');	

Remove the constant SHIBA_WIDGET_URL and just put in the relative file path. Not sure if this will solve the SSL issue since I am not familiar with SSL coding.

wp_enqueue_style('shiba-widgets', '/wp-content/plugins/shiba-widgets/shiba-widgets.css');	

Alternatively, you can also hook into wp_head and add the css styles functionally with something like this –

add_action('wp_head', 'widgets_header_style');
function widgets_header_style() {
?>
/* add css styles here */
<?php
}

I am now implementing ecommerce with secure transaction on the same site that I’m running Shiba custom widgets. I am running into a problem where the page is not 100% SSL secure because the Shiba style sheet is loading into the header with “http” instead of “https”. This gives the user a warning that not all page elements are secure (not good).

So I have questions and requests…

1) Can you make an update that will auto-detect whether a page is “http” or “https” and then have it write the appropriate absolute URL? That way the shiba plugin and css file references will also be encrypted SSL. I noticed some code that does this in the ecommerce plugin, maybe you can borrow from their methods, let me know.

2) Or is there a quick way you can show me to edit the plugin to make the shiba links and references relative, without the full absolute reference of “http” that way they are relative and will be encrypted.

#1 method is probably best for your plugin in long term, but I will settle for any quick fix that I can implement now. I wish I knew PHP, maybe I could figure it out myself. Any help is greatly appreciated!

PS: Let me know if the fix is easy to implement on other plugins as well, because I have another activated plugin causing the same issue and I need to either fix it myself or contact the development company.

Thanks!

Glad it worked out Rob.

Yeah I am thinking of turning off the propagate since it seems to only complicate matters. It is useful for my own purposes, because I have certain text widgets that I want shared across multiple widget sets and I don’t want to have to edit each and every one of them every time I need to do an update.

Good luck on your launch tomorrow!

So far so good. I think the propagate feature was my issue–I just did not know what that feature was for, how it worked, or how to use it.

Here’s I did … I did not re-install (running v 1.2.2 already), but I deleted all my widgets, deactivated Shiba, dropped the Shiba mySQL tables, commented out the propagate lines per your suggestion, then activated and started building my widget sets from scratch again. So far so good. Will be done tomorrow hopefully with no further issues.

Again, THANKS SO MUCH for replying on a Sunday! You’re awesome.

For future, I have some improvement suggestions:
– Propagate feature should be off by default
– It should be explained more clearly exactly what it does in the admin interface, and perhaps a warning.
– In options, perhaps a method/button/script to “turn off all propagation” in existing widgets, even if some are currently checked on. This would fix the problem and make all widgets standalone and unique at their present state (in theory).

I am not sure of the usefulness of the propagation feature in general. I love your plugin because it allows me to create completely unique sidebars/widgets on every individual page if I need to. The propagate overrides the uniqueness, which kinda goes against the nature of the plugin IMHO. I think this is what confused me to start. That’s why I said it should at least be clearly defined/explained and maybe have some warnings built in.

Still love it, and thanks again.
Rob

Sorry, started to say, if I still have problems, I wouldn’t mind you logging in.

I just tried editing some widgets and unchecking “propagate” and on some widgets, I uncheck propagate, then click “Save” and the check comes back immediately. I can’t get rid of the checked box!

I guess I’ll try commenting out the propagate feature–especially since that goes against my whole purpose which is different widgets on every page.

I’ll be back with news.

I am running v1.2.2 according to my plugins panel. Is that the latest? Please let me know.

The propagate feature confuses me, what does it do exactly? If I understand correctly, that might be the issue because all of them are turned on (checked). I will go through and turn them all off nad redo them and see and test further. I have a lot of work to do…about 30 widgets.

Some of the widgets may have been created before the latest upgrade, most most afterward I think.

I’ll let you know what happens.
Thanks.

If I still have problems,