rjcord

In an almost random long shot I upped the z-index to 99999 and guess what the error message and success messages showed up! Would be nice if the console messages could detect that!

I’ve just installed the plugin and updated the Comments container selector with the #comment-wrap selector. I get the console messages below in debug mode but no popup when I click on the Comment Submit button with an empty comment field. Theme is Divi, WP 4.1.1. I don’t know what the reference to X-WPAC-ERROR means. Any suggestions?

Console log:
wp-ajaxify-comments.js?ver=1.2.0:87 [WP Ajaxify Comments] Initializing version 1.2.0
wp-ajaxify-comments.js?ver=1.2.0:87 [WP Ajaxify Comments] Found jQuery 1.11.1
wp-ajaxify-comments.js:87 [WP Ajaxify Comments] Found jQuery blockUI 2.6
wp-ajaxify-comments.js:87 [WP Ajaxify Comments] Found jQuery Idle Timer plugin
wp-ajaxify-comments.js:87 [WP Ajaxify Comments] Attach form…
wp-ajaxify-comments.js:87 [WP Ajaxify Comments] Search comment form (selector: ‘#commentform’)… Found: e.fn.init[1]
wp-ajaxify-comments.js:87 [WP Ajaxify Comments] Search comments container (selector: ‘#comment-wrap’)… Found: e.fn.init[1]
wp-ajaxify-comments.js:87 [WP Ajaxify Comments] Search respond container (selector: ‘#respond’)… Found: e.fn.init[1]
wp-ajaxify-comments.js:87 [WP Ajaxify Comments] Search comment paging links (selector: ‘#comments [class^=’nav-‘] a’)… Not found
wp-ajaxify-comments.js:87 [WP Ajaxify Comments] Search comment links (selector: ‘#comments a[href*=”/comment-page-“]’)… Not found
wp-ajaxify-comments.js:87 [WP Ajaxify Comments] Initialization completed
wp-ajaxify-comments.js:87 [WP Ajaxify Comments] Found error state X-WPAC-ERROR header. undefined
wp-ajaxify-comments.js:87 [WP Ajaxify Comments] Comment has not been posted
wp-ajaxify-comments.js:87 [WP Ajaxify Comments] Try to extract error message (selector: ‘p:parent’)…
wp-ajaxify-comments.js:87 [WP Ajaxify Comments] Error message ‘ERROR: please type a comment.’ successfully extracted
wp-ajaxify-comments.js:87 [WP Ajaxify Comments] Found error state X-WPAC-ERROR header. undefined
wp-ajaxify-comments.js:87 [WP Ajaxify Comments] Comment has not been posted
wp-ajaxify-comments.js:87 [WP Ajaxify Comments] Try to extract error message (selector: ‘p:parent’)…
wp-ajaxify-comments.js:87 [WP Ajaxify Comments] Error message ‘ERROR: please type a comment.’ successfully extracted

As I remember, for my project, I added these two lines to the class:

.widget_recent_work img {
….
width: 50px;
height: 50px;
}

in the …wp-content/plugins/featured-images-widget/style.css file. You might have to play with different px numbers to suit your project.

Jan: I wouldn’t want to limit how authors offer support or worry about keeping users on www.ads-software.com. Many plugin authors put their documentation on their own websites under their direct control. Easy access to that is always preferable.

Also from a UX standpoint one would like to see any Support tab tell you straight up how and where to get support and not just show a list of posts. If it is the local forum post say so and show them, if it’s somewhere else say so and optionally not show any posts.

I’m not sure all authors are aware of the ability to add sticky entries, but that would be useful too if used. I recommend the ‘Support’ tab be called ‘Forum’, or ‘Plugin Forum’ or ‘Theme Forum’ as appropriate.

People who contribute/distribute/offer their Themes and Plugins through the www.ads-software.com site.

The scripts make three thumbnails from the original (named <userid>_<filename>). I’m getting fatal errors during the creation of these after the first one is generated. One thumbnail is a custom size called <size>_<userid>_<filename> (size depends on the settings for the contest) the other two are called med_<userid>_<filename) and pre_<userid>_<filename>. You can ftp into the …/wp-content/plugins/wp-photocontest/contests_holder/<contest name> folder to see them.

I’m running out of memory with 30MB allocated to php and hoping to raise this to 60MB. For me the break point is somewhere between 330kb and 430kb for original image file sizes.

So when the script hits the fatal error (and dies) during this process it wont get to the database updating but will leave files on the server that prevent re-uploading because there is a file-exists check based on the original filename.

One possibility is to add a file_size check to the code to kick out any upload above xKB before it tries to generate thumbnails but this is site specific. I’d rather get more memory. I suggest you call the tech support guys at the hosting company you use to get the real memory limits you have and explore options with them. PHP scripts only set and return settings that for me are completely fallacious being over-ridden by hosting account settings. I don’t know what happens with really large image files and more memory yet. So even then a file size limitation may still be needed given today’s digital cameras with as much as 18MB sensors.

May be frekel will have other suggestions (and corrections to my analysis).

Hope this helps.

At least on my installation, the workaround allows one’s use of the captcha code when logging in as a different registered user on the same machine – at least that’s how I interpret it. I’d have to look into the different problem of turning off the captcha in the back-end and that not working. But as you say see if Frekel responds.

My suggestion is to turn on debug messages in the photocontest settings (Admin > Photocontest > Update Settings > DEBUG FLAG) and see if you get a Fatal error: Out of memory… I suspect you are hitting your server’s memory-limit. If allowed raise it (there may be several ways to do that), if not you may have to find a better hosting package.

Hope this helps.

There seems to be a problem with memory usage during image processing in wp-photocontest/lib/thumbnail.class.php. I can get a fatal error after making one of the three thumbnails and the page returned is basically blank (without debug messages turned on in the admin panel for the plugin.) Consequently the entry doesn’t get recorded in the DB tables.

Turns out it’s running out of memory with the server memory-limit set at 30MB. The solution appears to be to find a hosting package with higher memory-limit – say 60MB. Or config your own dedicated hosting package. Trying to change the memory-limit doesn’t work with init-set() and other options ‘cos my provider won’t allow it.

Trying a reload of the same image then fails because it already exists (in the full size version) on the server – a big user problem. Possible solution: document requirement that the server should have a memory-limit of at least, I don’t know, say 48MB. I suspect most modern hosting packages may already have more memory available.

Other suggestions welcome, ‘cos now I’m faced with having to migrate to a better hosting package.

Workaround: I reenabled the line:
unset($_COOKIE[‘photocontestVote’]);
in viewimg.php to defeat the check on returning user. Most of the time I expect voters to be logging in from their own PC. If you login as a different user on the same machine it doesn’t seem to work without the above change. A rework of the logic here is suggested longer term.