last time I had issues on loading plugins with aurelia-cli and the component i18next (Error: "Plugin.load is not a function").
The (temporary?) solution was to set the aurelia.json configuration "build.loader.stub" to false (Solution).
Now I have the question what "stub" exactly means and if it's really ok to change this global setting permanently to get that one component working?
What is the impact having that configuration "false"?
In the official aurelia documentation I only found a very rough explanation that I don't understand (Aurelia Doc).
Update 1
According to the aurelia-cli repository discussion with EisenbergEffect:
vegarringdal commented on 28 Jul 2016
#EisenbergEffect
You can close this issue if having the "stub" set to false wont break anything..
EisenbergEffect commented on 28 Jul 2016
Nope. There's no problem with that. Setting stub to true just doesn't embed the full text loader. If you need to dynamically require text, you will just want to set that to false. It's absolutely supported both ways. Our HUB actually sets stub to false.
Related
I have attempted to upgrade a production environment fusion auth instance from version 1.6.x to 1.9.1 unfortunately after the database migration we are presented with error 500 page when browsing to the app.
I have taken a look at the logs which shows the following error:
Sep 24, 2019 4:16:03.726 PM ERROR
com.inversoft.scheduler.LogAndRetainFailureHandler - The scheduled
service [class io.fusionauth.api.service.cache.ThemeCacheLoader]
failed but will be re-run.
java.lang.IllegalStateException: Invalid
message value for theme at
io.fusionauth.api.domain.CachedTheme.loadProperties(CachedTheme.java:40)
at io.fusionauth.api.domain.CachedTheme.(CachedTheme.java:24)
at java.util.stream.Collectors.lambda$toMap$58(Collectors.java:1321)
at
java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169)
at
java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)
at
java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at
java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
at
java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at
java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
at
io.fusionauth.api.service.cache.ThemeCacheLoader.load(ThemeCacheLoader.java:34)
at
io.fusionauth.api.service.cache.ThemeCacheLoader.run(ThemeCacheLoader.java:40)
at
com.inversoft.scheduler.InjectableRunnable.run(InjectableRunnable.java:37)
at
com.inversoft.scheduler.DefaultScheduler.(DefaultScheduler.java:74)
(I have truncated the log output on purpose, if needed I can edit question with full log)
I have also looked in the themes table which contains two entries. The first has a very large JSON object string literal in the data column the second just has any empty JSON object i.e. "{}".
I am reaching out as hopefully this is a simple data issue? Does anyone have any ideas? Thanks in advance
This is a known issue that can occur when you have a custom theme defined prior to upgrade.
A fix will be available shortly in version 1.9.2, a work around is described in the above linked GitHub issue and provided below as well. https://github.com/FusionAuth/fusionauth-issues/issues/306
Workaround:
For each theme other than the default FusionAuth theme
Use the Retrieve Theme API
Set a value for the defaultMessages such as empty string
Update the theme using the Update Theme API
https://fusionauth.io/docs/v1/tech/apis/themes
I was using prestashop on hosting with no problem.
Now I started my home web server and I'm trying to get it working.
I tried many different prestashop versions and reinstalled them x times..
All the time problem is that, I can Access front panel, but not the backend panel..
All the time it shows Http 500 ERROR : Server can't Handle this request.
Now I enabled debugging and it shows me error:
Fatal error: Declaration of AdminLoginControllerCore::viewAccess() must be compatible with AdminControllerCore::viewAccess($disable = false) in C:\xampp\htdocs\Shop\controllers\admin\AdminLoginController.php on line 27
And Line
class AdminLoginControllerCore extends AdminController{
I can't understand why this is happening, becouse I haven't edited and changed any file or folder.
It happens because you have to implement a method in a child class with all parameters of a parent class method. So in your parent class viewAccess has a parameter $disable=false and you need to have it in your child viewAccess() declaration. Just put that parameter in the declaration public function viewAccess($disable=false) and you even need not use it inside. And why it was not showing on the hosting but show in a local machine it is sooner in due to different PHP versions on the servers. Because in different versions it has different error levels.
The way to fix this is simple:
go to ROOT/controllers\admin\AdminLoginController.php
al line 153 you’ll have to change
public function viewAccess() to public function viewAccess($disable = false).
I had that issue with a fresh installation of PS 1.7 yesterday but did'nt come out of it. Today, apparently the same one with PS 1.6.18, thought I was expecting it would'nt, but it seems that PS can't stand PHP 7.2.4, no matter which PS version it is (of course I should have guessed that a previous version would'nt make it better than a recent one ...). Some PHP warnings might have turned into fatal errors now. The fact is, when I went into controllers/admin/adminLoginController on line 153 and typed public function viewAccess($disable = false) instead of public function viewAccess() the blank screen went away and my back-office was there (with some remaining warnings ...). Those files would'nt have to be overwritten to allow upgrade, but anyway 1.6.18 is the last upgrade of 1.6 series... Hope it can help.
I am after something like
firefox['update'] = "never" equivalent in cookbook recipe for firefox as auto updates is causing issues with selenium tests. Could someone please help?
Looking at the attributes provided by the cookbook reveals the following:
default['firefox']['version'] = 'latest'
So setting this to some specific version would be a starting point (not sure if you have set this, as you seem to lack the knowledge how to find the attributes provided by a cookbook.
Regarding actually disabling updates, a quick search revealed this thread, which lists the option that needs to be added to the user.js file in your profile:
user_pref("app.update.enabled", false);
I'm trying to follow the basic cometd example here: http://dojotoolkit.org/reference-guide/1.7/dojox/cometd.html
It's using the old module loader so I tried the equivalent as follows:
require(["dojo/ready","dojo/io/script","dojox/cometd","dojox/cometd/callbackPollTransport"], function(ready, dontcare, cometd) {
ready(function(){
cometd.init('http://localhost:8080/MyCometD/cometd');
comted.subscribe("/test", function(msg){
console.debug(msg);
});
});
});
This doesn't work and I think it has to do with loading modules - there is some sort of silent error as the code within the ready function does not execute at all. What I found is that when the "dojox/cometd" require statement is present, the code within the ready function does not execute.
Running example: http://jsfiddle.net/Q9W8f/2/
Example with dojox/comted removed: http://jsfiddle.net/mMs2h/4/
I haven't worked with the new module loader that much so I bet I just have some simple misconception.
Help!
It seems like youre correct and that there is a 'wait-loop' for a module requirement that never gets loaded. This may be any of the requirements inside dojox.cometd and you'd need to rewrite the codebase for a fix.
I have had similar issue with the RollingListPane, also in dojox repository - and the developers are saying 'we are 100% AMD compliant with 1.7' however the X in dojox is short for experimental. The developement of dojox modules is not done by the core djtk team and there are still glitches..
Try for starters to avoid using CDN which has performed a >>built macro on every single module. This tends to fail at times whilst using AMD. Instead download the tarball and use a local copy - Not compressed (dojo-release-1.7.2-src)
You can find the hello world example in cometD and ExtJs at following link:
http://jksnu.blogspot.in/2013/08/network-reliability-by-cometd-hellow_16.html
I am curious about the proper way to stop a user from activating my plugin if their system does not meet certain requirements. Doing the checks is easy and I don't need any help with that, I am more curious how to tell WordPress to exit and display an error message.
Currently I have tried both exit($error_message) and die($error_message) in the activation hook method. While my message is displayed and the plugin is not activated, a message saying Fatal Error is also displayed (see image below).
Does anyone know of a better way, that would display my message in a proper error box without displaying Fatal error, it just looks really bad for new users to see that.
Thanks for any help in advance.
This is a little undocumented, as you might have noticed. Instead of die(), do it like this:
$plugin = dirname(__FILE__) . '/functions.php';
deactivate_plugins($plugin);
wp_die('<p>The <strong>X</strong> plugin requires version WordPress 2.8 or greater.</p>','Plugin Activation Error',array('response'=>200,'back_link'=>TRUE));
The lines above wp_die() are to deactivate this plugin. Note that we use functions.php in this case because that's where I have my Plugin Name meta data comment declaration -- and if you use a different file, then change the code above. Note that the path is very specific for a match. So, if you want to see what your path would normally be, use print_r(get_option('active_plugins'));die(); to dump that out so that you know what path you need. Since I had a plugin_code.php where the rest of my plugin code was, and since it was in the same directory as functions.php, I merely had to do dirname(__FILE__) for the proper path.
Note that the end of the wp_die() statement is important because it provides a backlink and prevents an error 500 (which is the default Apache code for wp_die()).
It is only a idea though. Try checking the wordpress version and compare then use php to through custom exception/error. PHP 5.0 try catch can be a good way to do it. Here is some resources.
http://www.w3schools.com/php/php_exception.asp
http://php.net/manual/en/internals2.opcodes.throw.php
You can try the first link. It is pretty basic. Thanks! hope the information will be helpful.