eZ Publish Site Package Error - content-management-system

I am installing ez publish(CMS) in my xampp...
however in this section of installation
SITE PACKAGE
I can't proceed even though I can click next.. I bet the site package is mandatory... I need your help guys... btw, I am installing 2013.5 version
here's the error
Error
Invalid package
Remote repository URL: http://packages.ez.no/ezpublish/5.0/5.0.0/
I've tried uploading the ezwebin_site.ezpkg in the remote repository still I can't proceed... thanks in advance.

Site Package selection step within the Setup Wizard is more or less required (you must select one package using the ratio buttons) to complete a proper eZ Publish installation first time.
Notice the 'Help' sidebar content, "The type of site will choose some basic settings for toolbars, menus, color and functionality. It is possible to change these settings at a later time.".
This is to remind new users that you first use the setup wizard for your first time installation of eZ Publish and then you can re-configure eZ Publish settings, design, extensions, etc manually as much as you desire / require. You can customize almost any part of eZ Publish, once you have it installed and setup properly.
It is recommended for new users to install the 'Website Interface' (with content) package for your first installation. Again you can change all it all after you have completed the default installation and have a working default installation.
More experienced developers may choose to use the 'Plain site' package (with no content, and significantly less default functionality and helpful tools) but this option often causes extreme confusion to new users / developers (who need the tools provided in the 'Website Interface' package to get started using eZ Publish quickly) as it omits expected content classes, default content use case examples, roles / policies, default settings use case examples, ezwebin design extension and much more. As such any package choice other than 'Website Interface' (with the version of eZ Publish you are using) is very strongly discouraged.
Advanced Developers with an already setup installation can create their own site packages to reuse in the future to simplify configuration of a default installation.
Resolution Edit: During an extensive stackoverflow and irc chat it was determined that the user asking the question lacked the WAMP server (PHP modules) support required by eZ Publish 5.x which is why the user was having installation setup problems. Specifically the user was missing the required php curl module which is used / required by the setup wizard to download site packages. The user was strongly recommended to replace Xampp (on win32) with Bitnami (for eZ) which provides for all the requirements of eZ Publish 5.x by default and has already been heavily tested and customized for use with eZ Publish 5.x. Also the user was using an older version of eZ Publish 5.x (2013.5 community build) which only supports PHP 5.3 and the user's Xampp PHP version was PHP 5.6.8 which requires at the very least eZ Publish 5.x (2014.11 community build).

Related

There was an error in the working CMS and I can not even enter to management panel

There was an error in the working CMS and I can not even enter management panel. I did not update PHP on the server, nothing changed in the configuration, and yet I can't enter the administration panel or display the WWW page.
When I try to get on administration panel or on website there is a message like this:
PHP Runtime Notice: Declaration of tx_ttnews_catmenu::wrapTitle() should be compatible with t3lib_treeView::wrapTitle($title, $row, $bank = 0) in /home2/izbampro/public_html/typo3/typo3conf/ext/tt_news/class.tx_ttnews_catmenu.php line 56
Is this a bug related to a too old version of PHP, or could someone break into the server and change the configuration?I have no idea what could have happened, everything worked well several days ago. Please help me with this error.
what do you mean with the administration panel?
in TYPO3 you have the BackEnd where you can do the normal administration and editorial tasks.
it is called normally with domain.tld/typo3/
the other area for administrative tasks is the Install Tool
which is called with domain.tld/typo3/install/
While the Backendneeds a running TYPO3 instance the InstallTool should be callable even if there is no configuration (e.g. database).
regarding your TYPO3 version:
we can guess a little bit with your data:
PHP 5.6.26 will let run TYPO3 only until version 7.6
the function reference t3lib_treeView::wrapTitle will restrict the version in the same way as the classname was available in core up to 4.7. for later version there existed an compatibility extension, first in core, later from TER.
if you have a look onto your server we might have further restrictions.
I will not exclude the usage of older versions up to 4.7:
these versions can be identified by files typo3conf/localconf.php, while since 6.0 the files are named typo3conf/LocalConfiguration.php.
In the same way there is a break in the storing which extensions are active in your installation:
up to 4.7 it was one line in typo3conf/localconf.php, since 6.0 it is an own file typo3conf/PackageStates.php.
You should be able to call the install tool, which will show the version (a screenshot from the appearance after the Install Tool login might help. But first we need to make you accessing the Install Tool.
Are you able to login to the install tool?
the TYPO3 version will decide about the next steps

Domino 8.5.3 - Create an organization extension library / codestore

This is a project I've been working on off and on for months and I feel like I'm pretty close, but I just can't seem to get past the final hurdle.
The goal is to develop an organization extension library that contains both internal and 3rd party code that we frequently rely on.
History
As a test project, I started with Apache Poi because that is already in wide use in our environment. I have a plug-in and feature built just from the Poi .jars that allows me to build our current Poi applications as long as I add the plug-in (from my workspace) to my build path. The apps work on the servers because we have already distributed the Poi .jars by manually copying them.
The next step is taking that plug-in and getting it into an updatesite so that all of the servers and developers can synchronize on one version. I found and followed these two excellent blog articles (that I wish existed when I started this project):
http://www.dalsgaard-data.eu/blog/wrap-an-existing-jar-file-into-a-plug-in/
http://www.dalsgaard-data.eu/blog/deploy-an-eclipse-update-site-to-ibm-domino-and-ibm-domino-designer/
With the caveat that the articles are written for Domino 9 and we are running 8.5.3 here, but that only matters in the last (installation) step.
Current
This brings us to the problem. All of the above seems to have worked great up to a point. I can install my feature to my designer client from the eclipse update site and it works great. However, the install is failing when I import that into our updatesite.nsf database. This means that while the developers can all install from the updatesite if I put it on a network drive, that doesn't deploy updates to our servers.
The problem is that when I try to install from the .nsf update site, the Eclipse Updater just hangs. I've let it go for well over an hour and eventually Notes becomes completely unresponsive.
So the question is, is there anything I might have done wrong, either in the development of the plug-in or server configuration that might be causing this issue?
Additional Info
I'm looking at the osgi console and that is largely unhelpful. I am getting the following errors as I'm trying to install: SEVERE Could not access digest on the site: no protocol: 0/5B004DDD5E38F3FF85257CAF004C72C7/$file/digest.zip ::class.method=unknown ::thread=Worker-7 ::loggername=org.eclipse.update.core
I could generate dumps if that would be useful.
Security is also locked down fairly tight here. It could be a security issue - is there a way to troubleshoot that? Once I get to the hang I'm just stuck guessing.
This has been edited for clarity and to update information
I know that this is post is over 5 years ago but...
for those that find this and are trying to resolve the error
SEVERE Could not access digest on the site: no protocol: "
is due to the update site project not having the URL of the Domino updatesite.nsf not being added to the Archives tab of the site.xml.
I found the updatesite.nsf also needs to be anonymously accessible as no credentials are prompted/passed through to the Domino server hosting the updatesite.nsf database (at least from DDE), YMMV from eclipse. So if Anonymous connections are blocked on the Domino server you will be out of luck.
To develop a plug-in you really want to have 3 projects:
the plug-in
the feature
the update site
Of course a feature can contain more than one plug-in (and probably should) and a update site can contain more than one feature (and probably should). Once you have an update site project it features a handy button "build all" that makes sure plug-in, feature and update-site get compiled in one go. And that button is what you really want.
You can point using a setting in your Domino Designer (or local Domino server) to the feature directory. Add a plain text .link file to framework/rcp/eclipse/links, that contains the path to your install site - it then picks up the features and plug-ins from there. After a build you would need to restart designer/server to activate the updated feature.
For the Domino server the approach using an updatesite.nsf and the respective notes.ini setting makes the most sense (to me). http restart required. Lazy people script the whole thing.
I still don't have a great answer for this, but I believe the issue is related to the environment here. I don't have the authority to change the environment, even if I were able to conclusively demonstrate it is the cause of this problem, so it is a moot point. All I can say is that at least one administrator computer had no issue installing from the update site.
For me, the solution for distributing the update site is to put it on a network drive and have everyone install it from there. The server has no problem using it from the updatesite.nsf.

How create an installer of chrome packaged app?

I need to demonstrate a test version of my app. I DON'T want to load it to the store yet. I want create an installer of my app, so the user can go to my site and install the application by clicking.
First of all, have you read the documentation including developer installation, enterprise installation, publishing on the Web Store only to test accounts, and recent announcements of changes? Assuming you have, then with the exceptions listed in those sources, all apps/extensions must be published in CWS. They don't have to be listed publicly, but they do have to be published there.
Your best bet is to use the test-account feature of CWS for your demonstration.
This is very easy, yo can create the installer vía chrome://extensions > Developer Mode > Package extension.
Then you got the .crx file, you can upload it anywhere and share it. To install it, user must open chrome//extensions and drop the file in the page.
The option to install from webpage by clicking was disabled in Chrome for security reasons.

Building customer based installation packages with install4j

I am developing an application which has customer specific configuration (2 text and 2 binary files). The use case supposes that customer downloads an installation package (I am going to use install4j) and install it on target platform (Mac or Windows). So all installation packages should be different for different customers.
I am considering 2 possible scenarios for implementation:
Generate new installation package per customer request on server side (cons: I need to have install4j for Linux, which is server platform)
Have a half-generated installation package and inject customer data somehow to the package by customer request (cons: I am not sure this is quite possible at all)
I never used install4j before and don't know how to implement 1 or 2. Their documentation is far from ideal. They doesn't have examples or consider cases like this, so any suggestion is very appreciated.
You cannot modify an installer after it has been built. The main reason is that it would break code signing. So you would need to generate a new installer for each configuration. If you deploy on Mac OS X and Windows, you need install4j Multi-Platform Edition which also works on Linux.
Alternatively, you could ask the user to provide credentials in the installer, then you could download the appropriate files on demand with "Download file" actions.

How to automatically upgrade a Firebreath plugin

Recently, I wrote a cross-browser plugin using Firebreath, and I made one installer for all browsers. I searched in stackoverflow for automatic plugin installation, and find a bunch of good answers,
FireBreath plugin automatic installation
Deploying a Firebreath plugin on a webpage without manual installation
Plugin Installation
Deployment of NPAPI plugin with minimal user steps
All answers points out that it needs users’ interaction to download and install the plugin.
My question is that does plugin upgrade follow the same process of first installation, which let users to download the latest installer and install it manually again? Is there any other options to make the plugin upgrade more automatically (less user interaction)?
I also searched this answer a little bit relevant, but it doesn’t tell the way to upgrade a plugin automatically.
firebreath plugin refresh after update
Or I should ask what is the best practice to upgrade firebreath plugin?
Basically there is no good answer to your question, unfortunately. I have had in-place updates working for all browsers (updating in the browser without a restart), but it's fraught with difficulty and extremely fragile. I don't really recommend it.
Probably the cleanest update experience I've seen is by using Google Omaha to do the install and automatic updates in the background. The biggest downside to Omaha is that it's a beast to get set up and working; even just building it requires a lot of work, and then you have to customize a lot of constants and such.
The way I do it is just require that the user download and install an update (MSI or .DMG w/ applescript, depending on the platform) and then just tell them they'll have to restart their browser to get the new version. It's not clean, but it drastically reduces the support requirements.