3.4 plans?

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

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

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

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/

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

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

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

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

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