WordPress

WP Blipper Widget: options

I decided that the OAuth settings for the widget didn’t belong on the back-end widget form after all, but rather on a settings page of their very own under the main WP settings menu. Luckily, I already knew all about adding settings pages, so I set about writing a settings class that would do all of that malarkey for me. I looked at the Rotating Tweets plugin for guidance because it divides its settings up in a similar manner.

The problem that had set me back before, where I had a separate class do the settings, was that I didn’t know how to get the settings from one class to another. When I asked the settings object contained in the class that invoked the Blipfoto API for the OAuth credentials, it turned out the credentials were blank, even though they’d definitely been set and I could see them in the widget’s back-end form and in the database. It seemed that the settings object contained within the Blipfoto API class was not necessarily the same one that had been instantiated at the time of setting the settings. I still had the same problem with this incarnation.

The Rotating Tweets plugin seems to get round it (and correct me if I’m wrong) by not having the settings in a class; instead they are independent functions at the bottom of the main widget file. I didn’t want to do it like that; I wanted them in a class.

I finally realised I could simply ask the database directly, using get_option(). I could see no reason why I had to limit calls to the database to the settings class, although for some reason, it feels a little odd. Once I’d accessed the database directly, I could easily create an API client and hence call any function on the client I desired. Hurrah!

The settings on the widget form are naturally in the same class as the widget display, so there are no problems there.

I used Rotating Tweets again as a guide to getting the settings set with a tick-box (or checkbox) done. Tick-boxes confused me last time because the value is always 1, and if you change it to zero, then that value isn’t added to the settings array and it all goes pear-shaped. I’m not entirely sure now what is going on, but I do know it appears to work, so I’m happy enough.

Update

I’ve wrapped the direct calls to the database from the widget class in a function in the settings class. It seems neater, somehow, although there’s still a niggle that it should be static or something. But I’m sure that’s not right. Is it?

Leave a Reply