We are not satisfied with ez 3.x

Next topic

Author	Message
Michael Bolien	Sunday 13 July 2003 6:54:25 am I posted this message in comments to the new release announcement already! We did setup a few big sites with special objects and templates, because our customer want ez publish. Ok, we had to to many workarounds for missing features, such as an automatic archive-function or additional database queries. We are working with perl-scripts to build this new features. No problems so far - but the continueing strange changings in ez 3.x, such like the new template behaviour let me think over, if it was a such a good decision to use ez. Although we didn't change anything in the sources, that thing won't work after updating from 3.02 to 3.1.1. So what? After studying the changelogs and the forum articles for a few hour's , we noticed about the new template system with a new override modus. Great! However, we changed every entry in the inis and it is still not working - don't know why, we'll continue with trial and error! A major suggestion in the forum is to build a new database - our smallest database is 12 MB with about 25 new objects. A rebuild would cost us a weeks per site. It can not be, that every update is such a tortuous manoeuvring! If there were a good documentation - but never seen such a lack of support ... so I wonder, if the whole 3.x line is not really be well planned. Maybe you should reconsider the whole thing to release a stable version, next year or so, which will include standards to work a while with and a nice documentation. So there will be much less frustrations on developers side. Michael
Bård Farstad	Sunday 13 July 2003 8:03:25 am Strange that you've got problems with upgrades. I've updated a couple of 3.0 sites to 3.1 without any problem. You will find information about how to upgrade here: http://ez.no/developer/ez_publish_3/documentation/installation_and_configuration/upgrade With the 3.1 release we've added a new template override system for more flexible template overrides. You need to create an override.ini.append for every site access. Details about the override system can be found here: http://ez.no/developer/ez_publish_3/documentation/customization/custom_design/override_templates What excactly are you missing from the documentation? You say that eZ publish is not stable. Have you reported any bugs? What kind of stability problems are you having? If you need support which is guaranteed there are support packages available from eZ systems. -bård Documentation: http://ez.no/doc
Karsten Jennissen	Sunday 13 July 2003 8:35:00 am Hi Michael, sounds to me that you seriously hacked eZ publish (Perl scripts?) and now wonder why upgrading is difficult. While I can very much understand your frustration, this is not the fault of eZ systems. If you do normal customization, i.e. class and template development, workflows etc., upgrading is normally not a problem. If you need to modify more, take a look at extension development (http://ez.no/developer/ez_publish_3/documentation/development/extensions), i.e. how to do upgrade-friendly modifications. Since eZ publish 3.0 was the first stable release of an entirely new architecture, changes in the architecture are likely. I know that in very popular, large open source projects, a stable release X.0 may be planned for to be kept intact for a longer duration. But 3.0 was only the initial release of a new architecture, waiting for feedback from users to be improved. Btw. finding out about the new override system is a matter of 5 minutes going through the changelog that comes with the distribution. Regards, Karsten
Michael Bolien	Sunday 13 July 2003 10:23:56 am Thanks for your immediate answers :o)! Right, I suggest, you have a look at his site: http://physical.vorschauseite.de - it is a site which needed extensive template-reprogramming. You must know, we started to build this site in December. At his time a decision between ez. 2.7 and ez 3.0 had to be made. We started in ez 3.0 RC1 and did all updates until 3.02. The problems now are: - we edited all inis as described, created those override.ini.append.phps. Everything seems to be proper configured. But we don't get access to our site, the admin-interface appears instead. On the other hand, we get only the site. - we did all updates to the database, but in the user-section no user appears. The database still contains all user, but they are not displayed anymore. And finally, our contruction of this site doesn't match the ez-philosophy of views, because we need more sources than one folder per site to show details (e.g. the experiments). So we do a lot of programming with ez Template and have a lot of includes. To match the new template override system, we have to do very much. So - I think we cannot upgrade, I give up. Concerning out perl programming: the scripts are generating static HTML-Sites which will be included in ez via the "include" directive. So, as I pointed out, we changed nothing in the original sources or in the settings-folder. Just to stay upgradeable. Concerning the documentation - as we started, there were no SDK, perhaps rudimentary only. E.g. the fetch-function wasn't documentated, it took days to find out, what that thing do. The only thing we've got was to study the source. Regards, Michael
Karsten Jennissen	Sunday 13 July 2003 11:25:10 am Hi Michael, I probably was a bid harsh before, have been working all weekend, sorry. Anyway, looks like a really big project you did. I really would not give up if I were you. Why don't you consider buying a support package. However, why don't we start to sort things out right here. Let's see. "But we don't get access to our site, the admin-interface appears instead. On the other hand, we get only the site." Could you desribe in more detail? When do you only get the admin, when do you only get the site? What is your configuration (in general terms)? Did you do your design in your own folder? Or did you modify the /design/standard, /design/admin or any other of the shipped files? "we did all updates to the database, but in the user-section no user appears. The database still contains all user, but they are not displayed anymore." Are you talking about the admin site? "our contruction of this site doesn't match the ez-philosophy of views, because we need more sources than one folder per site to show details (e.g. the experiments). So we do a lot of programming with ez Template and have a lot of includes." What would you define as the eZ philosophy in this case? Don't quite understand what you mean by one folder per site. As far as the programming of templates is concerned, upgrading really should not be a problem, as long as you leave the shipped design files intact and create a new design subfolder and start from there. Studying just from the source is really difficult, I agree. Did you follow the build up of the community contributed docs and now the new docs? Maybe there is help in there. Hope we can sort this out. :-) Karsten
Michael Bolien	Monday 14 July 2003 10:40:20 am We're sorry to bother you yestreday, but we were in deep troubles with ezPublish! But, thanks to all for the great support! We made it! After studying the recommended articles and careful thoughts about the new overriding concept, the site runs under ez 3.1.1. Only a few adjustments were neccessary. Btw: there is another little problem: We think about using ezPublish for different complex sites like that physical one. It is a handicap to share articles in different sites with different structures. Our plan is to move all site-structures into subfolders of the root-node. Then we would use the same database and create different sections for the different sites. So we can achieve sharing articles between the sites using the 'add-location'-feature. Is that right? Or does anybody has a better solution? Maybe sharing articles between several databases?
Bård Farstad	Monday 14 July 2003 10:53:01 am Great that you figured it out! Regarding sharing multiple sites with the same installation: this is a good setup for many cases. You can use the permission system to make only articles from one site available from one site access for example. This would use less memory on the server as well. If you would need to run different databases you could still run it on the same eZ publish installation. --bård Documentation: http://ez.no/doc
Michael Bolien	Monday 14 July 2003 11:07:01 am Well, thank you Bård, then we should work on that subfolder-solution. But is it possible to assign editors to subfolders in ez 3.1.1-folder structure? I mean, that editors from different sites could not edit articles from others? Michael
Bård Farstad	Monday 14 July 2003 12:06:09 pm Yes, the permissoin system handles this. You can either use subtree of section to accieve this functionality. --bård Documentation: http://ez.no/doc