After migrating from Plone 3.3.2 to 4.3.6, the result when accessing a forum item is simply:
<Products.Five.metaclass.ConversationView object at 0x7f24404e3a50>
There is no trace, error or log entry.
The buildout.cfg file used contains the following:
eggs =
Plone
Pillow
archetypes.kss
collective.captcha
plone.app.caching
plone.app.discussion
plone.app.registry
plone.app.kss
plone.openid
plone.registry
Products.ATReferenceBrowserWidget
Products.Clouseau
Products.CMFNotification
Products.CMFPlacefulWorkflow
Products.DocFinderTab
Products.kupu
Products.NuPlone
Products.Ploneboard
Products.PloneboardNotify
Products.PloneFormGen
Products.ResourceRegistries
Products.SimpleAttachment
zope.app.container
zope.app.cache
zope.app.component
zope.app.pagetemplate
zope.app.publisher
zope.copypastemove
zope.dublincore
zope.hookable
...
[versions]
buildout.sanitycheck = 1.0b1
Cheetah = 2.2.1
collective.recipe.backup = 2.20
Pillow = 2.6.1
plone.recipe.command = 1.1
plone.recipe.unifiedinstaller = 4.3.2
Products.DocFinderTab = 1.0.5
setuptools = 7.0
zc.buildout = 2.2.5
ZopeSkel = 2.21.2
zopeskel.dexterity = 1.5.4.1
zopeskel.diazotheme = 1.1
Products.Ploneboard = 3.4
Any ideas of what may be causing this?
Thank in advance,
#joao the type "Discussion Item" is shipped with plone by default. it's not releated to ploneboard.
according to the type definition
the conversation type should use conversation_browserview as deault view.
try to call the url http://yoursite/path/to/forum/conversation/##conversation_browserview
if this works without problems, you need to update PloneboardConversation in portal_types to use this view as default view.
If you still get the error try the latest code from master and file a ticket if it still persists.
It seems a problem in the default view of the object.
Check in ZMI -> portal_types -> your content type
Related
I'm in trouble with the "local translation" override by buildout configuration. I would like to override some standard labels of plone using the extra conf parameter "zope_i18n_compile_mo_files" with a folder placed in the buildout's directory (plone 4.3) : "locales/it/LC_MESSAGES/plone.po"
In another Plone 4.1 installation it works well. The only difference between these installations are the plone version (4.1 vs 4.3) and the architecture (stand alone vs zeo cluster).
This is the piece of my buildout:
[instance-settings]
user = admin:admin
debug-mode = off
verbose-security = off
blob-storage = ${buildout:directory}/var/blobstorage
effective-user = ${config:system-user}
products = ${buildout:directory}/products
eggs =
${plone:eggs}
zcml =
${plone:zcml}
resources = ${buildout:directory}/resources
environment-vars =
PTS_LANGUAGES it en
LANG it_IT.utf8
TZ Europe/Rome
zope_i18n_allowed_languages it en
zope_i18n_compile_mo_files true
What's the problem?
You need to register that locales directory. I do not see that in your buildout config. Something like this:
[instance]
recipe = plone.recipe.zope2instance
locales = ${buildout:directory}/locales
See https://github.com/mauritsvanrees/maurits.i18ntalk/blob/master/talk.rst#buildoutcfg
i’m trying to install the latest Ploneboard (v3.6) on a Plone 4.2 site, but getting the error
The version, 2.13.11, is not consistent with the requirement, AccessControl>=3.0
i see that the most recent Ploneboard change log for this version mentions "Fixed dependency for AccessControl. Plone < 4.3 have an old version pinned [cekk]”
anyone see what is wrong in this picture? thanks for any clues.
Since version 3.6 PloneBoard requires AccessControl>=3.0.
The Problem in your case is, that Plone 4.2.x has an older version pinned:
Check: http://dist.plone.org/release/4.2-latest/
If you run ./bin/buildout annotate | grep -C 5 AccessControl.
You will see which buildout configuration pins the version of AccessControl.
...
[versions]
AccessControl= 2.13.13
http://dist.plone.org/release/4.2-latest/versions.cfg
...
In your case you need to override this version pinning in your buildout.cfg (or versions.cfg).
[versions]
AccessControl = 3.0.8 # For example
I don't know which version of AccessControl works with Plone 4.2.x.
But 3.0.x seems suitable.
This blog gives a summary of how to use buildout when download.zope.org is down http://devblog.4teamwork.ch/blog/2013/06/06/download-dot-zope-dot-org-is-down-how-to-fix-buildout/ however it is specific to Plone 4.2.
How do I go about getting a similar cache for Plone 4.3.1 so that my buildout won't fail when download.zope.org is down?
In the case of this particular outage, you don't need a cache[1]: you need a valid extends = target. I've just fixed my Plone 4.3 buildout to avoid download.zope.org[2]. This should work for you:
[buildout]
extends = https://raw.github.com/plock/pins/master/plone-4-3
[plone]
#eggs +=
[1] Because Plone extends configuration files located on download.zope.org: http://dist.plone.org/release/4.3.1/versions.cfg
[2] As soon as a find the appropriate Zope configuration files, I'll fix 4.3.1 too.
name = MagApp 1.0
description = Magapp module that enables MagApp powered publications.
core = 7.x
php = 5.1
package = MagApp
dependencies[] = references
dependencies[] = node_reference
dependencies[] = magapp_core_content_types
version = "7.x-2.0"
I have been created a module and the info file is written above is there any problem while changing the php version , Because i did it before months , so i have to update this module , Can i add dependencies directly without using modules .
Search the source of /modules for admin/structure and check how they built that *_menu() hook.
If you have access to the server and it's running *NIX you could do:
grep -ri 'admin/structure' your_site_directory/modules/*
And then you can implement your own hook_menu() in your own module. Might also be possible in the Structure -> Menu system of the web UI. I don't recall.
While Zope 2.13 have native wsgi support, I haven't been able to find any documentation/deployment tutorial/article/blog yet.
Would anyone point/post a working example ?
The reason is that while Zope 2's WSGI support is a starting point, there are still lots of rough edges, and as a result, WSGI is not yet an officially supported or "recommended best practice" deployment option. However, you might find http://smith-li.com/wordpress/2011/05/31/plone-4-1-with-apache-and-mod_wsgi-sorta/ useful as a starting point.
Try the following:
http://pythonpackages-docs.readthedocs.org/en/latest/ex5.html#wsgi-powered-plone-setup
The buildout referenced in that document (http://build.pythonpackages.com/buildout/plone/4.2.x) is as follows:
[buildout]
allow-hosts =
*.plone.org
*.python.org
extensions =
buildout.bootstrap
mr.developer
extends = http://dist.plone.org/release/4.2b1/versions.cfg
extends-cache = .
find-links = http://dist.plone.org/thirdparty/elementtree-1.2.7-20070827-preview.zip
parts =
mod-wsgi
plone
wsgi-conf
versions = versions
[plone]
recipe = plone.recipe.zope2instance
eggs =
PasteScript
Pillow
Plone
Products.PloneHotfix20110928
WebError
repoze.retry
repoze.tm2
repoze.vhm
products =
user = admin:admin
scripts = paster
[versions]
distribute = 0.6.24
# Error: Setup script exited with error: src/config.h: No such file or directory
# Error: Couldn't install: pycrypto 2.4
pycrypto = 2.3
zc.buildout = 1.5.2
[mod-wsgi]
recipe = collective.recipe.modwsgi
eggs = ${plone:eggs}
config-file = plone.ini
[wsgi-conf]
recipe = collective.recipe.template
url = http://build.pythonpackages.com/buildout/plone/plone.ini.in
output = plone.ini
[versions]
Zope2 = 2.13.11
Please note that a newer Zope2 is used than the one that is likely to be shipped with Plone 4.2. This is due to the fact that the 2.13.11 release adds support for doing WSGI without requiring repoze.who for authentication (which effectively increases the "convenience factor" quite a bit.)