As the developers of Open Journal Systems, Open Conference Systems, Open Harvester Systems, and Open Monograph Press, the PKP team are experts in helping journal managers and conference organizers make the most of their online publishing projects. PKP Publishing Services offers support for:

As a customer of PKP Publishing Services, you will not only receive direct, personalized support from the PKP Development Team, but will be contributing to the ongoing development of the PKP applications. All funds raised by PKP Publishing Services go directly toward enhancing our free, open source software. For more information, please contact us.

1. Search the forum. You can do this from the Advanced Search Page or from our Google Custom Search, which will search the entire PKP site. If you are encountering an error, we especially recommend searching the forum for said error.

2. Check the FAQ to see if your question or error has already been resolved.

3. Post a question, but please, only after trying the above two solutions. If it's a workflow or usability question you should probably post to the OJS Editorial Support and Discussion subforum; if you have a development question, try the OJS Development subforum.

Is there a chance that the problem is only occurring when the Turkish language is being used on the language pulldown? We've tried to duplicate this locally with Turkish characters and were unable to do so.

No it occurs when locale changed to both Turkish and English, but only some Turkish letters case not all of them.Actually there are two problem probably same reasoned:1. If a user name or last name contains some Turkish letter, no password reset email send.2. Some prepared Turkish emails cannot be sent. If I change the subject field sentence of the email from Turkish to English sentence (email body remains in Turkish), the mail normally send.

If you're not using SMTP, then OJS will use PHP's mail() function to send email (see http://ca2.php.net/manual/en/function.mail.php). It's called from classes/core/String.inc.php in the mail() function, and before that, from classes/mail/Mail.inc.php in the send() function.

Without the MTA log, it'll be tough to tell -- you might check with your host whether they provide access to mail sending logs from your account. Otherwise, the best way to debug this will be as follows:

1) Determine whether the mail() call is returning true or false. If it's returning true, then there's nothing we can do from within OJS to tell why the message isn't sending. This means it's being accepted for delivery by the MTA, but never actually sent for some reason.

2) If mail() is returning false, then we know the MTA is rejecting the message, but we don't know why. I'd suggest modifying OJS temporarily to dump the parameters to that function to a file or something similar so that they can be inspected more closely.

------------------We are sorry for possible inconvenience. As we have checked php mail() function is working fine on the server. We have created test mail script and email from it insanbilimleri.com/New_File.php was successfully delivered to destination. The issue you faced with seems to be related to your application error as the only message we get after submitting your form was "/insanbilimleri.com". Please contact with your application developers in order to verify the reason of such message instead of common reply. Thank you.

Unfortunately this doesn't get us much further -- we've already established that mail() is broadly working, but in some situations email isn't getting delivered. I'm not sure what they mean by "the only message we get after submitting your form was "/insanbilimleri.com"" -- could you get further clarification on that? Is it an error message from the server log, or a redirect, or something else? What form are they submitting?

The next best way to debug a blank page is to figure out where PHP is dying. Find the requestResetPassword function in pages/login/LoginHandler.inc.php and add the following line at the top of the function (just below the opening brace):

This will break the password reset function, but will tell us whether or not you're getting to that point before PHP dies. Let me know if you see the "Testing' error message when you try the reset. If you do, then move it down to just above the $mail->send() function call and try again.

If you see it there, then proceed into the send() function of classes/mail/Mail.inc.php and see if you can figure out likewise where in that function PHP is dying, or if it's getting through to the String::mail(...) call near the bottom.

Unfortunately this is one of the more painful aspects of debugging PHP.