I upgraded my Expression Engine installation to 2.7.3 (from 2.3.1). But after upgrading I get an error when trying to view the site.
Error
Unable to load requested field type file: ft.relationship.php.
Confirm the fieldtype file is located in the expressionengine/third_party/ directory
I can see that there is a expressionengine/fieldtypes/relationship/ft.relationship.php and if I go to the admin page I see a field type as being installed there (As “Relationships Version 1.0”).
Why is EE giving me an error at that point?
Per the EE 2.7.3 docs found here:
Changed in version 2.6: Relationships was completely rewritten for this version, adding the ability to create multiple relationships for each entry and introducing a friendly new tag syntax. The template tags described here are not compatible with previous versions.
The foundation of Relationships is very different in the new version, so I would guess that you need an update to which ever third party add-on you're using.
Related
I am taking this one straight from the repo.
I am using this scenario Azure Samples and when I try to upload the base I get the following error (cut for brevity):
The specified page contract 'urn:com:microsoft:aad:b2c:elements:contract:unifiedssp' has invalid version '2.0.0'. The available versions are: '["1.0.0","1.1.0","1.2.0"]'.
Any thoughts on this?
The current available versions for page layout are ["1.0.0","1.1.0","1.2.0"]. You can find the version change log here.
Try to change the version from 2.0.0 to the available version in PasswordlessEmailAndPhoneBase.xml file.
I have an instance of crafter running with crafter-studio-publishing-receiver-2.5.3-aio.jar, I need to locate the source code for the jar file.
Is this the right repository
What is the significance of the word "legacy" in the name of the project?
You can find the source code here:
https://github.com/craftercms/legacy-deployer
The specific version can be found by checking the manifest of the jar.
- unzip the jar
- open ./META-INF/MANIFEST.MF
- locate the property Implementation-Build: 87c84d58313b2bcbdca306de69758320aee174d0
This value can be placed in github to get the exact code you are looking for.
Example:
https://github.com/craftercms/legacy-deployer/blob/87c84d58313b2bcbdca306de69758320aee174d0/cstudio-publishing-receiver-zip/pom.xml
The reason we renamed the project "legacy-deployer" in github is that with Crafter 3.x we are moving to a new deployment system. Without going too deep on this: The new system is based on Git pulls, as you can imagine, this approach has many benefits. It will support the same concepts (callbacks etc) as the now "legacy" deployer.
I'm getting the following error compiling a program using a 3rd party library:
Error:(xx) No resource identifier found for attribute 'tint' in package 'com.example.mycompany.myapp'
The line xx is inside the xml layout that includes a custom component defined in the library.
cntrlco:tint="42"
The xml namespace documentation says I need the following:
xmlns:cntrlco="http://schemas.android.com/apk/res-auto"
Here's my best guess as to the problem, but if you think otherwise please let me know, this is a guess.
I suspect I don't have the library installed completely. The reason is that the library instructions want the library installed from maven. I'm not up on this technique, but it appears to be a web based auto install that automates dependency installs while performing the primary install. Nice idea, but I can't install using the web (long story), so I included the .aar file locally.
From my research, installing .aar files locally won't look at its dependencies. If this is true and the "tint" property is defined in a dependency, then this would explain the error I'm seeing.
Is there a way to follow the error chain in more detail so I can verify my theory? Along the way, will this help me find the name of the possible missing dependencies so I can see if including them fixes the problem.
I'm trying to overwrite a jsp from a LR 7 module, in the bnd.bnd file of the fragment module you have to provide the version:
Fragment-Host: com.liferay.announcements.web;bundle-version="1.0.6"
Let's assume this version is only supported for example in CE GA3, so what will happen if on CE GA2 or GA4 the bundle-version needs to be different to make it work or should i create multiple fragments modules projects in order to support different original module version ?
If I understand you correctly, you're asking if you can override more than one version of a bundle with the same fragment? I don't think you can, but even if you could, you shouldn't.
From the Liferay Docs on overriding a module's JSPs:
Supplying a specific host module version is important. If that version
of the module isn’t present, your fragment won’t attach itself to a
host, and that’s a good thing. A new version of the host module might
have changed its JSPs, so if your now-incompatible version of the JSP
is applied to the host module, you’ll break the functionality of the
host. It’s better to detach your fragment and leave it lonely in the
OSGi runtime than it is to break the functionality of an entire
application.
I have a XPage application where I use JavaMail in one of my managed beans. Currently I have added the jar-file C:\Programme\IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jarto the build-path of the manged bean. This works well. But now I want to use a newer version of JavaMail as the Domino server uses version 1.3 but I need version 1.4.x.
I have downloaded the new JavaMail jar-files from Oracle. In Domino Designer (version 9) I add this jar-file to the new design element "Code / Jars" and remove the old jar-files from the build path.
My managed bean is still compiling and running as desired, but if I check the version the bean is using it reports still version 1.3. To check the version number I use the debug property of JavaMail and it's reporting version 1.3 to the domino server console.
Is there a way to tell the domino server to use the jar-files in the application (i.e. the nsf) and not his own? Is there another approach to update the JavaMail version?
The reason I want to use a newer version of JavaMail is as follows: I want to read mails from an imap server with ssl. To avoid the problem of importing ssl-certificates I simply want to trust all hosts. This can be be done via MailSSLSocketFactory, but this is only available since version 1.4.2. Therefore I want to use a newer version of JavaMail.
Another reason I want to use a newer version is as follows: the method "getSortedMessages" of "IMAPFolder" is only available since version 1.4.4. (and so are some other features of JavaMail).
This may be a little too late for you... I think the right approach may be to include the jar file as an OSGi plugin.
I have spent some time to figure out how to do that - and recently succeeded :-) I have described the steps to perform to make this work in two articles. The first is about wrapping a JAR into a plug-in: http://www.dalsgaard-data.eu/blog/wrap-an-existing-jar-file-into-a-plug-in/ - the second is about deployment (and there is a link in the first one).
/John
You can solve the problem by creating an OSGi plug-in that supersedes the one that sports the JavaMail library: com.ibm.designer.lib.javamail.
In order to do that do the following:
Create an OSGi plugin whose id is com.ibm.designer.lib.javamail (Dalsgaard's tutorial on how to do it)
Set its version to a higher number than the one the Domino server is shipped with (to know the version type tell http osgi ss com.ibm.designer.lib.javamail). As of now using 9.0.1.qualifier should be fine
Deploy the plugin either through an update site or by directly copying it under the domino\workspace\applications\eclipse\plugins folder.
Restart the HTTP service. The higher version - the one you created - will now be used
I've got the same problem here, but found a solution. Be warned, this is not the best answer but it will work. Simply download the latest javamail jar here and rename the jar file to 'mail.jar'. Just replace the current file in IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jar with this file. Quit the http task and restart it. The code will now work with the latest version.