Dzikri Aziz

Thanks for the reply Otto.

That’s the problem, I don’t know where to look for what may block it ?? The only ‘weird’ thing in my apache setup is that I’m using DYNAMIC_VHOST instead of DEFAULT_VHOST.

And yes, the plugin works, but there’s another problem I forgot to mention;

I activated the publish module, and even though the plugin says I’m logged in to twitter with my username printed, it still asks me to authenticate for auto-tweeting (already I gave the permission and twitter redirected me back to the setting page).

Is this normal with local server?

Hi,

I’m not the plugin author, but I think this is the expected behaviour of the current state of the plugin. It doesn’t support child pages yet, so it would set the orders in one level only.

On the other hand, to get what you need, you will have to set the child pages orders completely separated from the first-level pages, so ‘General Settings’ should be set to 0, and ‘Activate bbPress…’ should be set to 1.

HTH, and for the plugin author, please correct me if I’s mistaken ??

Could you paste here the code you’re using?

Thanks.

Oh, I forgot to mention…
I will add the check for Widget Logic in the next update. Thanks for the code ??

@hallmarc

Thanks for the info. I actually have a working version my plugin with ‘widget logic’ builtin. However, I don’t feel comfortable releasing it to the public because it’s using eval() (just like the original Widget Logic plugin). A commenter on my blog said that I shouldn’t worry about that because the widget settings can only be modified by admins and they should know what they’re doing, but alas…

Anyways,
My implementation of the logic will be a little more complicated to code but should be easier and safer for the site admins since they won’t need to enter WordPress’ conditional tags. I’m still working on my KC Setting plugin improvement (making it easy to create settings without editing any file) and should start the work on KC Widgets Enhancements when it’s done.

Well, if you take a look at the term.php file, you’ll see that I used a pretty standard WordPress way to create the table, which I got from the Simple Term Meta plugin and confirmed by the Codex.

Surely I’m no expert with SQL, but I’ve experienced this behaviour in WordPress and other PHP apps using MySQL (different collation for different table) when the database was not originally set to utf8. This could be the caused by (among other things) the operating system the database runs on (I’ve experienced this with my Gentoo Linux before I moved the whole system to utf8).

Yes, this is a known issue and I’ve mentioned it in the release announcement on my blog (I will add this to the plugin description on the next update).

I’m working on my own ‘widget logic’ implementation and hopefully I can include it in the next plugin update.

Hello,

Unfortunately I cannot reproduce the collation bug. Every tables created by the plugin is UTF-8. Perhaps your database’s collation is latin1_swedish_ci?

If you’d be so kind, please go to your PHPAdmin page, click the database and then click the Operation tab. On the bottom of the page you’ll see the database collation. If it’s set to latin1_swedish_ci just change it to utf-8 and save the change. If not, please let me know.

If you changed the collation, you can delete the termmeta table and reload the Term editing page and try entering the Serbian letters and let me know the result.

Thanks.

The conflict was caused by datepicker css. KC Settings always loaded the stylesheet even when it’s not needed. I’ve fixed this and you should see update notification in your dashboard shortly.

OK, I found the bug, will push the update in a few moments. Thank you for reporting this, much appreciated!

Hello,

In which admin page(s) does this conflict happen?

Hello,

I’m sorry it took me so long to realize that I forgot to subscribe to my plugin’s support feed. I just added some new features to the plugin and will bump the version in the repo soon. The update should also include screenshots.

Viper,

I throughly check the plugin with firebug. Turns out it’s not working correctly because you’re still using the deprecated js_escape() function AND I have WP_DEBUG set to true. I changed it to esc_js() (at line 148) as the debug message suggested and it’s now working as it should.

Thanks again for the great plugin and quick response. You may want to update your plugin though ??

Sorry for the delay.

No, nothing at all.
I just check the page with firebug and it throws an error:
unterminated string literal
$("#message").html("<p><strong><br />\n

Try clearing your browser’s cache so it download the newly edited stylesheet and then refresh the page ??