Came across an interesting issue with cache-blocks the other day when trying to add in audioscrobbling on the block and playing with some other templates.
Have lodged an official bug report with eZ at http://issues.ez.no/11829
Has anyone else experienced this problem as yet?
I have a number of projects on at the moment which involve managing media types and providing editing facilities for the managed assets. Whilst the built-in image management tools in eZ are great for resizing images and the like, they don’t provide for dynamically allowing the users to crop images to preset sizes or the like.
I have surveyed the scene in regards to image management available through PHP/JS and found the Javascript Image Cropper UI by David Spurr. This cool little utility is built on the Prototype and script.aculo.us libraries and has an array of functions for cropping images. The utility itself does not perform the cropping or image management on the server side, but allows the user to interactively choose what they would like done, with the coordinates and related variables being available for passing into whatever script you decide to integrate.
I am going to look at developing a new datatype for eZ over the coming day or two utilising this utility to provide cropping functionality and the ability to create versions/derivative images from the original upload.
As more information becomes available I will let you know and will likely release the results as a contribution to the eZ community.
When working through some changes on this site the other day I noticed the initial permissions shipping with eZ 3.9.3 and above are incorrect for providing comment access to blog posts.
There is a missing class entry in the members policies to allow commenting on the Blog Post class. See below:
Class( Comment ) , Section( Standard ) , ParentClass( Article , Article (main-page) , Blog )
To enable Members to post comments on your blog, you will need to add a new create permission for the Blog Post class (or modify the existing one).
Class( Comment ) , Section( Standard ) , ParentClass( Article , Article (main-page) , Blog post )
This appears to be an issue from 3.9.3 through to 3.10. I haven’t checked 4.0 as yet.
Well thanks has to go to Kristof Coomans for the quick patch on the 3.10 user registration issue. For starters that means you can now register on this site, but it should also make it a lot easier to start rolling out sites on 3.10.
I have included the patch information below:
** Watch out for long lines wrapping below – please copy and paste to a text editor to preserve line breaks ** – will implement a fix on the site for this in near future
Index: kernel/user/register.php
===================================================================
--- kernel/user/register.php (revision 20561)
+++ kernel/user/register.php (working copy)
@@ -163,7 +163,6 @@
// Check if user should be enabled and logged in
unset($user);
$user = eZUser::fetch( $object->attribute( 'id' ) );
- $user->loginCurrent();
$receiver = $user->attribute( 'email' );
$mail = new eZMail();
@@ -193,9 +192,6 @@
$userSetting->setAttribute( 'is_enabled', 0 );
$userSetting->store();
- // Log out current user
- eZUser::logoutCurrent();
-
// Create enable account hash and send it to the newly registered user
$hash = md5( mktime( ) . $user->attribute( 'contentobject_id' ) );
include_once( "kernel/classes/datatypes/ezuser/ezuseraccountkey.php" );
@@ -204,6 +200,10 @@
$tpl->setVariable( 'hash', $hash );
}
+ else
+ {
+ $user->loginCurrent();
+ }
$templateResult =& $tpl->fetch( 'design:user/registrationinfo.tpl' );
$emailSender = $ini->variable( 'MailSettings', 'EmailSender' );
In addition the .patch file can be downloaded from the eZ Issue Tracker at Bug ID: 11598
Special thanks must go to Kristof for aiding in debugging an additional template problem plaguing the registration form on this site, everything is now working properly 
I have been working on the blog again today and have added the ezAudioScrobbler extension from Christian Johansen.
I must thank Christian for this extension, it is quite nice. I have only recently started using last.fm and having discovered their webservices I immediately thought about coding an extension for eZ Publish to output the information onto personal websites, only to find that Christian had already gone to the trouble himself
For those who are interested in doing this themselves download the extension from the http://ez.no contributions area (direct link above). I have utilised the example provided in the README file, with a quick change to the foreach loop to only output the most recently played track. (code below)
{foreach $recent_tracks as $track max 1}
{$track.artist.name} -
{$track.name}
{/foreach}
Very interesting extension and I’m sure it will see wide use throughout the eZ population.
eZ Publish 3.10 has introduced a new bug with the ezenum attribute. It seems that the function storeDefined calls the function removeAttributes which removes all the stored properties for the zenum attribute.
This was initially identified because our Quiqgrids extension utilised an ezenum option to select which grid layout was to be used for the specified row. Due to the depreciation of this attribute and the fact it is currently not working I have since rewritten our Quiqgrids implementation to utilise the ezselect attribute instead.
This issue affects both 3.9.4 and 3.10 versions of eZ Publish. If anyone knows of a workaround let me know. I will post the fix once supplied.
Another nice little bug stemming from 3.10 changes is that user registration is broken. It has been documented at http://issues.ez.no/11598 and seems to be related to changes to the eZUser::logoutCurrent() function.
Currently this issue is affecting this site as well as many others. The listed patches in the eZ Issue Tracker do enable registrations but in cause issues with email delivery for account activation.
I am currently looking at this issue and trying to formulate a suitable patch to resolve.
If anyone else is working on this and comes up with a solution please let me know.
Being involved with eZ Publish at a partner level I fully endorse and promote the system and believe it is by far one of the best enterprise content management frameworks available today.
During the recent release of version 3.10 I had a number of sites I was about to begin working on, this site included, so I decided to take an early-adopter stance and deploy 3.10 for all these sites rather than 3.9. In doing so I have found that cache clearing mechanism is broken.
This affects the admin interface clean up, forced cleanup through the CLI ezcache.php, as well as standard clean ups such as modifying an object.
This bug is a little dangerous because the workaround was to delete the contents of your cache folder manually. Most sysadmins would do this via the CLI and introduce the risk of mistyping the directive and erasing more than they should.
Using the CLI ezcache.php –clear-all –purge worked in some cases to clean up modified objects such as the admin treemenu, but not to refresh all caches.
Bug ID: #011644
View this bug at http://issues.ez.no/IssueView.php?Id=11644
This bug has sinced been rectified by the eZ Crew and pushed into svn as patches for 3.10.1 and 3.9.5. Unfortunately these releases may be weeks away as yet, which leaves current 3.10 users a little out of luck.
HOWTO: Patch 3.10 caching issue
There is only one file to be patched to fix this issue, its location is:
kernel/classes/ezcache.php
You need to modify this file in 4 separate locations:
Within: function clearItem() at Line 345
Find:
$expiryHandler = eZExpiryHandler::instance();
Replace:
$expiryHandler =& eZExpiryHandler::instance();
The exact same change must be made 3 more times at:
Within: function clearImageAlias() at Line 418
Within: function clearContentTreeMenu() at Line 434
Within: function clearTemplateBlockCache() at Line 447
HOWTO: Patch 3.9.4 caching issue
There is only one file to be patched to fix this issue, its location is:
kernel/classes/ezcache.php
You need to modify this file in 4 separate locations:
Within: function clearImageAlias() at Line 370
Find:
$expiryHandler = eZExpiryHandler::instance();
Replace:
$expiryHandler =& eZExpiryHandler::instance();
Disclaimer: I do not recommend nor endorse the modification of kernel files and provide the above instructions for you to attempt at your own risk. I accept no responsibility for whatever stupid action you take that breaks your system.
If anyone would like this and other 3.10 issues patched I am happy to do so for a small maintenance fee. Contact me via the contact form on this site and we can arrange a suitable time