Hi, geradt.
I am developer of this plugin.
If you are satisfied, please tell me the other plugins that are installed.
Thanks.
Thread Starter
geradt
(@geradt)
Hi Takayuki,
Thank you so much for replying. Here are the other plugins that I currently have installed, please review them and let me know if you think any of them are causing the issue:
TinyMCE Templates
Wordpress Wiki FAQs
WP-PageNavi
WP-PostRatings
Askimet
That’s all I have running on the site at this time.
I create a template and save it and make it shared. Then I go into a new post click on the button and it displays the template popup lightbox, but the template list dropdown is empty.
Any help you can provide would be GREATLY appreciated.
Thanks,
Geradt
Hi geradt,
Unfortunately, it seems not the cause of these plugins.
Please try below in WordPress Admin.
- Open [Settings] – [Permalinks]
- Click [Save Changes]
If you’ll tell me the URL, I might be examined in more detail.
Thanks 🙂
Hi,
I have the same problem. I’ve pinpointed it down to the login check in TinyMCETemplate::get_templates() which fails invariably.
What really confuses me, however, is the fact that on my clean install, it works just fine, while my dev install (with no plugins, but quite some customization through the theme’s functions.php) it breaks. Rewrite rules aren’t the problem, the AJAX request always goes through… but the login variables aren’t populated properly.
Hi kernfel,
Please try to install below.
http://firegoby.theta.ne.jp/downloads/tinymce-templates.zip
Please tell me if you solve the problem.
Thanks.
Huh. Now the AJAX request returns a full HTML doc, i.e. the frontpage.
As a workaround on 1.2.1, one could always suppress the login check, though then, only shared templates show up, of course.
Oh, maybe looking at what you actually changed would help.
Since authentication appears to fail for whatever reason, is_user_logged_in() returns false as well, so get_templates() returns without exiting => hence the request trickling down into WP’s usual output.
I can’t fathom what causes login/authentication to fail – I can see the auth_cookie_malformed action is being called, but I don’t know enough about the authentication process to get what that means, and how to fix it.
Hi kernfel,
Huh. Now the AJAX request returns a full HTML doc, i.e. the frontpage.
Oh, Sorry!
But, I don’t know.
Why is_user_logged_in() return false when you open WordPress Admin.
Let’s examine it a little, please wait.
Thanks 🙂
Hi kernfel,
Sorry, I looked at many. But I did not know the cause. 😉
Pease tell me below.
- your permalink structure.
- is multisite?
Permalink structure: customized, but the plugin’s rewrite rule is right at the top of the list and in full swing.
Multisite: No.
I thought it might be connected to the fact that I’m currently protecting WordPress’s base directory with .htaccess, so I disabled that, upon which the request didn’t even get passed through any more. Putting it back in, I’m getting proper WP user auth (although auth_cookie_malformed still fires) and, as far as I can tell from my debug logging, the data should be passed out properly.
… but of course, as if such magical changes in the authentication behaviour weren’t enough, the template still isn’t displayed in the popup.
Screw this. I’ll keep digging tomorrow if I get a chance. I really want to make this work, and if it means rewiring the requests to admin-ajax.php. Your work’s much appreciated, I hope we’ll find a way.
Ah, I get it.
Since I’m working on the site every day, I always leave a /wp-admin tab open in Firefox. Now, what apparently happens is that the wordpress_logged_in cookie, which is set to /, expires. I can still move around the admin interface, however, because there’s the wordpress cookie set to /wp-admin which persists or is set again as Firefox loads the tab.
But since the plugin’s AJAX request is to /, the wordpress cookie isn’t sent along, and login fails.
This means there are two ways around it:
1) You tell users with this problem to log out and log in to /wp-admin again. The wp_logged_in cookie is set on /, the plugin’s AJAX requests log in, everything’s fine. Or
2) You rewrite the plugin to send its request to /wp-admin instead – most sensibly to /wp-admin/admin-ajax.php to do it “the right way”, if I may be so bold.
I’ll stick to (1) for the moment, but I’ll see if I can’t sneak in an hour or two to write and test (2).
Hi kernfel.
It is very interesting about WordPress’s Cookie.
I will challenge some idea for fixe this problem.
Very Very Thanks! 🙂
