cakePHP 3.0.7 - Unable to call method "" in "default" provider for field "member_selected" - validation

In MembersTable.php I have:
$validator
->notEmpty('member_selected')
->add('member_selected', ['rule' => ['inList', [0,1], false]]);
return $validator;
I am receiving the following very cryptic message from cakePHP 3.0.7
Unable to call method "" in "default" provider for field member_selected" InvalidArgumentException
⟩ Cake\Validation\ValidationRule->process CORE\src\Validation\Validator.php, line 656
⟩ Cake\Validation\Validator->_processRules CORE\src\Validation\Validator.php, line 136
⟩ Cake\Validation\Validator->errors CORE\src\ORM\Marshaller.php, line 181
⟩ Cake\ORM\Marshaller->_validate CORE\src\ORM\Marshaller.php, line 428
⟩ Cake\ORM\Marshaller->merge CORE\src\ORM\Table.php, line 2034
⟩ Cake\ORM\Table->patchEntity APP/Controller\MembersController.php, line 104
⟩ App\Controller\MembersController->edit [internal function]
⟩ call_user_func_array CORE\src\Controller\Controller.php, line 411
⟩ Cake\Controller\Controller->invokeAction CORE\src\Routing\Dispatcher.php, line 114
⟩ Cake\Routing\Dispatcher->_invoke CORE\src\Routing\Dispatcher.php, line 87
⟩ Cake\Routing\Dispatcher->dispatch ROOT\webroot\index.php, line 37
If I remove the ->add('member_selected', ['rule' => ['inList' ...
every thing works ok, but of course the validation is not being done correctly. I do not have an example of the use if 'inList' but I think I've got it setup correctly. I have several other fields of this table that I've had to remove other validator rules from to get past this error message (e.g. naturalNumber).
I also will reference another stackoverflow question titled "cakePHP 3.0.7 - Baked edit function fails to perform save in patchEntity with Marshaller::merge() error."
The problems can be "resolved" by altering the $validator setting for one of the fields... One of ways to create these errors is to change field name or type, and forget to change it in Entity $_accessible, and Table $validator inside function validationDefault(). Also don't forget $rules->adds in Table::buildRules()
Of course... why would anyone want to change a field name or type? Oh well, it would be nice if cakePHP would give some information as to the actual problem (expected field does not exist, or field specified should not exist).
Anyway, now that I've blown off a little steam, the validator is not reporting anything useful when it blows up. I hope someone is watching stackoverflow so it can be resolved.
Having said all this, I'm still wondering why the 'inList' rule does NOT work?
Answer to why inList, and naturalNumber did not work for me!
add public
add( string $field , array|string $name , array|Cake\Validation\ValidationRule $rule [] )
Adds a new rule to a field's rule set. If second argument is an array then rules list for the field will be replaced with second argument and third argument will be ignored.
Example:
$validator
->add('title', 'required', ['rule' => 'notBlank'])
->add('user_id', 'valid', ['rule' => 'numeric', 'message' => 'Invalid User'])
$validator->add('password', [
'size' => ['rule' => ['lengthBetween', 8, 20]],
'hasSpecialCharacter' => ['rule' => 'validateSpecialchar', 'message' => 'not valid']
]);
Well, it's not true! You cannot leave out the second argument! All errors during validation (which are incorrectly reported as far as I'm concerned) go away if I always specify the second arg and then the 3rd arg specifies the rules!
Thanks to everyone who may read and offer assistance,

You forgot to give your rule a 'name' of your own liking
->add('member_selected', 'rule_name', ['rule' => ['inList', [0,1], false]]);

Related

Laravel - Wrong password generate 'Error' in logs

When a user puts in a bad password, I see it as the level of ERROR in the logs which does not seem like it deserves to be that critical. I alarm off errors so I can understand health of the system. Is there anyway to turn this down to a warning or info...
`production.ERROR: array (
'error' => 'The given data was invalid.',
'errorLine' => 71,
'errorFile' =>
/var/www/html/dashboard/vendor/laravel/framework/src/Illuminate/Validation/ValidationException.php',
'error_catch_scope' => 'report',
'error_catch_file' => '/var/www/html/dashboard/app/Exceptions/Handler.php',
)
I am using laravel 5.7

Laravel localization file format error: array() versus [] format

I am struggling a bit with localization in Laravel 5.3 (with php 7). The default localizaiton file format in Laravel 5.3 is using brackets, as in this example:
return [
'footer.contact.email' => 'Email:',
]
That's what I have been using in my app and it's working fine. But now I am trying to work with some packages to help with translations, for example:
https://github.com/potsky/laravel-localization-helpers
https://github.com/barryvdh/laravel-translation-manager
But both of those generate localization files in the "old" laravel 4.x array format. For example
return array(
'footer' => array(
'contact' => array(
'email' => 'Email:',
),
),
);
As I understand it I should have no issue with this localization file format in my laravel 5.3 app, however it's always throwing an exception:
[2016-12-02 13:26:01] local.ERROR: ErrorException: htmlspecialchars() expects parameter 1 to be string, array given in C:\100_source_code\consulting_platform_laravel\maingig\vendor\laravel\framework\src\Illuminate\Support\helpers.php:519
Stack trace:
#0 C:\100_source_code\consulting_platform_laravel\maingig\vendor\sentry\sentry\lib\Raven\Breadcrumbs\ErrorHandler.php(36): Illuminate\Foundation\Bootstrap\HandleExceptions->handleError(2, 'htmlspecialchar...', 'C:\\100_source_c...', 519, Array)
I really cant understand why this format is not working with my app. I bet it is something trivial that I am missing, but any help would be very welcome!
Thanks,
Christian
After a few extra hours of stepping through the code I found the source of the problem.
For example, I got these in my original lang file:
'footer.subscribe' => 'SUBSCRIBE TO OUR NEWSLETTER',
'footer.subscribe.intro' => 'Be the first to know about our latest news...',
'footer.subscribe.privacy' => 'Privacy Policy',
'footer.subscribe.tos' => 'Terms of Service',
'footer.subscribe.tac' => 'Terms and Conditions',
As I tried to use both of the packages mentioned in my original question they produced the following output:
'footer' =>
array (
'subscribe' =>
array (
'intro' => 'TODO: intro',
'privacy' => 'TODO: privacy',
'tos' => 'TODO: tos',
'tac' => 'TODO: tac',
),
),
As you can see the generated file dropped the value for the text footer.subscribe and only kept the child element, intro, privacy, tos and tas in this case. Therefore a request for trans('footer.subscribe') returns an array and not the text.
Now that I know this I will change the format of my original translation file!
c.

Codeigniter showing problem with date function

I want to insert values into db. I have a table as registration_patients. My code is:
$data = array(
'patients_first_name' => $this->input->post('first_name'),
'patients_last_name' => $this->input->post('last_name'),
'patients_email' => $this->input->post('email'),
'patients_password'=> $this->input->post('password'),
'patients_birth_date'=> date('Y-m-d', strtotime($this->input->post('day') . "-" .$this->input->post('month') . "-" . $this->input->post('year'))),
'patients_sex'=> $this->input->post('sex'),
'patients_telephone'=> $this->input->post('telephone'),
'patients_codice_fiscale'=> $this->input->post('codice_fiscale'),
'account_active'=> 0
);
return $this->db->insert('registration_patients', $data);
Now it is inserted values into database bus showing some error and warning like that
A PHP Error was encountered
Severity: Warning
Message: strtotime(): It is not safe to rely on the system's timezone
settings. You are required to use the date.timezone setting or the
date_default_timezone_set() function. In case you used any of those
methods and you are still getting this warning, you most likely
misspelled the timezone identifier. We selected 'Europe/London' for
'BST/1.0/DST' instead
Filename: models/doctors_model.php
Line Number: 22 and A PHP Error was encountered
Severity: Warning
Message: date(): It is not safe to rely on the system's timezone
settings. You are required to use the date.timezone setting or the
date_default_timezone_set() function. In case you used any of those
methods and you are still getting this warning, you most likely
misspelled the timezone identifier. We selected 'Europe/London' for
'BST/1.0/DST' instead
Filename: models/doctors_model.php
Line Number: 22
In your root_folder/index.php write date_default_timezone_set('America/New_York'); and see if the problem is solved or not. Here is the link of available timezones.

Magento page freeze/blank after account creation

RE: EE v1.10.1.1
Hello,
Recently I've discovered that registration process page freezes after a user submits the form to create an account. It dies on '/customer/account/createpost/'.
Seems to die on this line in the /app/code/core/Mage/Customer/controllers/AccountController.php around line #325 ($session->setCustomerAsLoggedIn($customer);).
It seems to choke on an invalid/empty session when going to set user as logged in. Only after refreshing the frozen page wlll it logs/displays an error. I haven't found any other errors/warnings/messages that are logged... in any of the logs (to include server logs):
a:5:{i:0;s:62:"Mage registry key "_singleton/customer/session" already exists";i:1;s:1247:"#0 /server_path/html/app/Mage.php(192): Mage::throwException('Mage registry k...')
#1 /server_path/html/app/Mage.php(446): Mage::register('_singleton/cust...', Object(Mage_Customer_Model_Session))
#2 /server_path/html/app/code/core/Mage/Customer/controllers/AccountController.php(50): Mage::getSingleton('customer/sessio...')
#3 /server_path/html/app/code/core/Mage/Customer/controllers/AccountController.php(75): Mage_Customer_AccountController->_getSession()
#4 /server_path/html/app/code/core/Mage/Core/Controller/Varien/Action.php(409): Mage_Customer_AccountController->preDispatch()
#5 /server_path/html/app/code/core/Mage/Core/Controller/Varien/Router/Standard.php(253): Mage_Core_Controller_Varien_Action->dispatch('create')
#6 /server_path/html/app/code/core/Mage/Core/Controller/Varien/Front.php(176): Mage_Core_Controller_Varien_Router_Standard->match(Object(Mage_Core_Controller_Request_Http))
#7 /server_path/html/app/code/core/Mage/Core/Model/App.php(340): Mage_Core_Controller_Varien_Front->dispatch()
#8 /server_path/html/app/Mage.php(627): Mage_Core_Model_App->run(Array)
#9 /server_path/html/index.php(95): Mage::run('', 'store')
#10 {main}";s:3:"url";s:25:"/customer/account/create/";s:11:"script_name";s:10:"/index.php";s:4:"skin";s:2:"sg";}
The next line (#326) sends the welcome email. If line #325 is commented out then the email is still sent and, if this is done, the very first attempt to login to their account chokes on '/customer/account/loginPost/' on line #137:
$session->login($login['username'], $login['password']);
Refreshing the page one time displays the dashboard.
Either way the account appears to be created properly and account functionality is normal afterwards, no other login issues.
There have been a few recent changes, but none of them should have anything to do with the customer and/or customer/sessions... at least not that I'm aware of.
By chance does anyone have an idea on any common potential magento pitfalls in code... where I could have done something indirectly in another script/mod that would cause something like this?
I've been going over this way longer than I should and feel I've circled back to the starting point without any leads/success. I kinda feel like I'm missing/overlooking something obvious. Any input, thoughts, suggestions or ideas are appreciated.
Thanks.
Respectfully,
JamesD
[b]Note:[/b] The last time I personally checked this functionality was a month or two ago and it wasn't doing this. I have made/added a few custom mods since, but again they should not be 'directly' connected to customers and/or customer sessions.
Also, over a year ago we did add some additions to the 'customer_login' and 'customer_before_save' events, but there haven't been any issues with them in the past, so I wouldn't think either of these would be the cause.. The only other change would be a Magento upgrade from EE 1.9 to 1.10.
Empty session example....
Here's what the session looks like when the page chokes:
Mage_Customer_Model_Session Object
(
[_customer:protected] =>
[_isCustomerIdChecked:protected] =>
[_skipSessionIdFlag:protected] =>
[_data:protected] => Array
(
[_session_validator_data] => Array
(
[remote_addr] => 155.77.22.255
[http_via] =>
[http_x_forwarded_for] =>
[http_user_agent] => Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11
)
[session_hosts] => Array
(
[www.slimgenics.com] => 1
)
[id] =>
[messages] => Mage_Core_Model_Message_Collection Object
(
[_messages:protected] => Array
(
)
[_lastAddedMessage:protected] => Mage_Core_Model_Message_Success Object
(
[_type:protected] => success
[_code:protected] => Thank you for registering.
[_class:protected] =>
[_method:protected] =>
[_identifier:protected] =>
[_isSticky:protected] =>
)
)
[before_auth_url] => https://www.domain.com/customer/account/index/
[no_referer] => 1
)
[_hasDataChanges:protected] => 1
[_origData:protected] =>
[_idFieldName:protected] =>
[_isDeleted:protected] =>
The error you describe should raise here (magento CE 1.7.0.2 for reference):
// app/Mage.php:472
$registryKey = '_singleton/'.$modelClass;
if (!self::registry($registryKey)) {
self::register($registryKey, self::getModel($modelClass, $arguments));
}
So it is checked immediatly before the registration wether this key exists. I don't think, the EE code does something else. So the question you have to answer is: Why is !self::registry($registryKey) false?
You have luck I dug deeper. I think the creation of the Session-Object fails and returns false. This means the check for the key is true, but the check in Mage::register() failse, because it checks with isset():
// app/Mage.php:216
public static function register($key, $value, $graceful = false)
{
if (isset(self::$_registry[$key])) {
if ($graceful) {
return;
}
self::throwException('Mage registry key "'.$key.'" already exists');
// [...]
The question is: why fails the creation of the session object.
The problem has been solved.
The problem stemmed from a change in a file that I was unaware of.
That change apparently caused a loop (where it was dying) throwing a 'Cannot redeclare' message. Caused from a 'require' statement in a file that was being called multiple times.
The only way I found this out was from a custom API. I used it to test the account creation functionality and fortunately the Soap handler was able to throw the error and log it within the Magento error.log (which it never did before). That 'redeclare' error message was in there and led me to the file that had been changed.
Thanks to all of you for your input.

Magento - Admin view orders error

Within the admin section when clicking to view an order we're getting the following error:
There has been an error processing your request
Invalid method Mage_Adminhtml_Block_Sales_Order_View_Tab_History::isCustomerNotificationNotApplicable(Array
(
[0] => Array
(
[title] => Pending
[notified] => 0
[comment] =>
[created_at] => Zend_Date Object
(
[_locale:Zend_Date:private] => en_GB
[_fractional:Zend_Date:private] => 0
[_precision:Zend_Date:private] => 3
[_unixTimestamp:Zend_Date_DateObject:private] => 1321280177
[_timezone:Zend_Date_DateObject:private] => Europe/London
[_offset:Zend_Date_DateObject:private] => -3600
[_syncronised:Zend_Date_DateObject:private] => 0
[_dst:protected] => 1
)
)
)
)
To me this looks like the default exception of Varien_Object::__call(), which is raised whenever you try to call an unknown method of an Varien_Object instance.
Either you completely missed to define an isCustomerNotificationNotApplicable method in the appropriate class, or the spellings of the defined and the called method do mismatch.
To identify the class causing the exception, I'd append the output of mageDebugBacktrace() in the throw instruction of Varien_Object::__call().
If you get no backtrace output, the exception is probably thrown in a class extending Varien_Object and overriding the __call() method. In that case scan your code for function __call( matches and append the mageDebugBacktrace() output in the found method.
In the end we copied in fresh code files from 1.6.1 and copied them into our path. It all seemed to work fine then.

Resources