[desc]:I use the same WordPress folders for multiple WordPress sites using a variation of Stephen Rider's multiblog solution (see http://dpotter.net/Technical/2007/10/multi-blogging/). As a result, any changes to plugin files specific to one site mean I can't use that plugin for other sites. Is there any way to avoid requiring the change to the wp-content\\cforms\\js\\cforms.js file? Currently I must add /Test to the beginning of the sajax_uri variable which means the plugin won't work for a site at the root or at another virtual directory.
Bummer. Okay, thanks for the ideas. Too bad there's not a way to get the root of the site in the Java. If tht could be done the variable could be set the fully-specified URL.
I'm actually just in the process of deploying cforms across my sites. I have sites at different levels – some use a top-level host header (e.g. dpotter.net) while others use a virtual directory (e.g. dpotter.net/Technical. All of them use the same directory – similar to WordPress MU. What I'd love to be able to do is deploy cforms across all my sites whether they're at the top-level or a virtual directory, whether they're using WP or WP-MU.
You mentioned in your first response that I could use an if statement. I'm pretty good with PHP on WordPress but not JavaScript so I'm not sure what is available. In PHP the site URL is readily available but I don't if the same is true in JS.
Thanks for your help. I really appreciate it. David
One more thing I'd like to mention to better support WP-MU and multi-blogging solutions. It would help a lot if the path and/or URL to directories containing site-specific data (if any) could be specified in the admin UI.
I know that quite a few users use cforms on their WPMU blogs (there should be some threads in here).
Site specific is only crucial when looking at Ajax. In Javascript you can easily obtain the current URL / HOST / PATH which could be used in js/cforms.js to make decisions e.g. on which key to use for which site.
Other than that I'm not seeing any issue.
It'd be great if you could actually show me two URLs/sites where one is working and the other is not. Based on that I could easily identify the actions that need to be taken.
It'd be great if you could actually show me two URLs/sites where one is working and the other is not. Based on that I could easily identify the actions that need to be taken.
I have cforms deployed on two sites righte now, one on which it works (a virtual directory) and one on which it doesn't (the root). Both are on different WordPress directories hosted on IIS.
It seems that your ROOT directory for Wordpress is /Test. cforms tried to auto-adjust its settings accordingly, however if you still encounter issues with Ajax (form submission & CAPTCHA reset) please open the file js/cforms.js in your cforms plugin folder and check the sajax_uri variable. (After changing the file, please emtpy your browser cache!)
I tested out sending of email before making the suggested changes and it hung displaying the "One moment please…" message. Once I modified the file as specified (adding /Test to the beginning of the sajax_uri variable) it started working.
DOESN'T WORK: The other site is http://www.supersimplebudget.com/contact/. This site is virtually identical except that it is at the root. I also did not get the message and did not modify the sajax_uri variable.
Note that I'm hosting these sites on IIS which means I had to make the following configuration changes:
Installed Ionics Isapi Rewriter to get rid of index.php in the URL. I tested with the rewriter enabled and disabled with no success on the second (root) site.
SMTP enabled. The SMTP configuration is identical on both sites. I also installed the Configure SMTP plugin by Scott Reilly. I tested with this active and inactive but had the same results.
I really appreciate your help on this. Sorry if this seems like a detour. I've looked at many of the posts related to the "One moment please…" message and the only thing that worked was to add the virtual directory name part (/Test) to the sajax_uri variable. Obviously this won't work on the root site.
I had encountered the same problem as you, and I tweaked the code in cforms/cforms.js (see below) and it worked like a charm with my multi-blog usage of cforms with ajax. Try it and see if it helps.
// ONLY in case AJAX DOESN'T work you may want to double-check this path: var path = document.location.href; var sajax_uri = path + '/wp-content/plugins/cforms/lib_ajax.php';
…and if "path=.." doesn't work, you could do the same with an IF clause, eg:
if ( document.location.href.match(/^Test/) ) var sajax_uri = 'Test/wp-content/plugins/cforms/lib_ajax.php'; else var sajax_uri = '/wp-content/plugins/cforms/lib_ajax.php';
I'll try these, but what's interesting is that it's the site at the root (without the change) that can't send mail. The site below the root is able to send mail just fine with the change. So with that said, I don't know how this change will help.
Okay, I've looked at this and I've seen the same response. However, the script code that is producing this is encrypted so I have no way of knowing why this response was generated. Why is the script having a problem establishing a database connection? Clearly the rest of the site is able to access the database. Why can't the script? Any help would be appreciated.
Thanks, David
PS Could you make the change suggested by Lorraine in your next release? That seems like the most flexible way to implement support for multiple levels of sites without having to change the code.
First, I tried the path suggestion made by Lorraine, and it didn't work at all, even in Firefox on the Test site. It turns out that documen.location.href gives the full URL for the current location. What I need is the root URL for the site. Is there any way to get that so that the if statements don't have to be hardcoded?
Second, when I leave the virtual directory prefix off the string assigned to sajax_uri (i.e. Test), I get the same "Error establishing connection to database" response on the Test site that I get on the root site. This would indicate to me that somehow the value of sajax_uri is being used in a manner that is not producing the correct URL for the root site.
Lorraine's adjustment may not work for every deployment, and I rather point the few multi-domain users to this post, than to deal with a bunch of "this new code broke my 500 other installs".
the url is correct, otherwise you would not see any response in Firebug coming back from PHP backend.
the db connection issue stems from PHP not Javascript.
you could add some debug code (echos) to lib_ajax.php at certain points to see when the PHP script breaks (likely before a DB call of some sort).
FAQs
Reply to Post
Add a New Topic
Search 
cforms II User Forum
Quote and Reply 
Topic RSS 
