Magento1.9.1 Please make sure your password match issue - passwords

I am encountering this issue in CE1.9.1.
When a User registers (doesn't matter if its during checkout or from the Create an Account link) the user keeps getting the password mismatch error even though the password is re-entered correctly.
The form validation does not indicate a miss-match, but once a user clicks on Register it returns the mismatch error.
There is no errors in the chrome console...
I found this: https://magento.stackexchange.com/questions/37381/please-make-sure-your-passwords-match-password-error-in-checkout-with-new-re
But I don't believe it is the same error.
I need to fix it soon, any help is greatly appreciated!

We also had this issue with 1 of our webshops. However we used a checkout extension. So im not sure if this applies for the regular standard checkout. Anyway.
The question should be, are u using a checkout extension?
If so, the value inside the model's file of that extension is set at:
$customer->setConfirmation($password);
but should be:
$customer->setPasswordConfirmation($password);
For me this worked, without changing anything in the core. It's just that the extensions should get a small update, or you can do it manually like i did. Just find that line in the files of the model map of your extension.

as workaround you can use folloing code:
$confirmation = $this->getConfirmation();
$passwordconfirmation = $this->getPasswordConfirmation();
//if ($password != $confirmation) {
if (!(($password == $confirmation) ||
($password == $passwordconfirmation))) {
$errors[] = Mage::helper('customer')->__('Please make sure your passwords match.');
}

Changing app/code/core/Mage/Customer/Model/Customer.php as proposed by #Pedro breaks the functionality of "forgot password" and "edit customer account" pages. Instead, make the following changes to
app/code/core/Mage/Checkout/Model/Type/Onepage.php
by editing lines starting from 369
if ($quote->getCheckoutMethod() == self::METHOD_REGISTER) {
// set customer password
$customer->setPassword($customerRequest->getParam('customer_password'));
$customer->setConfirmation($customerRequest->getParam('confirm_password'));
} else {
// emulate customer password for quest
$password = $customer->generatePassword();
$customer->setPassword($password);
$customer->setConfirmation($password);
}
and set the PasswordConfirmation -Property and not the Confirmation-Property of the Customer-Object:
if ($quote->getCheckoutMethod() == self::METHOD_REGISTER) {
// set customer password
$customer->setPassword($customerRequest->getParam('customer_password'));
$customer->setPasswordConfirmation($customerRequest->getParam('confirm_password'));
} else {
// emulate customer password for quest
$password = $customer->generatePassword();
$customer->setPassword($password);
$customer->setPasswordConfirmation($password);
}

Encountered the same problem and fixed it. Snel's answer is closer to right answer. The problem could lay in the external/local modules, so you should check not the
app/code/core/Mage/Checkout/Model/Type/Onepage.php
And of course do NOT modify it in any case!
But you should find _validateCustomerData() method which is used in your case. Use Mage::log() or debug_backtrace() for it. It may look something like (but not exactly, because this part could be modified for some reason):
if ($quote->getCheckoutMethod() == self::METHOD_REGISTER) {
// set customer password
$customer->setPassword($customerRequest->getParam('customer_password'));
$customer->setConfirmation($customerRequest->getParam('confirm_password'));
} else {
// emulate customer password for quest
$password = $customer->generatePassword();
$customer->setPassword($password);
$customer->setConfirmation($password);
}
Those modules extend the old version of core file so if you module wasn't updated, you should change them yourself and change
setConfirmation()
to its current usable analog:
setPasswordConfirmation()

I also had this same problem. I'm not comfortable with code so I wanted to avoid all the above fiddling. To fix it all I did was update my extensions, and I also disable one page checkout, cleared cache, then re-enabled one-page checkout.
This has now fixed the problem without needing to modify code.
hope it helps for you.

If anybody still can't figure out, why this is happening:
The Conlabz Useroptin extension (http://www.magentocommerce.com/magento-connect/newsletter-double-opt-in-for-customers.html) can cause this behavior aswell.

Unless this truly is a core bug, I wouldn't recommend changing core files.But i sloved this way Open app\code\core\Mage\Customer\Model\Customer.php and edit your code like below
$confirmation = $this->getConfirmation();
$passwordconfirmation = $this->getPasswordConfirmation();
//if ($password != $confirmation) {
if (!(($password == $confirmation) ||
($password == $passwordconfirmation))) {
$errors[] = Mage::helper('customer')->__('Please make sure your passwords match.');
}

I had the same issue after updating to 1.9.2.1 and was unable to resolve using some of the suggested code changes here and elsewhere - also very reluctant to change core code for obvious reasons.
My solution - a configuration update. It was:
Enable OnePage Checkout = Yes
Allow Guest Checkout = Yes
Require Customer to be Logged in = No
I updated to Yes/No/Yes as per the above and cleared the cache. This resolved the issue by inserting the standard customer registration form (rather than appending the registration to end of the billing info) and passing that info to the billing form on successful registration.
It seems there is a code issue here along the lines of the other responses but this was an excellent workaround for me. Hope it helps.

Change this code
app\code\core\Mage\Customer\Model\Customer.php
$confirmation = $this->getPasswordConfirmation();
to this code
$confirmation = $this->getConfirmation();

Related

Detect the first time a VS Code extension version is loaded

I'd like to take an action the first time a user loads a new version of my VS Code extension. This is different from merely detecting first run as described by the How to run vscode extension command just right after installation? because I don't want to detect "just right after installation" I want to detect first run of each new version which is a totally different problem.
Mike Lischke's answer to that question doesn't actually answer that question, it answers this question, but that doesn't mean this is a duplicate question, it means the response to the other question doesn't actually answer the asked question, and since unlike many people I actually read the question, I didn't bother to read the answers, because answers to that question are not what I seek. Frankly I'm tempted to delete the question myself just to spite Stack Overflow because I'm fed up with this crap. Do whatever you like.
Searching the net turned up sample code
export function activate(context: vscode.ExtensionContext) {
if (context.firstTimeUse) {
//do the one-time-per-version-update thing
}
}
but ExtensionContext doesn't seem to have this property, at least not any more.
So how do you do it now?
I could record the version in a file and compare to the file before updating it, but if there's baked in support I'd rather do it the supported way.
There is no supported mechanism.
Since each update gets a new folder, you don't need to log a timestamp, just probe for the file. If it exists, not first run. If it doesn't exist, first run so create the file and do other first run things.
This is so simple and straightforward there probably won't ever be a supported mechanism. Thanks to Lex Li in the comments for confirming that this is the standard solution.
If you need to differentiate major, minor and maintenance releases, the simplest solution is to store the version string in context.globalState. You begin by trying to fetch from context.globalState. Absence means first run ever. If it's present, an exact match for current version means no change. For a non-match you can parse out major and minor version numbers context.globalState.
const currentVersion = context.extension.packageJSON.version as string;
const lastVersion = context.globalState.get("version") as string ?? "0.0.0"
if (lastVersion !== currentVersion) {
logger.warn(`Updated to ${currentVersion}`);
const lastVersionPart = lastVersion.split(".");
const currVersionPart = currentVersion.split(".");
if (lastVersionPart[0] !== currVersionPart[0]) {
// major version change
advertiseWalkthrough();
if (lastVersionPart[1] !== currVersionPart[1]) {
// minor version change
launchWhatsNew();
} else {
// it's a maintenance version change so don't pester the user
}
}
context.globalState.update("version", currentVersion);
}

Problem with Prefix in Discord.js (including .toUpperCase())

Basically, I've been developing a bot for several weeks now using the discord.js library and recently encountered a small but crucial issue. Essentially when I declare my argument, I also made it so that the message content (message.content) would be capitalized using .toUpperCase(). Essentially in doing so regardless of the type of prefix you would enter (symbol wise) it would all be read by the program as valid.
For example only: !help - should work, however if I would enter .help, it would also be read as valid.
In any case, here's the code. I appreciate all the help!
bot.on('message', message =>{
let args = message.content.toUpperCase().substring(PREFIX.length).split(" ");
const sender = message.member;
switch(args[0])
{
case 'HELP':
message.reply("I've sent you some documentation on all the commands that you can use...").then(d_msg => {d_msg.delete(3000); });
message.delete(3000);
const attachment = new Attachment('./UtilityBot_Documentation.txt')
message.author.send('[Education] Bot - Documentation');
message.author.send(attachment);
break;
}
})
The discord.js tutorial covers an extremely similar problem to what you're trying to do. I recommend you check it out. The page I linked in specific is doing a very similar thing to you, but it's worth giving the whole thing a read through if you haven't done so already. In general, I would include the following line just above where you established args.
if (!message.content.startsWith(PREFIX)) return;
What I'm doing here is saying if the message does not start with the prefix, stop running until a new message is sent. I might be missing something, but certainly check out the tutorial. It's really well written.
https://discordjs.guide/creating-your-bot/commands-with-user-input.html#basic-arguments

DokuWiki LDAP can't see any groups

We have just changed our domain after protracted name change (the name actually happened two years ago!) and our DokuWiki installation has stopped being able to see any groups and memberships.
The config has been updated to reflect the new server and DCs and login is working correctly, it is only the groups that aren't working.
$conf['auth']['ldap']['server'] = 'ldap://MYDC.mydomain.co.uk:389';
$conf['auth']['ldap']['binddn'] = '%{user}#mydomain.co.uk';
$conf['auth']['ldap']['usertree'] = 'dc=mydomain,dc=co,dc=uk';
$conf['auth']['ldap']['userfilter'] = '(userPrincipalName=%{user}#mydomain.co.uk)';
$conf['auth']['ldap']['mapping']['name'] = 'displayname';
$conf['auth']['ldap']['mapping']['grps'] = 'array(\'memberof\' => \'/CN=(.+?),/i\')';
$conf['auth']['ldap']['grouptree'] = 'dc=mydomain,dc=co,dc=uk';
$conf['auth']['ldap']['groupfilter'] = '(&(cn=*)(Member=%{dn})(objectClass=group))';
$conf['auth']['ldap']['referrals'] = '0';
$conf['auth']['ldap']['version'] = '3';
$conf['auth']['ldap']['debug'] = 1;
Obviously I have edited the doain name there, but for the life of me I can't see what's wrong here, It all worked fine yesterday on the old domain.
I should also state that this is an old version of DokuWiki that for various reasons I can't actually update.
The debug line gives me a "ldap search: success" line, but if I add "?do=check" onto any url within the system I get "You are part of the groups"...... and nothing, it can't see any groups.
It's a massive pain as we have a pretty intricate ACL setup for the site, so it's not like I can just throw it open to all.
If anyone has any suggestions, no matter how obvious, please pass them on.
Solved it by changing the dokuwiki authentication plugin that was used, the 'authad' is more simple to use and just works with what I'm doing.
As a side bonus it also means that I have finally been able to get the install upgraded to the current version.

How can I get the Register form on the front page in Drupal 8?

I've been trying to get the create account form (register form) in a pop-up on the front page, without any success.
Can anybody here help me out with an example that works?
I've tried adapting examples from Drupal 7 but couldn't get them to work, I've tried to make a custom form but it didn't work, I've tried installing modules that could handle this but they also didn't work.
The last attempt I've made to resolve this problem was:
<?php
/**
* #file
* Functions to support theming in the themename theme.
*/
use Drupal\Core\Form\FormBase;
use Drupal\Core\Form\FormStateInterface;
use Drupal\Component\Utility\UrlHelper;
/**
* Implements hook_preprocess_HOOK() for HTML document templates.
*/
function themename_preprocess_html(&$variables) {
$form = \Drupal::formBuilder()->getForm('Drupal\user\register');
return $form;
}
Any help would be greatly appreciated.
Thank you!
you can use this module: https://www.drupal.org/project/formblock which exposes some additional forms as blocks (like the user registration, new password, contact, etc..). So after you install it you can just configure the block to appear only on the front page. The registration block will not be available for authenticated users or if the anonymous users are not allowed to create new accounts.
However, you will also have to apply this patch https://www.drupal.org/node/2570221 (if it will not be already committed by the time you check it) if you use the latest Drupal8 stable version, otherwise you will get a fatal error.
This link explains how it can be used to programmatically render the login and registration forms.
http://web-tricks.org/content/how-render-user-login-form-and-user-register-form-drupal-8
For the login form
$form = Drupal::formBuilder()->getForm(Drupal\user\Form\UserLoginForm::class) ;
$render = Drupal::service('renderer');
$variables['login_form'] = $render->renderPlain($form);
and for register form
$entity = \Drupal::entityTypeManager()->getStorage('user')->create(array());
$formObject = \Drupal::entityTypeManager()
->getFormObject('user', 'register')->setEntity($entity);
$form = \Drupal::formBuilder()->getForm($formObject);
$variables['register_form'] = \Drupal::service('renderer')->render($form);

Custom YouTrack Workflow 6.0: Can't change 'New Issue' Visibile To

I have a custom WorkFlow that I've built in the Workflow editor. Uploaded it, and assigned it to a project.
When a new Issue is created in that Project, I'm expecting the Visiblity To, to change from {All Users} to {Front End Support}
I have other custom workflows assigned, that are working, so this doesn't have to do with the workflow being added, or assigned to the project.
Here is my workflow, and I've tried a bunch of variations on permittedGroup with, and without the "issue." prefix. None seem to matter.
rule Change PermittedGroup to Support
when permittedGroup == {All Users} {
issue.permittedGroup = {Front End Support}
}
This Sample Workflow, seems to be doing the same thing, though maybe it's old and not compatible with 6.0? And This talks aboue a 'Visible To' command, but I can't find that anywhere.
Thank you!
I was able to fugre this out by testing for the name being blank.
I found this by debugging with messages.
when permittedGroup.name != "anything" {
message(permittedGroup.name);
}
With this I found out that {All Users} visibility is actually blank. And then my final working code is
when permittedGroup.name.trim(mode: nullToEmpty) || permittedGroup.becomes({All Users}) {
permittedGroup = {Front End Support};
message("Support Visibility Must be limited to Front End Support or a Customer Team Project");
}