Will D. White

Just grabbed a fresh copy of this plugin – using it with the latest version of WP and continue to get a 500 error trying to load it.

I’ve opened the config.php file you mentioned, and $wp_siteurl variable is already set to ”;

I’ve tried to update it to the server location of wp-load.php manually – but no luck there either.

My database isn’t on localhost, do you think that could be causing a problem? Any idea what else could cause a 500 error?

Thanks in advance.

I found out my server blocked the IPNs PayPal uses.

Download/install Bad Behavior plugin and use the Whitelist functionality to allow your server to receive the IPN’s.

Here’s the IP list that PayPal has posted that I’ve whitelisted – it seems to do the trick. Good luck.

173.0.88.66
173.0.88.98
173.0.84.66
173.0.84.98
66.211.168.91
66.211.168.123
173.0.88.67
173.0.88.99
173.0.84.99
173.0.84.67
66.211.168.92
66.211.168.124
173.0.88.69
173.0.88.101
173.0.84.69
173.0.84.101
66.211.168.126
66.211.168.194
173.0.88.68
173.0.88.100
173.0.84.68
173.0.84.100
66.211.168.125
66.211.168.195
173.0.81.1
173.0.81.33
66.211.170.66
216.113.188.100
66.211.168.93
118.214.15.186
118.215.103.186
118.215.119.186
118.215.127.186
118.215.15.186
118.215.151.186
118.215.159.186
118.215.167.186
118.215.199.186
118.215.207.186
118.215.215.186
118.215.231.186
118.215.255.186
118.215.39.186
118.215.63.186
118.215.7.186
118.215.79.186
118.215.87.186
118.215.95.186
202.43.63.186
69.192.31.186
72.247.111.186
88.221.43.186
92.122.143.186
92.123.151.186
92.123.159.186
92.123.163.186
92.123.167.186
92.123.179.186
92.123.183.186
92.123.199.186
92.123.203.186
92.123.207.186
92.123.211.186
92.123.215.186
92.123.219.186
92.123.247.186
92.123.255.186
95.100.31.186
96.16.199.186
96.16.23.186
96.16.247.186
96.16.255.186
96.16.39.186
96.16.55.186
96.17.47.186
96.6.239.186
96.6.79.186
96.7.175.186
96.7.191.186
96.7.199.186
96.7.231.186
96.7.247.186
216.113.188.64
216.113.188.34
173.0.84.178
173.0.84.212
173.0.88.178
173.0.88.212
66.211.168.136
66.211.168.66
173.0.88.203
173.0.84.171
173.0.84.203
173.0.88.171
66.211.168.142
66.211.168.150
173.0.84.76
173.0.88.76
173.0.84.108
173.0.88.108
66.211.168.158
66.211.168.180
118.214.15.186
118.215.103.186
118.215.119.186
118.215.127.186
118.215.15.186
118.215.151.186
118.215.159.186
118.215.167.186
118.215.199.186
118.215.207.186
118.215.215.186
118.215.231.186
118.215.255.186
118.215.39.186
118.215.63.186
118.215.7.186
118.215.79.186
118.215.87.186
118.215.95.186
202.43.63.186
69.192.31.186
72.247.111.186
88.221.43.186
92.122.143.186
92.123.151.186
92.123.159.186
92.123.163.186
92.123.167.186
92.123.179.186
92.123.183.186
92.123.199.186
92.123.203.186
92.123.207.186
92.123.211.186
92.123.215.186
92.123.219.186
92.123.247.186
92.123.255.186
95.100.31.186
96.16.199.186
96.16.23.186
96.16.247.186
96.16.255.186
96.16.39.186
96.16.55.186
96.17.47.186
96.6.239.186
96.6.79.186
96.7.175.186
96.7.191.186
96.7.199.186
96.7.231.186
96.7.247.186

I’ve been thinking about this.

Is it possible that the default location of uploads was changed during the most recent WP upgrade?

Under Settings -> Media -> Upload Files heading you should check and see what the values are. Question mark boxes would entail that the link to the image is broken – not necessarily that they aren’t being loaded.

I’ve recently taken the files associated with the website that loads blank pages in the administration area and loaded them up in a more powerful hosting environment. The problem went away immediately.

So I went back to the troubled installation and it looks like I’ve pinned down the problem – at least within my setup.

The error logs show:
PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 7680 bytes) in /www/test/wp-admin/includes/admin.php on line 66

It looks like an issue with memory limitations of the host. I’m going to see if they will let me modify my .htaccess or php.ini to work around it – or at the very least ask them to up it.

I would bet that your best bet currently is to look for a server plugin that will turn emails into PDF’s. Once you’ve set it up, the next step would be to simply direct Contact Form 7 to send the emails it generates to that server plugin. I don’t expect there will be an easier way to integrate full-fledged PDF creation into the plugin itself.

If there’s another solution, I’d love to hear it.

Best of luck.

I’m actually running into this issue as well. My WordPress is up to date. Nothing in my functions.php file alters anything in the admin area. I’ve tried switching back to twenty eleven and have tried disabling all plugins and still receive the blank page.

Whats odd is that hard-refreshing the page makes it display correctly, but then the next time you try to access it – it is blank again.

Checking the source code I see that on the refreshed page the charset is set correctly. When I check the blank page’s source its blank – making me think its an issue in the PHP before it begins to spit out the header information.

I’m currently running on Yahoo hosting (which seems to be particularly finicky). I wonder if its another issue with their terrible WordPress support.

Are you on Yahoo as well Nicky?

Hey Christine – this isn’t an uncommon problem.

Your 32MB max is normal – but in addition to it a lot of hosting platforms limit the amount of time that it will spend uploading images (also known as scripting limitations).

Here’s my advice – make sure any image you are uploading is less than 2MB and try loading one at a time, then two at a time, then three.

Not ideal, but it will give you an idea of your server’s limitations.

If you have a backup of the web.config file, go ahead and load it back up. Most wordpress installations will manage their permalink settings through a file called .htaccess.

There are a variety of ways to check that your htaccess is set up correctly. In FTP, ensure that hidden files are being displayed (usually in the view tab) and download a copy of the .htaccess file.

Make sure that it has a section that looks like this:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

If it looks different, put that in at the top of the file and save it and put it back on the server.

This looks like an explorer bug on your nice looking football ad. In Firefox the problem doesn’t show up.

To solve the problem you should look at the CSS “width” and “padding” values of each of the elements that contain the ad.

It looks like one of those has a width or padding with a left value that is too high.

Remember “TROUBLE” – TRBL – Top Right Bottom Left.

Word Art from Microsoft Word isn’t copy-pastable. If I understand correctly, you’re trying to add a nifty artistic header or pretty set of text to your page. Unfortunately the only way to do that is to modify the theme’s CSS file (usually style.css) or create a custom graphic including the Word Art in a graphics program like Photoshop and save it as a .JPG or .PNG file.

The functions.php is a PHP file. That means that by default you can start the file with <?php and put as much as you want – and then close the file with ?>

The only time you close the PHP tag is when you want to post HTML to the website (or run another language, I suppose). Like in your theme files like page.php or header.php where you would stop using PHP for a while and use HTML instead:

EG: <?php if(is_page()){ ?>Some cool html here<?php } ?>

In the example, it says “if this is a page” (using PHP) and then switches back to HTML for a while. Then when you’re done posting HTML code you close it back up with another php setting <?php } ?>

I hope that helps clear up how PHP works within the theme structure for ya!

We have multiple admins – some more savvy than others. Its a custom build and there really isn’t any benefit of loading the admin bar – so we figured why load it at all. Lets pull that function out and lower the number of HTTP requests etc.

add_filter( 'show_admin_bar', '__return_false' );

These stylesheets became unnecessary when I removed the bar.

Its actually not just the admin bar CSS files I’m looking to remove, either. There are a few plugins that I have running that I’m trying to figure out similar issues with. I’d love to set up an if-then statement that lets me use remove_action on plugin files when someone isn’t on a page that needs them.

For example if I only run a certain plugin on the home page, but it loads its’ files on every page, I could do something like this:

if(!is_front_page()){remove_action('wp_head','whatever-the-action-name-is');}

However, I don’t know how to find out what the name of the action is in order to get the remove_action() function to work on it.

I hope this makes things a little clearer. Thanks for your response!

After recognizing that the IPN is actually dumping info into the database successfully, and simply returning the wrong “Status” to PayPal, I made a temporary adjustment to the file until the plugin author can fix the issue.

Once you have verified the IPN is working (by checking to ensure that transactions show up in the WordPress Dashboard) you can disable the 404 error altogether from the plugin by opening paypal.php and editing line 62.

Change:
header("Status: 404 Not Found");

To:
header("Status: 200 OK");

Note: This doesn’t fix the issue. It simply makes the plugin tell PayPal the IPN was received successfully no matter what. It should stop the emails from PayPal saying the IPN is broken, and should stop PayPal from disabling your IPN feature every couple weeks.

Hopefully someone can figure out why the plugin is returning a 404 error instead of the 200 status in the first place.

It looks like its having trouble adding capabilities to user roles.

The specific line (95) seems to be trying to add the “edit_posts” capability to the “contributor” role.

Are you running with altered user roles – either by changing the roles in the database or through a user-management plugin? If so, try deactivating the plugin.

If that doesn’t work try commenting out the contributor case in the file mentioned in your error – “class-ai1ec-platform-helper.php” in the app/helper folder.

Change:

case 'contributor':
	$role->$action( 'edit_posts' );
	$role->$action( 'delete_posts' );

To:

/* case 'contributor':
	$role->$action( 'edit_posts' );
	$role->$action( 'delete_posts' ); */

That should remove the ability for contributors to edit any events – but should hopefully also potentially fix your issue.

MountainStream – I think thats a separate problem. You may way to consider creating a new topic.