Episerver TinyMCE plugin not working after EPI Server 8 upgradation - tinymce

I have implemented a custom tinymce plugin and before epi server up-gradation and it work fine. (In episever 7.5)
After the upgrade in edit mood when i load the editor it says:
"Failed to load: /util/Editor/tinymce/plugins/accordion/editor_plugin.js?moduleArea=Util".
In this other inbuilt plugins are working fine. Only manual implemented plugin arise this 404 error.
Also it failed to load its icon.
So i have added virtual path in web config and worked fine. But i need to fix this issue without adding virtual path. Any help for this ?
referred articles - http://world.episerver.com/documentation/Items/Tech-Notes/EPiServer-CMS-6/EPiServer-CMS-60/TinyMCE-Developers-Guide/

If you by
But i need to fix this issue without adding virtual path.
mean that you do not have a js file that needs to be loaded you can add ServerSideOnly = true
[TinyMCEPluginNonVisual(
PlugInName = "ExtendedValidElements",
AlwaysEnabled = true,
EditorInitConfigurationOptions = "{ extended_valid_elements: 'style' }",
ServerSideOnly = true)]
public class ExtendedValidElements { }
That way no request for
/util/Editor/tinymce/plugins/[PlugInName]/editor_plugin.js
will be made.
Ref: http://cjsharp.com/blog/2013/04/15/how-to-add-valid-elements-like-iframes-to-tinymce-in-episerver-7/#disqus_thread

Related

TYPO3 GeneralUtility Class 0; not found (own generic extension)

After creating my own Extension with the ExtensionBuilder-Package and activating it, I created a repository for the data and set the Storage-PID in the Template-Constants.
Then I created a new page containing the extension (with default values) and on viewing the page the following error appears and the page does not show:
Core: Exception handler (WEB): Uncaught TYPO3 Exception: Class '0;' not found | Error thrown in file /var/www/html/typo3Insy/public/typo3/sysext/core/Classes/Utility/GeneralUtility.php
For the setup I used the TYPO3 version 9.5.23 and have not migrated from a previous one.
Thanks to #Jack70 I found out, that an autoloader needs to be supplied for my own extension in the composer.json-File of the TYPO3-installation itself.
From the composer.json-File of the created extension itself, you can extract the vendor name and the site package. Make sure the case matches when supplying it to the autoloader-section:
"autoload": {
"psr-4": {
"MyVendor\\MySitePackage\\": "pathToTheClassesDirectoryOfYourExtension"
}
}
After that you can simply run composer dump-autoload and this error will be fixed (without restarting the webserver).
I found out about this here: https://wiki.typo3.org/Exception/CMS/1289386765

IBM Content Navigator ICN Plugin returns an error when configured but works fine

I am using ICN 3.0.3 IF7. I have a custom plugin that writes the following error to the console when I initially configure it into ICN.
The plugin itself works fine once configured.
Uncaught TypeError: cls is not a constructor
at Object.eval (ecm/widget/layout/AdminPane.js:9845)
at dojo.js.jgz:22442
at runFactory (dojo.js.jgz:611)
at execModule (dojo.js.jgz:691)
at dojo.js.jgz:397
at guardCheckComplete (dojo.js.jgz:699)
at contextRequire (dojo.js.jgz:396)
at req (dojo.js.jgz:32)
at Object._displayPluginConfig (ecm/widget/layout/AdminPane.js:9844)
at Object._pluginRequestCompleted (ecm/widget/layout/AdminPane.js:9759)
In addition, once it is configured, I cannot get the details on it like I can for the included AFP Viewer plugin:
Name: AFP Viewer
Version: 2.0.3.5
Repository types: None
Actions: None
Open Actions: None
Viewers: AFP Viewer
Features: None
Layouts: None
It seems like something is wrong with the plugin structure that doesn't affect its ability to run. I am worried because I just don't like seeing errors. Has anyone seen this before?
Looking at the error it seems like the module you specified in the plugin.java#getConfigurationDijitClass is either failing to instantiate, or isn't specified at all.
If you have a configuration dijit class configured, then ensure it's actually a widget and that it's constructor and postCreate method (if provided) don't throw an error :).
If you don't have one configured, set it to null to prevent instantiation

Unable to download embedded MongoDB, behind proxy, using automatic configuration script

I have a Spring Boot project, built using Maven, where I intend to use embedded mongo db. I am using Eclipse on Windows 7.
I am behind a proxy that uses automatic configuration script, as I have observed in the Connection tab of Internet Options.
I am getting the following exception when I try to run the application.
java.io.IOException: Could not open inputStream for https://downloads.mongodb.org/win32/mongodb-win32-i386-3.2.2.zip
at de.flapdoodle.embed.process.store.Downloader.downloadInputStream(Downloader.java:131) ~[de.flapdoodle.embed.process-2.0.1.jar:na]
at de.flapdoodle.embed.process.store.Downloader.download(Downloader.java:69) ~[de.flapdoodle.embed.process-2.0.1.jar:na]
....
MongoDB gets downloaded just fine, when I hit the following URL in my web browser:
https://downloads.mongodb.org/win32/mongodb-win32-i386-3.2.2.zip
This leads me to believe that probably I'm missing some configuration in my Eclipse or may be the maven project itself.
Please help me to find the right configuration.
What worked for me on a windows machine:
Download the zip file (https://downloads.mongodb.org/win32/mongodb-win32-i386-3.2.2.zip)
manually and put it (not unpack) into this folder:
C:\Users\<Username>\.embedmongo\win32\
Indeed the problem is about your proxy (a corporate one I guess).
If the proxy do not require authentication, you can solve your problem easily just by adding the appropriate -Dhttp.proxyHost=... and -Dhttp.proxyPort=... (or/and the same with "https.[...]") as JVM arguments in your eclipse junit Runner, as suggested here : https://github.com/learning-spring-boot/learning-spring-boot-2nd-edition-code/issues/2
One solution to your problem is to do the following.
Download MongoDB and place it on a ftp server which is inside your corporate network (for which you would not need proxy).
Then write a configuration in your project like this
#Bean
#ConditionalOnProperty("mongo.proxy")
public IRuntimeConfig embeddedMongoRuntimeConfig() {
final Command command = Command.MongoD;
final IRuntimeConfig runtimeConfig = new RuntimeConfigBuilder()
.defaults(command)
.artifactStore(new ExtractedArtifactStoreBuilder()
.defaults(command)
.download(new DownloadConfigBuilder()
.defaultsForCommand(command)
.downloadPath("your-ftp-path")
.build())
.build())
.build();
return runtimeConfig;
}
With the property mongo.proxy you can control whether Spring Boot downloads MongoDB from your ftp server or from outside. If it is set to true then it downloads from the ftp server. If not then it tries to download from the internet.
The easiest way seems to me to customize the default configuration:
#Bean
DownloadConfigBuilderCustomizer mongoProxyCustomizer() {
return configBuilder -> {
configBuilder.proxyFactory(new HttpProxyFactory(host, port));
};
}
Got the same issue (with Spring Boot 2.6.1 the spring.mongodb.embedded.version property is mandatory).
To configure the proxy, I've added the configuration bean by myself:
#Value("${spring.mongodb.embedded.proxy.domain}")
private String proxyDomain;
#Value("${spring.mongodb.embedded.proxy.port}")
private Integer proxyPort;
#Bean
RuntimeConfig embeddedMongoRuntimeConfig(ObjectProvider<DownloadConfigBuilderCustomizer> downloadConfigBuilderCustomizers) {
Logger logger = LoggerFactory.getLogger(this.getClass().getPackage().getName() + ".EmbeddedMongo");
ProcessOutput processOutput = new ProcessOutput(Processors.logTo(logger, Slf4jLevel.INFO), Processors.logTo(logger, Slf4jLevel.ERROR), Processors.named("[console>]", Processors.logTo(logger, Slf4jLevel.DEBUG)));
return Defaults.runtimeConfigFor(Command.MongoD, logger).processOutput(processOutput).artifactStore(this.getArtifactStore(logger, downloadConfigBuilderCustomizers.orderedStream())).isDaemonProcess(false).build();
}
private ExtractedArtifactStore getArtifactStore(Logger logger, Stream<DownloadConfigBuilderCustomizer> downloadConfigBuilderCustomizers) {
de.flapdoodle.embed.process.config.store.ImmutableDownloadConfig.Builder downloadConfigBuilder = Defaults.downloadConfigFor(Command.MongoD);
downloadConfigBuilder.progressListener(new Slf4jProgressListener(logger));
downloadConfigBuilderCustomizers.forEach((customizer) -> {
customizer.customize(downloadConfigBuilder);
});
DownloadConfig downloadConfig = downloadConfigBuilder
.proxyFactory(new HttpProxyFactory(proxyDomain, proxyPort)) // <--- HERE
.build();
return Defaults.extractedArtifactStoreFor(Command.MongoD).withDownloadConfig(downloadConfig);
}
In my case, I had to add the HTTPS corporate proxy to Intellij Run Configuration.
Https because it was trying to download:
https://downloads.mongodb.org/win32/mongodb-win32-x86_64-4.0.2.zip
application.properties:
spring.data.mongodb.database=test
spring.data.mongodb.port=27017
spring.mongodb.embedded.version=4.0.2
Please keep in mind this is a (DEV) setup.

Docpad Plugin Contactify Issue: docpad is not defined

I am trying to get the Docpad Contactify Plugin to work as expected, but I am not having any luck and I was hoping to get some help here, if at all possible.
So the plugin in question is https://github.com/thaume/docpad-plugin-contactify and it doesn't install properly via nom, so I added it via /plugins/. Anyhow, when running it clean, I get a 'ReferenceError: docpad is not defined' caused by this line...
config = docpad.getConfig().plugins.contactify
so I changed it to...
config = #getConfig()
however then I receive the following error...
TypeError: Object function ContactifyPlugin() {
return ContactifyPlugin.__super__.constructor.apply(this, arguments);
} has no method 'getConfig'
Just looking for a way to send mail and this is the only Docpad plugin that does it, so I am kinda desperate to get it operational. Any input at all would be appreciated!
There appears to be an issue with contactify and the docpad version. I had it running under docpad 6.46 and everything seemed ok. When I updated to 6.66, contactify broke. There seems to be two relevant changes. The context of the plugin seems to have changed so that docpad is no longer directly available in the function(BasePlugin) context and docpad itself no longer has a getConfig method (instead you need to access the config property directly).
Moving the offending code inside the serverExtend method seems to fix the context issue where docpad itself is a property of the plugin this context.
ContactifyPlugin.prototype.serverExtend = function(opts) {
docpad = this.docpad;
config = docpad.config.plugins.contactify;
smtp = nodemailer.createTransport('SMTP', config.transport);
var server;
server = opts.server;
...
Coffeescript version:
serverExtend: (opts) ->
docpad = #docpad
config = docpad.config.plugins.contactify
smtp = nodemailer.createTransport('SMTP', config.transport)
{server} = opts
...

How can I find out what is causing a certain URL to be resolved to a synthetic resources?

On my Adobe CQ 5 (CQ 5.6) installation, for some reason, there's a URL (http://localhost:4503/services) that is getting resolved to a synthetic resource:
This is causing CQ to show the following page, rather than a 404 Page Not Found page:
What is causing this behavior?
You get Forbidden error not because of the strange type of the /services, but because you didn't add any extension (you'll get the same result requesting /content/geometrixx). Let's try to add some extension: .html doesn't really work, but .infinity.tidy.json results in interesting discovery:
{
"tagfilter": {
"sling:resourceType": "/services/tagfilter.servlet",
"servletClass": "com.adobe.cq.social.commons.impl.servlets.TagFilterServlet",
"sling:resourceSuperType": "sling/bundle/resource",
"servletName": "com.adobe.cq.social.commons.impl.servlets.TagFilterServlet"
},
"tagfilter.servlet": {
"sling:resourceType": "/services/tagfilter.servlet",
"servletClass": "com.adobe.cq.social.commons.impl.servlets.TagFilterServlet",
"sling:resourceSuperType": "sling/bundle/resource",
"servletName": "com.adobe.cq.social.commons.impl.servlets.TagFilterServlet"
},
...
It seems that /services is a virtual (or, well, synthetic) path, a parent for servlets. In fact, you can't bind servlet to any path, the most popular choice is /bin prefix, however /services is possible as well. You'll find a list of all such paths in Apache Sling Servlet/Script Resolver and Error Handler OSGi configuration.