In previous versions of Plone, QuickInstaller took care of automagically removing some stuff on uninstall time; that was the case of browser layers and resource registry resources. Now in Plone 5 is a best practice to include a GenericSetup profile to explicitly uninstall those thins.
I folowed up Keul's blog post on uninstalls and added a browserlayer.xml file to my package uninstall profile as follows:
<?xml version="1.0"?>
<layers>
<layer name="collective.fingerpointing" remove="true" />
</layers>
but my package is not removing it.
any hints?
code is in: https://github.com/collective/collective.fingerpointing/pull/6
test results are in: https://travis-ci.org/collective/collective.fingerpointing/jobs/110195902
I'm just one test away of accomplish compatibility of my add-on!
For unregistering browser layers, the interface is ignored. Only the browser layer name is important. That has to match the name, under which the browser layer was registered before.
The problem was in the test: I was testing against the name of the interface and another package (in my case, plone.app.event) had a browser layer with the same name (IBrowserLayer):
(Pdb) registered_layers()[4]
<InterfaceClass plone.app.event.interfaces.IBrowserLayer>
I was using this:
def test_addon_layer_removed(self):
from plone.browserlayer.utils import registered_layers
layers = [l.getName() for l in registered_layers()]
self.assertNotIn('IBrowserLayer', layers)
I change it to the following:
def test_addon_layer_removed(self):
from collective.fingerpointing.interfaces import IBrowserLayer
from plone.browserlayer.utils import registered_layers
self.assertNotIn(IBrowserLayer, registered_layers())
That's why is important to have the right tests in place.
Related
Goal: To learn how to add an import to a Swift package.
Modus Operandi: Use an Apple-supplied Example as base. Add another import (i.e., Alamofire)
Result: Alamofire does import; but its module "can't be found".
The Package:
The Sources:
Question:
Why is this happening?
What am I missing?
Check the target DeckOfPlayingCards, select the General tab, check Framework, Libraries, and Embedded Contents, make sure Alamofire is on the list
Inside the .target section in your targets section in package.swift file, add your dependencies as like array objects 👇🏻
.target(
name: "DeckOfPlayingCards",
dependencies: ["PlayingCard", "Alamofire"]),
This solved my problem. I was also having the same issue showing No such module "Alamofire". Not only Alamofire but also every other. I forgot to put my dependencies there.
I hope this will help someone sometime.
You know, I spend more time just trying to get things set up to work with Angular than I do actually developing with Angular. There must be an easier way... :(
Currently, I am using the aspnetcore-spa template, creating a project with the command "dotnet new angular" - this is version 1.0.3, which adds Angular 4.1.2 to the npm dependencies. This works great to get a project running quickly. But now I want to add PrimeNG to take advantage of their form controls. I have been struggling with this all day, and would love it if anyone could provide some assistance.
Here is what I have done in my current effort (the latest of many, starting fresh each time):
1) Added to the package.json file: "primeng": "4.1.0-rc.2"
2) Added 'primeng/primeng' to the webpack.config.vendor.js file's vendor collection.
3) Added the following to my test module (which is in turn referenced in app.module.shared.ts so I can route to it via my RouterModule):
import { FileUploadModule } from 'primeng/components/fileupload/fileupload';
And in the html for the module, in an attempt to use the file uploader control, I have (from their site - https://www.primefaces.org/primeng/#/fileupload):
<p-fileUpload name="myfile[]" url="./upload.php"></p-fileUpload>
4) ran "webpack --config webpack.config.vendor.js" from a command prompt at the root of the project folder, which completed with no errors.
Then I hit F5 to run the project, and I got this error:
Exception: Call to Node module failed with error: Error: Template parse errors:
'p-fileUpload' is not a known element:
1. If 'p-fileUpload' is an Angular component, then verify that it is part of this module.
2. If 'p-fileUpload' is a Web Component then add 'CUSTOM_ELEMENTS_SCHEMA' to the '#NgModule.schemas' of this component to suppress this message. (" type="button" (click)="onclick()" class="ui-button-info" label="Click Me">Click Me</button>-->
So, in an effort to comply, I added a reference to the ngprime module to the app.module.shared.ts file, like this (I don't really know how I should reference the module...):
import { FileUploadModule } from 'primeng/primeng';
But got the same exact error.
What am I missing???
Any help would be most appreciated.
I finally have this working, using the asp-prerender-module to get server-side rendering, and not having to rely on the asp-ng2-prerender-module (see my last comment). The trick, I found, was to reference the FileUploaderModule in the app.module.shared.ts file like this:
import { FileUploadModule } from 'primeng/components/fileupload/fileupload';
rather than like this:
import { FileUploadModule } from 'primeng/primeng';
The reason this matters is that the latter method of referencing will load all other components as well (see explanation here: https://www.primefaces.org/primeng/#/setup), and SOME of the PrimeNG components can not be rendered on the server due to DOM-related references (things like "window", which do not exist on the server). See the discussion here for more on this: https://github.com/primefaces/primeng/issues/1341
This change, combined with the other steps listed in my answer and, of course, actually referencing the directive in app.module (thank you #pankaj !) made everything work correctly at last. Only took me about 7 hours to figure it out. :(
What are the strategies to embed a unique version number in a Spring application?
I've got an app using Spring Boot and Spring Web.
Its matured enough that I want to version it and see it displayed on screen at run time.
I believe what you are looking for is generating this version number during build time (Usually by build tools like Ant, Maven or Gradle) as part of their build task chain.
I believe a quite common approach is to either put the version number into the Manifest.mf of the produced JAR and then read it, or create a file that is part of the produced JAR that can be read by your application.
Another solution would be just using Spring Boot's banner customization options described here: http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-spring-application.html#boot-features-banner
However, this will only allow you to change spring-boot banner.
I also believe that Spring Boot exposes product version that is set in Manifest.MF of your application. To achieve this you will need to make sure Implementation-Version attribute of the manifest is set.
Custom solution for access anywhere in the code
Lets assume you would like to have a version.properties file in your src/main/resources that contains your version information. It will contain placeholders instead of actual values so that these placeholders can be expanded during build time.
version=${prodVersion}
build=${prodBuild}
timestamp=${buildTimestamp}
Now that you have a file like this you need to fill it with actual data. I use Gradle so there I would make sure that processResources task which is automatically running for builds is expanding resources. Something like this should do the trick in the build.gradle file for Git-based code:
import org.codehaus.groovy.runtime.*
import org.eclipse.jgit.api.*
def getGitBranchCommit() {
try {
def git = Git.open(project.file(project.getRootProject().getProjectDir()));
def repo = git.getRepository();
def id = repo.resolve(repo.getFullBranch());
return id.abbreviate(7).name()
} catch (IOException ex) {
return "UNKNOWN"
}
}
processResources {
filesMatching("**/version.properties") {
expand (
"prodVersion": version,
"prodBuild": getGitBranchCommit(),
"buildTimestamp": DateGroovyMethods.format(new Date(), 'yyyy-MM-dd HH:mm')
)
}
}
processResources.outputs.upToDateWhen{ false }
In the code about the following is happening:
We defined a function that can take a build number out of the VCS
(in this case Git). The commit hash is limited to 7 characters.
We configure the processResources task to process
version.properties file and fill it with our variables.
prodVersion is taken from Gradle project version. It's usually set
as version in gradle.properties file (part of the general build
setup).
As a last step we ensure that it's always updated (Gradle
has some mechanics to detect if files ened to be processed
Considering you are on SVN, you will need to have a getSvnBranchCommit() method instead. You could for instance use SVNKit or similar for this.
The last thing that is missing now is reading of the file for use in your application.
This could be achieved by simply reading a classpath resource and parsing it into java.util.Properties. You could take it one step further and for instance create accessor methods specifically for each field, e.g getVersion(), getBuild(), etc.
Hope this helps a bit (even though may not be 100% applicable straight off)
Maven can be used to track the version number, e.g.:
<!-- pom.xml -->
<version>2.0.3</version>
Spring Boot can refer to the version, and expose it via REST using Actuator:
# application.properties
endpoints.info.enabled=true
info.app.version=#project.version#
Then use Ajax to render the version in the browser, for example using Polymer iron-ajax:
<!-- about-page.html -->
<iron-ajax auto url="/info" last-response="{{info}}"></iron-ajax>
Application version is: [[info.app.version]]
This will then show in the browser as:
Application version is: 2.0.3
I'm sure you've probably figured something out since this is an older question, but here's what I just did and it looks good. (Getting it into the banner requires you to duplicate a lot).
I'd recommend switching to git (it's a great SVN client too), and then using this in your build.gradle:
// https://github.com/n0mer/gradle-git-properties
plugins {
id "com.gorylenko.gradle-git-properties" version "1.4.17"
}
// http://docs.spring.io/spring-boot/docs/current/reference/html/deployment-install.html
springBoot {
buildInfo() // create META-INF/build-info.properties
}
bootRun.dependsOn = [assemble]
And this in your SpringBoot application:
#Resource
GitProperties props;
#Resource
BuildProperties props2;
Or this way to expose those properties into the standard spring environment:
#SpringBootApplication
#PropertySources({
#PropertySource("classpath:git.properties"),
#PropertySource("classpath:META-INF/build-info.properties")
})
public class MySpringBootApplication {
and then referencing the individual properties as needed.
#Value("${git.branch}")
String gitBranch;
#Value("${build.time}")
String buildTime;
I have been working on a dexterity based plone application.
I have created a couple of new types. This is what I did to activate comments on a specific dexterity content type named "activity_report":
In Plone Control Panel
In the Discussion section I enabled the following:
globally enable comments
enable anonymous comments
In the Types Section
I chose the "Activity Report" type from the drop down and enabled the "Allow comments" option.
On the file system
In the FTI file activityreport.xml:
<property name="allow_discussion">True</property>
I have restarted the instance and even reinstalled the product, but I can not activate the comments section in the dexterity type.
It is worth mentioning that a standard type (ex. Page) can have the discussion module activated.
Is there something I am missing?
plone.app.discussion currently disables commenting for all containers (see https://dev.plone.org/ticket/11245 for discussion).
I used a monkey patch like the following in one project to short-circuit the normal check and make sure that commenting was enabled for my folderish content type:
from Acquisition import aq_inner
from Products.highcountrynews.content.interfaces import IHCNNewsArticle
from plone.app.discussion.conversation import Conversation
old_enabled = Conversation.enabled
def enabled(self):
parent = aq_inner(self.__parent__)
if parent.portal_type == 'my_portal_type':
return True
return old_enabled(self)
Conversation.enabled = enabled
where 'my_portal_type' is, of course, the portal_type you want commenting enabled for.
The David response is not accurate. The class to be monkeypatched is plone.app.discussion.browser.conversation.ConversationView :
from Acquisition import aq_inner
from plone.app.discussion.browser.conversation import ConversationView
old_enabled = ConversationView.enabled
def enabled(self):
parent = aq_inner(self.__parent__)
if parent.portal_type == 'My_type':
return True
return old_enabled(self)
It works for Plone 4.2 at least. However, thanks David for the hint.
As David and Victor already pointed out, you can just override the enable method of the conversation class. I would recommend using the following approach which is a bit cleaner than monkey patching the conversation class:
https://github.com/plone/plone.app.discussion/blob/master/docs/source/howtos/howto_override_enable_conversation.txt
I also added support for dexterity types to plone.app.discussion recently, so as soon as there is a new release you won't need to customize the conversation class any longer:
https://github.com/plone/plone.app.discussion/commit/0e587a7d8536125acdd3bd385e880b60d6aec28e
Note that this method supports commenting ON folderish objects. There is no support to enable/disable commenting for objects INSIDE a folderish object yet.
In case you want to be able to switch on/off commenting with a behavior field/widget:
https://github.com/plone/plone.app.dexterity/commit/0573df4f265a39da9efae44e605e3815729457d7
This will hopefully make it into the next plone.app.dexterity release as well.
I solved in configure.zcml:
<interface interface="Products.CMFPlone.interfaces.INonStructuralFolder" />
<class class="Products.PloneHelpCenter.types.Definition.HelpCenterDefinition">
<implements interface="Products.CMFPlone.interfaces.INonStructuralFolder" />
</class>
UPDATE: this is not a good idea. I had problems with missing Add menu for each content type having this fix.
We're running a Zope server with an eventually large-ish number of Plone (4) sites. Every now and then, an extension product update comes along and requires a re-install to pick up changes in the profile settings, e.g. new content types.
Manually, this would mean clicking through to every Plone site's portal_quickinstaller, tick the products, press update. This is not very feasible if we're talking about dozens of sites, so I'm trying to automate this. Essentially so far, I have the following living as a Script(Python) in the Zope root:
a = context.restrictedTraverse('/')
p = a['Plone']
print p.getSiteManager()
qi = p.restrictedTraverse('portal_quickinstaller')
print qi
qi.reinstallProducts('LinguaPlone')
(Simplified; in reality I have a longer list instead of the single Plone instance, and I might want to reinstall a longer list of products.)
This fails with the following:
Module Products.CMFQuickInstallerTool.QuickInstallerTool, line 613, in uninstallProducts
Module Products.CMFQuickInstallerTool.InstalledProduct, line 272, in uninstall
Module Products.CMFQuickInstallerTool.InstalledProduct, line 351, in _cascadeRemove
AttributeError: 'BaseGlobalComponents' object has no attribute 'objectItems'
From my debugging attempts so far, the BaseGlobalComponents is the Zope SiteManager returned by the zope.component.getSiteManager. How do I convince quickinstaller to pick up the right one, i.e. the one from the Plone Site it's living in?
Alternatively, how would I go about automating re-installing products in a way that will remain vaguely feasible for larger installations? (ETA: I'm aware this is not the kind of thing you do automatically with a cronjob, but updates of inhouse-developed products can't be avoided, I'm afraid.)
Here's how to change the active local site manager. You won't be able to do this in Restricted Python, so you'll need to turn your Python script into an External Method or browser view.
from zope.app.component.hooks import setHooks, setSite
setHooks()
setSite(site)
The setHooks call only needs to be done once. In Zope 2.12 these calls should be imported instead from zope.site.hooks and in Zope 2.13 from zope.component.hooks.
Keep in mind that calling reinstallProducts is not appropriate for all add-on products, and not recommended unless you've carefully checked what reinstalling does and are sure it won't cause problems. Some products provide upgrade steps that run actions more selectively.
Disclaimer: are you sure you want to do this? Automatically reinstalling and upgrading products to the latest version, blindly and without any testing on a staging instance, is asking for trouble.
Anyway, you can do such a thing using XML-RPC and a little tweaking. This is how you install a product on a live running instance using XML-RPC:
>>> import xmlrpclib
>>> proxy = xmlrpclib.ServerProxy(
"http://admin:passwd#localhost:8080/Plone/portal_quickinstaller"
)
>>> proxy.getProductVersion('Marshall')
'2.0'
>>> proxy.isProductInstalled('Marshall')
'False'
>>> proxy.installProduct('Marshall')
'Registry installed sucessfully.\n'
>>> proxy.isProductInstalled('Marshall')
'True'
To reinstall you need subclass Products.CMFQuickInstallerTool.QuickInstallerTool.py and provide you custom QuickInstallerTool with a method that has the keyword argument "reinstall" set as 'True' by default; something like:
442c442
< swallowExceptions=None, reinstall=False,
---
> swallowExceptions=None, reinstall=True,
452,457c452,457
< if self.isProductInstalled(p):
< prod = self._getOb(p)
< msg = ('This product is already installed, '
< 'please uninstall before reinstalling it.')
< prod.log(msg)
< return msg
---
> #if self.isProductInstalled(p):
> # prod = self._getOb(p)
> # msg = ('This product is already installed, '
> # 'please uninstall before reinstalling it.')
> # prod.log(msg)
> # return msg
Even better: provide your own method for gathering information about versions and reinstalling a product, compatible with the XML-RPC protocol (as you cannot pass keyword arguments).
There might be cleaner ways of doing this via XML-RPC, but portal_quickinstaller is not meant to be used in this way and there may be caveats. Use with caution.
I have got this python script in the Zope root of an instance with 7 Plone Sites. Looks pretty much the same as what you have. It might be that it only works on this Plone 2.5 site (yes, old), but I think it should work on 3.x and 4.x as well. Maybe an an innocent looking difference (that I am overlooking) causes the error in your script; maybe the restrictedTraverses that you do trip it up. (Script edited for clarity.)
SITES = ['site-1', 'site-2']
for site in SITES:
print "Reinstalling LinguaPlone in %s." % site
portal = context[site]
qi = portal.portal_quickinstaller
qi.reinstallProducts(['LinguaPlone'])
First don't do a reinstall it can break your website in many cases.
Next you have to consider that add-ons may provide an upgrade step (usually they will). Use the quickinstaller api to achieve this in PythonScript. It is good but it can also be achieved with a script on the file system. Check the examples here: http://svn.plone.org/svn/plone/plone.org/Products.PloneOrg/trunk/scripts/
Another solution can be to use the Selenium IDE to record the quickinstaller stuff in one site and make a copy paste the results of that tests to run it on another website (very weird isn't it ?)