| Post |
|
Guest
| Viper007Bond 5:25 am September 29, 2008
| |
|
|
Please replace the ??? with your data!
Every time I upgrade cforms, I always have to change the path in /cforms/js/cforms.js as I run WordPress in a subdirectory: http://codex.wordpress.org/Giving_WordPress_Its_Own_Directory
When I upgraded to 9.0, I also had to edit lib_ajax.php and change $abspath from going up 5 directories to just 3. Dunno where the 5 came from.
Thanks for your hard work. :)
|
|
|
Admin
| Oliver Munich, Germany posts 6237 7:39 am September 29, 2008
| |
|
|
Every time I upgrade cforms, I always have to change the path in /cforms/js/cforms.js as I run WordPress in a subdirectory:
It should guess your sub dir location of WP, why it fails to do that I'm not sure. None of the beta testers reported any issues…if you can help pin point it down, it'd be great!
When I upgraded to 9.0, I also had to edit lib_ajax.php and change $abspath from going up 5 directories to just 3. Dunno where the 5 came from.
abspath.php should reside in the side dir level as lib_ajax.php and contains the path to your WP install base.
the 5 ../ are there in case no abspath file is found, so something seems not right. can you check for abspath.php in your cforms folder?
|
|
|
|
|
Guest
| Viper007Bond 7:33 am November 8, 2008
| |
|
|
The abspath.php issue seems to have been resolved.
I'm still having to edit cforms.js and edit the path each time though. You aren't confusing just installing WordPress in a subdirectory (like site.com/blog/) with installing WordPress in it's own folder, are you?
What I mean is my blog runs at http://www.viper007bond.com/ but my WordPress files, etc. are located at http://www.viper007bond.com/wordpress/
|
|
|
Admin
| Oliver Munich, Germany posts 6237 9:06 am November 8, 2008
| |
|
|
cforms detects when it finds a prefix in your blog URL, or if it thinks so. Hence the informational warning message.
the path in cforms.js is hardcoded to use the default wp/cforms location, so if the above is true then cforms will suggest to check js/cforms.js and possible correct the path.
|
|
|
|
|
Guest
| Viper007Bond 11:56 pm November 9, 2008
| |
|
|
I don't quite get what you mean, but all I know is that none of the AJAX works after upgrading until I edit that JS file.
|
|
|
Admin
| Oliver Munich, Germany posts 6237 7:40 am November 10, 2008
| |
|
|
Even if the path is wrong, the Javascript based form validation should always be functioning, except of course when submitting and thus triggering the Ajax call to the backend.
If cforms can't write to js/cforms.js it can't fix the path itself and you will have to manually fix it.
|
|
|
|
|
Guest
| Viper007Bond 11:05 pm November 23, 2008
| |
|
|
Ah, okay, that'd be the problem. I keep my files unwritable for increased security.
Wouldn't a better solution be to set that dynamically inline (i.e. just set that variable within a script tag) rather than in an external JS file that the plugin has to modify?
|
|
|
Admin
| Oliver Munich, Germany posts 6237 11:37 pm November 23, 2008
| |
|
|
Sure, but how do you do that in the case of an external JS file?
I could create some inline JS code when rendering the PHP page but most users would not appreciate that, and I wouldn't like it myself.
|
|
|
|
|
Guest
| Viper007Bond 1:35 pm December 19, 2008
| |
|
|
I meant do both, much like how WordPress translates it's JS files.
You set a variable (the path/URL) via a very short PHP generated inline script tag (all it contains is the one dynamic variable) and then you load the relatively big external JS file which uses that variable.
Keeps the bandwidth nice and low but doesn't rely on making your plugins folder writable. Not to mention that each time you upgrade the plugin, WordPress resets the permissions on the folder to unwritable meaning I have to go in and make the file writable every single time I upgrade.
|
|
FAQs
Reply to Post
Add a New Topic
Search 
cforms II User Forum
Quote and Reply 
Topic RSS 
