riricher

My apologies. Has nothing to do with Revisionary. Just seems that the VamTam editor gets very sluggish from time to time if you’re not Administrator. Especially bad on Internet Explorer 9.

Hosted on HOSTEK.

They run IIS rather than Apache
PHP 5.5.19
Server version: 5.6.14 – MySQL Community Server (GPL)

Same experience as couple of others. Tables not created, no error messages on install. Added the tables via SQL (without the single quotes) and now works fine.

Also, Add the Credit Link without “link juice” doesn’t remove the juice. Do not display does work.

Version v1.6.1
WordPress 4.0.1

Never mind. My host company disabled postbacks since someone was trying to hack my site. Reenabled and now works.

Some more information. I said Disable AJAX (by adding forceclassic=”true” to the sortcode) and now it works. Unfortunately the progress bar no longer does (probably requires AJAX).

Any change you’re using Synchronous AJAX? That might cause uploads to lock up.

I clicked “Update” from the WordPress Plugins dashboard if that’s what you mean by “automatic”. There was an earlier version installed. Was I supposed to delete the earlier version first?

A little more information. I updated to 2.4.1 (on WordPress 3.8.3) and got the following error.

Fatal error: Cannot redeclare wfu_browse_files() (previously declared in D:\home\PeaceDaleChurch.org\wwwroot\wpdir\wp-content\plugins\wp-file-upload\lib\wfu_admin.php:446) in D:\home\PeaceDaleChurch.org\wwwroot\wpdir\wp-content\plugins\wp-file-
upload\lib\wfu_admin_browser.php on line 3

However, can then activate and uploads work. The “remake the shortcode” I had to do with WordPress 3.9 wasn’t necessary.

I did a number of things (deleted a few file related plugins, reinstalled wp-file-upload, etc…). That didn’t seem to have an effect.

Finally I simply used the WordPress File Upload shortcode composer to make one that did exactly what the old one did but with a new ID. Now it works fine.

It may have something to do with the magic ID=1. That doesn’t show in the shortcode, but others do. Manually adding it to the old shortcode didn’t help, so some good database thing must happen when creating a new ID.

I figured it out. Following goes in web.config for IIS

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
	<system.webServer>
		<rewrite>
			<rules>
				<!--# Media Vault Rewrite Rules-->
				<rule name="In Protected Directory" stopProcessing="true">
					<match url="^wp-content/uploads(/_mediavault/.*\.\w+)$" ignoreCase="false" />
					<action type="Rewrite" url="index.php?mgjp_mv_file={R:1}" appendQueryString="true" />
				</rule>
				<rule name="In Standard Media Directory" stopProcessing="true">
					<match url="^wp-content/uploads(/.*\.\w+)$" ignoreCase="false" />
					<conditions>
						<add input="{QUERY_STRING}" pattern="^(?:.*&)?mgjp_mv_download=safeforce(?:&.*)?$" ignoreCase="false" />
					</conditions>
					<action type="Rewrite" url="index.php?mgjp_mv_file={R:1}" appendQueryString="true" />
				</rule>
				<!-- Usual WordPress Rule  works if before Media Vault, but Vault won't setup initially -->
				<rule name="wordpress" patternSyntax="Wildcard">
					<match url="*"/>
					<conditions>
						<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true"/>
						<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true"/>
					</conditions>
					<action type="Rewrite" url="index.php"/>
				</rule>
			</rules>
		</rewrite>
	</system.webServer>
</configuration>

Yep, adding px did it. Thanks.

Here it is:

[wordpress_file_upload uploadpath=”Rachel” uploadrole=”editor” placements=”title/filename+selectbutton+uploadbutton/progressbar/message” successmessage=”Upload Successful” widths=”uploadbutton:500, progressbar:500″ heights=”progressbar:400″]

On my system it was caused by Contact Form 7 generating a shortcode of:

[captcha captcha=some id] for both challenge and input fields.

Manually changing to [captchac …] and [captchar …] fixed the problem.