I have been searching Google for hours regarding a nasty bug in Magento 1.9.1.
I'm using the demo setup to show the possibilities of Magento for several customers.
One customer has sent me an email she couldn't create an account.
Ok, I thought and tried the same thing and guess what... I get an error telling me "Please make sure your password match".
I already "patched" the Customer.php file by changing $confirmation = $this->getPasswordConfirmation(); to $confirmation = $this->getConfirmation();
This resolves the checkout issue which has the same bug.
But this doesn't resolve to make a new account to use with Magento.
We had several update bugs with updating 1.8 all the way to 1.9 and now a bug in a fresh installation.
Are there developers out there which have fixed the account issue too?
Please let me know.
Steve
Copy /app/code/core/Mage/Customer/Model/Customer.php to the local
Search for function validate()
Comment //$confirmation = $this->getPasswordConfirmation();
Insert $confirmation = $this->getConfirmation() ? $this->getConfirmation() : $this->getPasswordConfirmation();
This would resolve the issue for registration and checkout as well.
To solve "But this doesn't resolve making a new account to use with Magento." you need to recompile ( or turn compiler off)
I have tried your solution but compilation is not used.
What I did was install a clean Magento installation and guess what.
I can register a new account and I can use the checkout without problems.
It seems that the demo installation provided for free from www.magentocommerce.com doesn't work as it should.
Br,
Stevan
Related
Just upgraded from Laravel 6 to 7, and had the error response above when submitting a contact form. I eventually found a solution that seems to work and I am submitting here to help out the next guy.
In the terminal run:
composer require illuminate/mail
Add the following to the top of the controller file (app/Http/Controllers/Main.php in my case):
use \Illuminate\Support\Facades\Mail;
Add this to bootstrap/app.php:
$app->register(Illuminate\Mail\MailServiceProvider::class);
Save and test, and it worked localhost.
If the above does not work for you, there are some other possible issues and solutions available at this link, where I must give credit to vipindasks.
https://laracasts.com/discuss/channels/lumen/lumen-52-mail-not-working
Since I am suppose to ask a question:
Do you see any problems with this solution even though the site and mailer is working now?
You are simply missing a backslash. This tells the autoloader that the file you are looking for is not in the namespace your controller resides in :
$app->register(\Illuminate\Mail\MailServiceProvider::class);
Run composer update hope this will help you
I have an installation of Magento 1.9.2. I am using a custom theme, and anytime I try and place an order it kicks off the Ajax on the page and then stops with no error messages, but does leave a log:
ERR (3): User Error: Some transactions have not been committed or rolled back in /html/lib/Varien/Db/Adapter/Pdo/Mysql.php on line 4039
I have spent 2 days trying to get to the bottom of this with no joy. It doesn't matter what payment method I use its always the same.
You should try to log all MySQL queries to see what wrong here. lib/Varien/Db/Adapter/Pdo/Mysql.
Open the file lib/Varien/Db/Adapter/Pdo/Mysql.php and change the value of the protected property $_debug to true. You can also change the value of $_logQueryTime which is especially handy when debugging slowdowns. Once you make this change all queries will be logged in the file var/debug/pdo_mysql.log
Hope this will help you. Please put your corrupted query here if you fixed it.
I had today the same problem. Magento 1.9.2.4 with a custom theme. Everything worked fine, expect the checkout-process. The custom theme used the PHP short open tag <? php code ?> . After enabling short_open_tag in the php.ini, everything works fine.
Everything was fine 'til this morning. I've tried clearing cache, re indexing, all tips I could find on the internet.
Here is the message I'm getting
Fatal error: Call to a member function getId() on a non-object in /home5/rockbott/public_html/app/code/core/Mage/Adminhtml/controllers/Catalog/ProductController.php on line 578
here is line 577 and 578:
if (Mage::app()->isSingleStoreMode()) {
$product->setWebsiteIds(array(Mage::app()->getStore(true)->getWebsite()->getId()));
A newly created product gives me Fatal Error message. Duplicated product gives me the same, but when I go to manage products it appears, but without SKU# and 0 stock count. When I try to edit that product again - I get Fatal Error.
Please help me with my problem.
Thanks in advance.
Thanks for your response.
Someone suggested that I clear log file and I did. I'm sorry I don't have the log file. Compiler is disabled as well. Would you be kind enough to take a look here: http://www.magentocommerce.com/boards/viewthread/347764/ I've posted more information there including reports.
Thank you
Anna
I realize this is old, but on a Magento 1.9.0.1 install i was having the same problem. I'm not sure what is happening but enabling the cache allowed it to work for me. Weird.
What appears to be causing it in my case is a remnant logging line in Mage.php that I was using to track events.
On line 447 I had:
Mage::log($name, null, 'events.log');
Removing this logging line resolved the issue.
With your informations is difficult to find the problem.
Can you paste your system.log file?
One question: Do you have the compiler enabled? Try to disable it.
I had the same error. Solution turned out to be very simple: you need to replace getStore(true) to getStore(1).
Its very strange because in PHP true same as 1 ... but in this it was a mistake. If you make a "more correct" and write:
$product->setWebsiteIds(array(Mage::app()->getStore(Mage::app()->getStore()->getId())->getWebsite()->getId()));
Magento give you not true website. Was too lazy to look for, as well as programmers Magento (getStore (true)) :)) so I decided to leave it
I have a new fairly fresh install of Magento 1.7.0.2. I installed two custom payment method modules that are working fine. But now whenever I try to disable or enable any Payment Method or Shipping Method it gives me an error like this:
An error occurred while saving this configuration: Warning:
preg_match() expects parameter 2 to be string, array given in
/app/code/core/Mage/Adminhtml/Model/System/Config/Backend/Encrypted.php
on line 57
Do you have any idea why?
EDIT 2:
I found the problem. It was caused by a patch I applied to fix to a previous BUG. :P
EDIT:
So I disabled all custom modules and I was still getting the same error. I logged what was happening and it seems that some core modules are sending an array to be saved.
Like PayPal Express Checkout for instance. One of the config options is the Time of Day in the SFTP credentials for Settlement Report Settings. It's composed by three different drop-downs and it's sending an array to be saved!
In the Shipping Methods, UPS has a config options called Allowed Methods, and it's also sending an array!
I still don't know why it wasn't happening before and now it is. They shouldn't be encrypting everything. Any clues?
I had the same issue, its a known bug, try this around line no. 135 on code/core/mage/Adminhtml/model/config/data.php
// add this code
$backendClass=false;
if (isset($fieldConfig->backend_model)) {
$backendClass = $fieldConfig->backend_model;
} // before this
if (!$backendClass) {
$backendClass = 'core/config_data';
}
This actually is a reported bug in Magento that seems to affect encrypted config settings (passwords, API keys, etc.).
http://www.magentocommerce.com/bug-tracking/issue?issue=14217
Try disabling the first of the modules, log out of the admin panel, clear /var/cache and see if the problem still exists. If it does, do the same with the second module.
The problem should be gone. Now that you know which module causes the problems you can either decide to try another module instead or debug to see whats going wrong.
Put a breakpoint on line 57 in /app/code/core/Mage/Adminhtml/Model/System/Config/Backend/Encrypted.php to see what goes wrong. It seems that the second parameter is not a string (might be null for example due to wrong configuration or something) when its given to the preg_match function. Maybe this helps you to identify the problem.
Regards
Disabling modules through the back office isn't a good idea as it only disables the block output, if you would like to disable a module you should go to app/etc/modulesand there you should find Module_Name.xmlfile - in this file just put false in active node.
Magento checkout is working fine, on all other browsers except IE, it gets stuck over billing section [STEP-2], and when I click continue it does not proceed further?
I tried with both account checkout / guest checkout, none of them works in IE.
Turn on Javascript error reporting for Internet Explorer and/or install an Internet Explorer javascript debugger. You're running into a Javascript error that breaks all the other javascript on the page, and prevents the checkout from proceeding. There's myriad reasons this could be happening, and without seeing your error messages it's impossible to debug. Once you see your error messages, you'll be able to answer.
I looked many internet articles and found that people solved this kind of issue with introducing div col-right block, but in my case it was not helping out, I checked for ajax reload progress url and progress.phtml file too, but in Magento 1.5.0.1 this file does not exist. so none of the solution worked that I read about IE magento checkout issue.
The fix which saved me is this
Go to File :
/app/code/community/Jira/MageBridge/Model/Rewrite/Url.php
around line 89:
change the line below
protected function isSecurePage($routePath = null){
To
protected function isSecurePage($routePath = null)
{
$routePath = preg_replace('/\*\//',
Mage::app()->getRequest()->getRequestedRouteName().'/', $routePath);
$routePath = preg_replace('/\/\*\//',
Mage::app()->getRequest()->getRequestedControllerName().'/', $routePath);
This fixed actually https SSL issue. that was got blocked by IE. I hope it will help someone.