Jay Versluis

Hi ayane9,

browsers try to load that index file by default. They will also try to load start and home files too, and it depends on the browser which file is attempted first. Furthermore, you could have an index.htm and an index.html file at the same time, and again it depends on the browser to load either one of them first.

Because WordPress is PHP based, its main file is index.php. Make sure it’s the only variation of index.* in your home directory and rename (or delete) all others, including home.* and start.*

This particular file will only be picked up if WordPress is installed in your root directory: so if it lives in a subfolder then you must navigate to the subfolder in order to load WordPress in your browser (example.com/wordpress). Do you have WordPress installed in the root directory?

Hi MrYann,

I ran into the same problem today on a CentOS 6 server. Just like in your case, sendmail was working, and other PHP mail scripts were working too.

Turns out that it was caused by SELinux which can prevent mail from being sent. To test, try this from the command line:

/usr/sbin/getsebool httpd_can_sendmail

This will show you ON or OFF. To change it, run this:

sudo setsebool -P httpd_can_sendmail 1

This can take several minutes depending on the speed of the server. It solved the problem in my case.

Hi greenfuture,

it’s a little complex, please bear with me. You must understand how WordPress handles the various user roles: only Authors, Editors and Admins can write and consequently edit their own posts. Contributors and Subscribers cannot usually publish posts. It’s explained in more detail here: http://codex.wordpress.org/Roles_and_Capabilities

P2 offers an option which lets “all users” write posts (under Appearance – Theme Options) – but the post owners are still governed by WordPress. Therefore, Subscriber and Contributor posts show up in P2, but they can’t be edited by either user role.

The solution to your problem is to make every registered member an Author. That way they will be able to edit their own posts on the front page.

Hope that explains it.

Hi fendlel,

here’s a quick fix that will swap the post title and the date. Feel free adjusting the margins to suit your taste, or add extra padding where required:


/* swap post title and date */
#main h4 {
margin-top: 30px;
margin-bottom: 15px;
}
#main .postcontent h2 {
margin-top: -65px;
}


Note that results may vary on your own site – looks like you’ve made some modifications to the look and feel of P2. Good luck 😉

It’s a bit pernickety:

The link needs to be on its own line, and it must not be the last line in the post. Hit return after the link so your cursor is on a new line – that should solve your problem.

Just wanted to let you know that I’ve spotted the problem on my test site too – and it seems to be really random. In the middle of the session, after a few browser refreshes and unrelated CSS tweaks, the problem occurred. Out of nowhere.

Then the next moment everything was back to normal. Sometime later, the controls were white blobs again. This happens consistently on Safari and Firefox – for seemingly no apparent reason. It’s not a browser issue. Embedded YouTube are not affected, only MP4 embeds.

I will keep my eyes peeled and see if any particular condition triggers this behaviour.

None of them should impact on your site to display videos indeed. Very strange. I’ve just tested it with an MP4 video and all controls show up fine in Safari on Mac:

http://wpguru.co.uk/wp-content/uploads/2013/10/P2-mp4-screenshot.png

Here’s what I would do:

– disable all plugins, check how that looks
– with disabled plugins, upload the MP4 again and check the results
– re-install P2 and check again
– if there’s still no improvement, install WordPress again

Good luck!

Try to put the link to your MP4 file on its own line. This should auto-embed the video, perhaps it’ll work better. Like this:

[video src="http://sub.domain.com/wp-content/uploads/2013/10/video.mp4" /]

Works for me.