ez projects / cjw_contexthelp / forum / general / usage in admin interface
You need to be logged in to post messages in the forums. New users may register here.
Member since: Posts: 52 |
Wednesday 14 July 2010 6:14:40 pm If I install this extension will it work in the admin interface out of the box?
Or do I have to change the admin templates? -- |
|
Member since: Posts: 7 |
Thursday 15 July 2010 9:56:33 am Hi Marko
the extension contains all the templates needed. Be aware, however, that it has been released and tested under 4.0.1 had we had some issues with installing on later versions. And it will certainly need some reworking for the new admin interface. Regards, Donat http://www.webmanufaktur.ch - Developers united in eZ Publish: http://www.cjw-network.com |
|
Member since: Posts: 79 |
Monday 28 March 2011 3:03:03 am Hi Donat
I may have a client interested in using this on 4.4/4.5, what needs to be done to upgrade this, is it something I could contribute towards getting done? Cheers Australian eZ publish specialist http://www.dbinformatics.com.au |
|
|
Member since: Posts: 75 |
Monday 28 March 2011 10:23:51 am Hi Brendan,
i just uploaded a new package of cjw_contexthelp ( for you ;-) ). http://projects.ez.no/index.php/c...w_contexthelp_2_2_0_201103281009_zip This is working wor us on ez4.4. It would be nice to give us feedback if it is working for you. If you want to have the contexthelp for editors in the admin interface you have to override the edit + edit_attribute.tpl for the admin / admin2 design. This is not done at the moment - we are using it only for the frontend. In the admin we only writing the content for the contexthelp. Please give us feedback - if all is fine or you have something to improve. Cheers Felix http://www.jac-systeme.de - Developers united in eZ Publish: http://www.cjw-network.com |
|
Member since: Posts: 79 |
Wednesday 30 March 2011 4:53:50 am Thanks Felix! I'm feeling very special right now :)
I'll only be using on the public side also, I've installed on 4.2.x and its working great, this site will be getting upgrade to 4.5.0 soon so I'll let you know how I get on with it there too. It's a really useful extension which I'll be using in other projects soon I'm sure, I'll provide feedback as I can. Cheers Australian eZ publish specialist http://www.dbinformatics.com.au |
|
Member since: Posts: 79 |
Tuesday 05 April 2011 11:18:05 am Thought I would report back on things. I've found this extension brilliant and delivering pretty much all I wanted. My only gripe is that I've found the requirement to edit a class and insert stop/stop fieldsets inefficient and frustrating. It isn't a problem on smaller classes but I'm currently mid-way through doing one that uses 129 attributes, 45 of which are "CJW Fieldset" attributes which are required as I'm using several levels of nested fieldsets.
Previously this grouping was handled by templates inserting h2/h3 etc but I'm replacing it with this extension as it offers a lot of advantages. None the less I'm going crazy, I should say I'm this is on a 4.2.0 site also so its probably more eZ Publish's poor class editing interface more than anything else. But having to choose from either a million mouse clicks or doing painful attribute number changes praying that not a single mistake was made in the manual sequential renumbering or you loose everything. Just insane! So a method of controlling fieldsets that didn't rely on class editing would be nice. Any tips to ease my pain, I checked for ajax class editing extensions but couldn't locate one that I could trust on a 4.2.0 production site. Australian eZ publish specialist http://www.dbinformatics.com.au |
|
|
Member since: Posts: 75 |
Tuesday 05 April 2011 11:55:58 am Hi Brendan,
wow - you are a heavy fieldset user ;-) We are using the fieldset feature with a class of 40 attributes 5 of them are fieldset attributes. It is maybe not the best implementation, because every attribute blows up the database. But it was the easiers implementation for us. I have 2 ideas to but the fieldset definition outside of class edit. 1. use an ini setting to define (disadvantage the fieldsetnames you have to put in i18n) 2. use a new contentstructur for fieldsets, like the contexthelp structure to define the fieldsets => extend the operator to get the fieldset structure for a class in edit.tpl The 2. idea i think would be the best way. What do you think? http://www.jac-systeme.de - Developers united in eZ Publish: http://www.cjw-network.com |
|
Member since: Posts: 79 |
Tuesday 05 April 2011 12:43:58 pm While I'm always fond of ini files for sheer speed I think idea 2. is superior, mainly because delivers a consistent user experience within the extension. One great feature is that I'm able to provide a client with direct access to control class descriptions, mouse-over tips etc with out letting them anywhere near the actual classes, this would complete the picture. So option 2 gets my vote.
Are you able to give me a rough idea of when you could do this, it will help me decide what to do from here as I can't leave this class mid-edited and thinking I should roll it back manually. Australian eZ publish specialist http://www.dbinformatics.com.au |
|
|
Member since: Posts: 75 |
Tuesday 05 April 2011 5:18:10 pm This is only an idea how this can be managed.
I do not plan it to implement it until a customer is paying for it. Sorry. http://www.jac-systeme.de - Developers united in eZ Publish: http://www.cjw-network.com |
|
Member since: Posts: 79 |
Friday 08 April 2011 8:11:15 am Fair enough Felix. I soldered on and completed the massive template edit job and will redo it once the new feature arrives.
Do let me know what the ball-park for the cost of this would be as I will contribute if possible. Australian eZ publish specialist http://www.dbinformatics.com.au |
You need to be logged in to post messages in the forums. New users may register here.