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.
Related
Currently, I have the Elasticsearch service running on version 7.4.0 while my C# Windows Form application is using Elasticsearch.Net version 7.3.1.
I notice I could set the maximum number of results returned from highlight by setting NumberOfFragments which by default is five. However, I could not get the completion/suggestion to return more than five results when I set the following:
var tRes = client.Search<Words>(s => s
.SuggestSize(20) // How many suggestions to return in response
.Suggest(su => su
.Completion("name", cs => cs
.SkipDuplicates(true)
.Field(f => f.Suggest)
.Prefix(tbInput.Text)
.Regex("*")
.Size(20))
)
I received the following error message when I execute the above query.
{"The remote server returned an error: (400) Bad Request.. Call: Status code 400 from: POST /docproperty/_search?typed_keys=true&suggest_size=20. ServerError: Type: illegal_argument_exception Reason: \"request [/docproperty/_search] contains unrecognized parameter: [suggest_size] -> did you mean [suggest_field]?\""}
Update
I manage to get more than 5 results by adding the following:
var tRes = client.Search<Words>(s => s
.Size(20)
.Suggest(su => su
.Completion("name", cs => cs
.SkipDuplicates(true)
.Field(f => f.Suggest)
.Prefix(tbInput.Text)
.Regex("*")
.Size(20))
.Term("", t=>t.ShardSize(20).Field(f=>f.Suggest).Text(tbInput.Text))
)
);
However, this time I notice that I could not get the completion to return words (a lot of missing ones) that could be found when I execute a MatchPhrase.
I think if you look at the documentation, I think it's not meant to be suggestSize. I think it should be size only.. not sure if this supports chaining.
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-suggesters.html
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.
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]]);
I am setting my own MediaWiki website locally, and am not able to get the InstantCommons feature to work (used to directly embed files from commons.wikimedia.org).
I get no error message, the files I try to load from Commons using the following syntax:
[[File:Cervus elaphus Luc Viatour 1.jpg|Cervus elaphus Luc Viatour 1]]
are just not loaded, and I end up with a red link on my page, referring to a non-existing file. It has been 2 days now that I am looking for a solution, but so far without any success.
I am running:
MediaWiki v.1.19.1
Fedora 16 (with SElinux)
PHP 5.3.15
MySQL Ver 14.14 Distrib 5.5.25a, for Linux (x86_64)
I have tried the following two configurations in my LocalSettings.php, without success:
$wgUseInstantCommons = true;
AND
$wgForeignFileRepos[] = array(
'class' => 'ForeignAPIRepo',
'name' => 'shared',
'apibase' => 'http://commons.wikimedia.org/w/api.php',
'fetchDescription' => true, // Optional
'descriptionCacheExpiry' => 43200, // 12 hours, optional (values are seconds)
'apiThumbCacheExpiry' => 43200, // 12 hours, optional, but required for local thumb caching
);
Any suggestion is most welcome.
OK, this is not (yet) an answer, but a debugging suggestion. It looks to me like the HTTP request from your server to Commons is failing for some reason, but unfortunately ForeignAPIRepo doesn't indicate the cause of the error in any way.
This is really a bug in MediaWiki, and should be fixed, but in the mean time, could you please try applying the following diff (or just manually adding the line marked with the + sign) to your includes/filerepo/ForeignAPIRepo.php file:
Index: includes/filerepo/ForeignAPIRepo.php
===================================================================
--- includes/filerepo/ForeignAPIRepo.php (revision 97048)
+++ includes/filerepo/ForeignAPIRepo.php (working copy)
## -385,6 +385,7 ##
if ( $status->isOK() ) {
return $req->getContent();
} else {
+ wfDebug( "ForeignAPIRepo: HTTP GET failed: " . $status->getXML() );
return false;
}
}
After applying it, try loading the file description page for a Commons image and look at the MediaWiki debug log. There should now be a line starting with ForeignAPIRepo: HTTP GET failed: followed by a few lines of XML error dump. That error data should hopefully indicate what's going wrong; please copy and paste it here.
Mine is not a definitive answer either. Referring to Ilmari Karonen's post, I was unable to find or get the getXML() method to execute for my version of Mediawiki v1.23.0. I was looking at the reference documentation found here to try and find any other method calls on the Status class that would give me good troubleshooting info. I ended up finding the following and editing the same file as mentioned in Ilmari Karonen's post includes/filerepo/ForeignAPIRepo.php beginning at line #521:
if ( $status->isOK() ) {
return $req->getContent();
} else {
$error = $status->getErrorsArray();
$dump = print_r($error, true);
wfDebug("ForeignAPIRepo: HTTP GET failed: $dump\n");
return false;
}
The default InstantCommons configuration of older MediaWikis is a bit silly. Due to T114098 I recommend one of the following, which will hopefully fix your problems:
upgrade to MediaWiki 1.27 (when it's released), or
set your LocalSettings.php to hotlink images to save on server-side requests and processing.
$wgUseInstantCommons = false;
$wgForeignFileRepos[] = array(
'class' => 'ForeignAPIRepo',
'name' => 'commonshotlink',
'apibase' => 'https://commons.wikimedia.org/w/api.php',
'hashLevels' => 2,
'url' => 'https://upload.wikimedia.org/wikipedia/commons',
'thumbUrl' => 'https://upload.wikimedia.org/wikipedia/commons/thumb',
'transformVia404' => true,
'fetchDescription' => true,
'descriptionCacheExpiry' => 43200,
'apiThumbCacheExpiry' => 24 * 3600,
);
We have a cakephp app running on 2.0 and we seem to be having some encoding issues with Firefox.
The URL we are accessing is /newcms/core/users/index/conditions[User][group_id]:6 to apply a filter in out cms system.
In everything but FireFox we get the following on the request object
[params] => Array
(
[plugin] => core
[controller] => users
[action] => newcms_index
[named] => Array
(
[conditions] => Array
(
[User] => Array
(
[group_id] => 6
)
)
)
[pass] => Array
(
)
[prefix] => newcms
)
Which is correct and everything works fine, if we goto the same URL in FireFox we get
[params] => Array
(
[plugin] => core
[controller] => users
[action] => newcms_index
[named] => Array
(
[conditions%5BUser%5D%5Bgroup_id%5D] => 6
)
[pass] => Array
(
)
[prefix] => newcms
)
I have tried URL encoding the named condition value but with no luck..
Any suggestions?
It's probably not a great idea to be using brackets and an array structure in your URL.
Why not just use something like this?:
/newcms/core/users/index/user_group:6
Then process the data in the controller.
Well after a bit of digging and playing around the latest version of cake in GitHub has fixed this FF issue (https://github.com/cakephp/cakephp/commit/e6905b44c3d4512b6989c59a1489bc983d88bcdc).
There is nothing incorrect about passing square brackets in the URI it was just an issue with the way FF encoded them differently than the other browsers.