Add Form Element – Can't add any, the buttons are only selectable texts.

This is the correct appearance, though when they are clicked they are supposed to add form elements. This would mean there is a problem with the javascript. What browser are you using? Do you have any other plugins installed?

I’m using firefox 3.6.17 with Fedora 14. I also tested it under a virtual Win 7 with IE8. Same behavior.

I have/had qTranslate, that could be probably in relation.
However, same behavior with all plugins deactivated, even deleted, and after clearing browser cash, history, cookies. …

On the server the wp files are write-protected. I can’t even determine if the bug is on server or client side, looks like a compatibility issue.

I try’d also with a wp instance that never saw any other plugins.

.. by the way, the “Insert Saved Form” button seems to be functional.

There is nothing wrong with the appearance you are reporting, that is the way they are supposed to appear, as ‘text links’. But I’m not sure why the insert form button would work while the add buttons don’t. The add buttons use AJAX to insert the new elements, but then, so does the insert. Maybe there is a security setting that doesn’t let text links run scripts?

I just tested the plugin on Safari, FF4 for Mac, IE8 and FF3 on winXP and win7, and the latest ios, and they all function properly. I think the problem has to do with AJAX, since the scripts are running on the editor page in the major browsers. I have no idea of where to begin debugging that, though, since the only servers I have access to don’t have the bug. Is it a multisite installation?

If you go into js/scripts.js, and insert ‘alert(response);’ on line 106, just below ‘jQuery.post(…’, that will tell what is coming back from the server for the add item requests.

Okay, I figured ot what the problem was. My fault.
Actually the whole js folder was told to be under a non-existing URL (some wicked url-path-mix instead …)

I use some symlinks in my configuration, and due to that plugin_basename() did not return the proper path. I could correct that errror simply by placing a PHP realpath function in wp-load.

Strange that other plugins never used the plugin_basename() function.

Thank you for your help. Now I look forward to test the plugin properly.

??

Happy to help. I found a support ticket that addresses the issue of symlinks and plugin_basename(), but it looks like a fix won’t be out any time in the near future. I’m surprised that WP can’t handle symlinks.

wait wait .. ?? …

Since I use the same wordpress folder for several instances, I slightly modified wp-load.php, as I had to insert something that distinguishes between instances, the sites. To achieve the desired functionality I use $_SERVER[‘DOCUMENT_ROOT’], and that returns the entry from the apache config file, which is a symlink.

In clear-text, since we have the possibility of symlinks $_SERVER[‘DOCUMENT_ROOT’] and __FILE__ are not necessarily in the same ‘area’ with their return vaules so to say. They might be symlinked paths across the filesystem.

We can overcome this, with the convention, that we use absolute symlink-free real path’s, eg.: realpath($_SERVER[‘DOCUMENT_ROOT’]).
“Since PHP 4.0.2, __FILE__ always contains an absolute path with symlinks resolved …” so we need to have an eye on ‘$_SERVER’ and other functions that may return symlinks …

.. every day something to learn. ?? …