3.4 plans?

Author Message

Paul Forsyth

Monday 26 January 2004 5:48:22 am

Activity seems to be starting to ramp up on checkins to the trunk, 3.4, on pubsvn. Most of these are fixes that are applied to 3.2 and 3.3 but some things seem new.

Are you working towards a point where plans for 3.4 will be discussed with the community? Can you say when?

Paul

Paul Borgermans

Monday 26 January 2004 6:30:30 am

Paul,

I think a large part of the plans are fixed already.

I asked a few new features and enhancements on our enterprise support that should go into the base distribution:

- <b>passing variables between templates</b> (the main ez site uses this too now)
- an <b>extended notification handler</b> (buggy version in svn, thourough testing and enhancements are occurring as I write for a non-released version)
- a <b>bug free ezobjectrelationlist</b> with possibilities to specify default node assignments in both ini and override templates (already in 3.3, but undocumented) and on/off for creation of new objects or adding only existing objects.

For the rest I hope the current feature set gets more stable and useful, so bugfixing and <b>speed</b> enhancements are the primary objectives for 3.4 afaik

My additional wishes (new features) though for 3.4:
- siteaccess selection based on user groups (can be done easily by modifying index.php)
- improvements of the <b>search engine</b> (configurable relevance ranking, asynchronous or delayed indexing for binary files)
- <b>data import/export</b> between ezp sites
- unicode support for pdf export
- some things that make admin life easier: <b>bulk move</b> and <b>bulk node placement</b> addition of objects, user management (inheritance in user groups)
- post/* triggers: bring back the possibility to have templates thrown up

For 3.5 I would like to see:
- the workflow/trigger system revamped, minimising overhead and more powerful event types for braching /recombining)
- more work on the search engine (this is crucial for any CMS)
- 0.2 sec average response time for single CPU 1Ghz (ie 4x faster a,d towards slashdot proof speeds)
- more collaboration features: assign objects (eg a task) to a user who gets an item in the collaboration inbox.

And in general: when the API in the kernel changes, this should be better documented/announced like the node placement deletion which bugged us

just my thoughts

-paul

eZ Publish, eZ Find, Solr expert consulting and training
http://twitter.com/paulborgermans

Bård Farstad

Monday 26 January 2004 7:21:05 am

We will come with our plans for 3.4 very soon. This will of course be open for suggestions, however we've already taken the feedback we've already got as input for this release. Our focus points: documentation (better structure, complete reference guide), speed ( processing time and memory usage, let's get under the 8MB memory limit ), UI ( improve usability in admin and user sites ), improve packages ( make more functionality available in the packages and make them more general ). And of course we will have one guy dedicated at all times to handle incoming bugreports.

Our goal is to make eZ publish accessable by as many people as possible. We will try to have this information out as soon as possible for you to review.

--bård

Documentation: http://ez.no/doc

Paul Forsyth

Wednesday 28 January 2004 6:33:58 am

The 3.4 plans look good. I assume 3.5 will be focused upon at the conference given that 3.4 is released the week before :)

Will part of the 3.4 documentation phase produce a eZ roadmap? I can imagine that several features considered for 3.4 were delayed instead for 3.5, so it would be nice to see such plans. Our business also needs to know in advance, for hosting and other reasons, the plans to support php5. A roadmap for details such as these would be ideal.

We have thought about other improvements we think are important. Some might be present in 3.3, please say so if they are :)

In no particular order:

- Added security to login - MD5
- Unsuccessful login attempt blocker mechanism, with an ini setting for the number of tries.
- SOAP site status page for Nagios and check tools - allows tests to confirm eZ is alive, db connections are fine, etc.
- Dublin core implemented as standard
- Prevent system from losing cache when you publish any object (not sure if this is fixed in 3.3?)
- Improved shop statistics/reports and real time analysis via admin. This is in addition to the announced shop upgrades.
- Drop down selection boxes for related objects (Maybe in 3.3?)
- Linux based online editor (JAVA etc)
- Advance/basic view when editing articles, so some items can be hidden from view.
- Enable cache to be created per server not per site. This way you can store cache on a local server and mount the main files on an NFS drive.
- When you publish, it should go back to last location not the home folder (Maybe in 3.3?).
- Online editor heading function should more closely match the fonts in the site dependant on the location of the article you are editing.
- Data import wizard. Allows csv columns to be easily mapped to content object fields, command line tools would be nice.
- Extension work:
http://ez.no/community/bug_reports/stabilise_extension_system
http://ez.no/community/bug_reports/use_the_extension_system_for_new_features
- Import/export of content objects
- 2.2 feature 'unpublish/toggle'
http://ez.no/community/bug_reports/not_happy_with_draft_system
http://ez.no/community/forum/developer/toggle_draft
- Documenation for each demo site - what does it contain of worth? What does it showcase?
- Handle depracated funtions better. Show as an error in templates, for example
- List what will spill over into 3.5, or wishes for it. Which features/fixes didn't make it for 3.4?

VisionWT team

Georg Franz

Wednesday 28 January 2004 10:42:32 am

Hi,

I've already made some suggestions in bug report / suggestions and forum / suggestions.

Additional wish for 3.4:
... Newsletter-System / Notification-System which supports multiple site accesses at one db.

I think, it would be a very good plan to focus on
-) bugfixing
-) performance
-) documentation
-) usability

as promised from the ez crew.

Keep on running ...

Bye,
Emil.

Best wishes,
Georg.

--
http://www.schicksal.com Horoskop website which uses eZ Publish since 2004

Lazaro Ferreira

Thursday 29 January 2004 12:33:08 am

Hi,

Also agree with Paul sugestions, as we are almost finished with our first Intranet using EZP 3., we understand that notification, collaboration and workflows (events) should have an upgrade to put it as close as possivel to enterprise level (sorry if the problem is already the lack of documentation )

Regarding the Search Engine, we have researched a bit the current search engine in 3.3-2, and see that 'Or' search and attribute especific search are already in place, at least there is code related there, my question is (is also the question of my Intranet client) which are the plans to release this key search engine features ?

Last, about the capability of passing variable between templates we see it as a critical one, as we don't know which are the workarounds for this now (of course without using PHP)

Lazaro
http://www.mzbusiness.com

Eirik Alfstad Johansen

Thursday 29 January 2004 12:48:57 am

Hi guys,

I thought I would mention one more feature, though it has been mentioned several times before, and that is the possibility of "remembering" users (user sessions stored in cookies). For security reasons, an ini setting could decide whether remembering users is allowed or not.

This feature, AFAIK, should be fairly easy to implement, and is greatly needed for forums and similar functionality which ordinarily requires logging in but doesn't need to be very secure.

Sincerely,

Eirik Johansen

Sincerely,

Eirik Alfstad Johansen
http://www.netmaking.no/

Björn Dieding@xrow.de

Friday 30 January 2004 3:52:42 am

Hi, I would like to see an extra option for the module conten and for multilangual sites.

Currently you can supply an language code to the params that will show all content objects in a that language.

In my option ther soudl be also a language filter the only selects the objetent obejcts that really have3 a translation in the language... It look's like this should be not hard to realise

Oh this filter should be an array ;-)

so a url could like this

/content/view/full/123/ger-DE/filter/ger-DE,eng-GB/year/2004/month/1/

or this filter could be an alias over a ini

like
/content/view/full/123/ger-DE/filter/ALL/year/2004/month/1/

[LanguageFilters]
filter[ALL]=ger-DE;eng-GB;cat-ES

Looking for a new job? http://www.xrow.com/xrow-GmbH/Jobs
Looking for hosting? http://hostingezpublish.com
-----------------------------------------------------------------------------
GMT +01:00 Hannover, Germany
Web: http://www.xrow.com/

Eirik Alfstad Johansen

Saturday 31 January 2004 6:52:42 am

Hi,

Today, nearly all web sites make use of some type of feedback form. I therefore suggest that a Form class should be included as a part of the next distribution. Here's how it could look:

Attribute name | Additional parameters

Title
Recipient
Redirect node
Name | Information collector
Email | Information collector
Comment | Information collector

Also, the content/collectedinfoemail.tpl should be updated to to make use of the recipient and redirect node fields.

Sincerely,

Eirik Johansen

Sincerely,

Eirik Alfstad Johansen
http://www.netmaking.no/

Paul Forsyth

Tuesday 03 February 2004 2:49:51 am

Yesterday we spotted this site:

http://www.md5crk.com/

which basically states how insecure md5 is.

So our suggestion for adding security to logins should use something better, not md5 ;)

paul

Bård Farstad

Tuesday 03 February 2004 3:42:08 am

Paul, we only use md5s to hash the passwords on the server. The password it self is sent using plain text ( normal post forms ), unless you use SSL. You need to get access to the server/database to get this md5 value and then the system is already compromised.

So the md5 hash is really not the weakest link in here.

--bård

Documentation: http://ez.no/doc

Paul Forsyth

Tuesday 03 February 2004 11:18:57 am

Sorry we should have been clearer. Our suggestion referred to encrypting the password instead of sending it as plain text. This is something of a follow up to this thread, many moons ago:

http://ez.no/community/forum/general/possible_major_security_problem

SSL is the best, yes, but there are barriers for people with smaller sites, certification, fixed ips, etc. And for eZ sites we are building, SSL is used only for the payment engine part. It would be nice to protect the password on login.

We are currently testing phpAdsNew and noticed that it uses javascript md5 functions to ensure the password isn't sent over as clear text. This isn't secure i know, but it raises the barriers a little.

On the php manual page for md5:

http://www.php.net/manual/en/function.md5.php

there is a little discussion about adding a random number into the equation to make it more difficult for the attacker - search for 'In respons to paj' for the comment.

What do you think?

Paul, Tony

Bård Farstad

Wednesday 04 February 2004 12:57:43 am

Ahh, ok. Now I see. As for the javascript solution we will most likely not add this since it will require javascript for logins to work. This clashes with the philosophy of eZ publish.

Mabye this could be added as an option though.

--bård

Documentation: http://ez.no/doc

Paul Forsyth

Wednesday 04 February 2004 1:13:42 am

Ok, guess it will be something we will use ourselves. Just to clarify, the examples i mentioned don't require javascript for logins to work. Javascript provides the md5 functions. If javascript isn't enabled the password is still sent by clear text.

btw, what is the ez publish philosophy towards javascript? its used in the admin and heavily in the oe, which is a big reason its ie only.

paul

Bård Farstad

Wednesday 04 February 2004 1:21:05 am

We will not include functions that will not work without javascript. Now we only use javascript to do a "select all" for all visible checkboxes, it still works if you manually check the boxes. OE is not part of eZ publish, it's another product. The IE/Javascript bindings is the main reason for not having OE a part of eZ publish.

But if the javascript/md5 functions works like you say, then it should be no problem to add to the standard distro. Since it will not break any functionality if you don't have javascript. We would gladly add a patch to the current code if you have a working example of this.

--bård

Documentation: http://ez.no/doc

Lazaro Ferreira

Monday 15 March 2004 9:53:14 am

Hi Bard,

I agree on this, we have been using somehing similar to evoid sending plain text passwords in the http stream, this funtionality is part of phplib login functionality : http://phplib.sourceforge.net/

The php code simple try to detect if js is enabled at the browser, if enabled uses a challenge/Response
mechanism, so it never sends the password instead it sends a challenge code using md5 encription, if js is disabled then it sends the password plain

Please, tell me if you need any help on this, phplib includes a working example

 

Lazaro
http://www.mzbusiness.com

Lazaro Ferreira

Monday 15 March 2004 9:59:36 am

Hi,

I would like to remark that import/export of content objects will be very useful, for users (like us) that want to reuse a lot of object implementations from site to site, i.e : User and User group, pre-defined forms, etc

is this implemented or included in any svn version ?

Any plan to include something like this in ezp 3.3-x ?

Lazaro
http://www.mzbusiness.com

Kåre Køhler Høvik

Tuesday 16 March 2004 1:47:40 am

Hi

The contentobject import/export is currently under development. I hope to commit it by Wednesday/Thursday next week. Due to the size/complexity of the implementation, we'll not be able to offer it for 3.3-x.

Upgrading 3.3 site to 3.4 will enable export of the contentobjects you currently have in 3.3. ( Only recommended when 3.4 final is out )

--
Kåre Høvik

Kåre Høvik

Lazaro Ferreira

Wednesday 17 March 2004 10:21:48 am

Thanks for the feedback Kare

Lazaro
http://www.mzbusiness.com

Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2014 eZ Systems AS (except where otherwise noted). All rights reserved.