eZ blog...

Installing eZ Publish 4.0 on home.pl servers

Sunday, 24 February 2008, 19:49
Categories: Hosting
Tags: eZ Publish hosting, shared hosting, home.pl, FreeBSD, installation, organization, PHP

Home.pl is Poland's largest hosting provider. Despite the fact that they do not have eZ Publish-dedicated services and their machines do not exactly match its standard requirements (FreeBSD, PHP in CGI mode), it is possible to successfully deploy eZ 4.0 installation in their shared hosting environment. Since many people seem to have problems getting through the installation wizard, here's some tips.

Organization

Put the files in a subdirectory and use the subserver functionality (in other words: point the domain to that subdirectory). This is not only because of some possible namespace conflicts (0:/bin is reserved by the system), but also for good organization and easy management. Since a subserver cannot reach above its own root, remember to create a /tmp dir for any temporary files.

Wizard problems

If you try to install version 4.0 from scratch, you may encounter some early problems. This is due to the fact that some systems functions are called during setup tests that cannot handle an error in this environment (which is FreeBSD-like by the way). You can easily cope with that by simply commenting out a line in /kernel/setup/ezsetuptests.php:

$ginfo = posix_getgrgid( posix_getgid() ); // around line 593

This is practically never used again, so don't worry, you may revert the changes after installation, or even leave it like that.

Limitations

For a number of reasons, this hosting will only serve a number of use scenarios. The major problem is a script-like CRON, which works on PHP rights, which means it has the same limitations. It will be impossible to safely run large, exhausting notifications or maintenance scripts... Lack of CLI makes it even harder, and can only be partially compensated by enabled system() PHP function. Still, with a little practice it is possible to tame it, especially with servers' above-average efficiency.

Comments (0)

Brainstorm: *.ini priority vs. extension settings

Tuesday, 19 February 2008, 21:14
Categories: Extensions
Tags: extension, settings, ini, priority, siteaccess, override, brainstorm, ini files, security, convenience, flexibility

Just looking at the priority that the settings files follow:

Gunnstein wrote at http://ez.no/doc/ez_pub...site_management

1. Default configuration settings (/settings/*.ini)
2. Active extension siteaccesses (/extension/*/settings/siteaccess/[name_of_siteaccess]/*.ini.append.php)
3. Siteaccesses (/settings/siteaccess/[name_of_siteaccess]/*.ini.append.php)
4. Active extensions (/extension/*/settings/*.ini.append.php)
5. Global overrides (/settings/override/*.ini.append.php)


It seems like the main/siteaccess/override model for settings files and its advantages weren't introduced to extensions' engine. Here's some issues I see:

1) Let's call it convenience and flexibility: One great feature of the three-step system (and - as far as I understand - one of its key functions) is that we have untouched original *.ini files with all/default settings present, the rest are siteaccess-dedicated or global overrides. This is a great in case of any upgrades, modifications, or simply for reference. I don't see this possibility for extension settings (unless we move the overrides of custom *ini files to the global overrides, but that isn't that convenient we have 10 or 20 extensions...).

2) Security: This actually results from the above. If there is no general override, all your general custom settings will most probably be kept in the main *.ini file. That may include project-dedicated values, passwords, options, etc. The file should then always be called *.ini.append.php, which is easy to forget about.

3) Rules: While with the general settings siteaccesses overrule general files and global overrides overrule all of them, the rules seem less clear with extension settings... that includes both the priorities and the names (look at the security point).

Here's what it could look like (just a quick idea):

  1. Default settings [/settings/*.ini]
  2. Default extension settings [/extension/EXT/settings/*.ini] (only for custom *.ini files)
  3. Extension siteaccesses [/extension/EXT/settings/siteaccess/SITEACCESS/*.ini.append.php]
  4. Siteaccesses [/settings/siteaccess/SITEACCESS/*.ini.append.php]
  5. Extension overrides [/extension/EXT/settings/override/*.ini.append.php] (for custom *.ini files as well as other *.ini files)
  6. Global overrides [/settings/override/*.ini.append.php]

Of course, that would require little changes to directory structure, might be difficult.

I put this on the forum, haven't given this as much thought as I would like to, so... let's see what happens ;)
http://ez.no/developer/forum/suggestions/ini_priority_vs_extension_settings

Comments (2)

Re: Is eZ Publish 4.0 like Microsoft Vista?

Sunday, 17 February 2008, 06:23
Categories: Random thoughts, eZ Components
Tags: eZ Publish 4.0, PHP5, eZ Components, content model, eZ Publish 5.0, maintenance mode, feature freeze, extensions, CMS, hacks, business model, storage model, presentation layer, content management, kernel, lib

Inspired by Bruce Morrison's post in his blog: http://suffandnonsense.blogspot.com/2008/02/is...

eZ Publish 4.0

I kind of understand the disappointment with minor revolution of the current big version 4.0, although I had known (more or less) what to expect when I was awaiting it few months back. You can ask yourself: was PHP5 more of an improvement, or maybe a necessity? If the latter, the smaller was the step ahead, indeed. Nevertheless, I am very glad this step was made, no matter what the version is called, for reasons that must be obvious. Back to the expectations, I can only imagine how 3.x introduction was different (greater) to 4.x, because I've only known eZ Publish since 3.8.x or so (BTW: have to admit I gave up after several attempts with 3.5... it beat me!).

eZ Publish 4.0 maintenance mode, 5.0 eZ Components-based rebuild

Bruce's suggestion is to put eZ Publish 4.0 at its rather stable state into feature freeze mode, while concentrating efforts on taking full advantage of the maturing eZ Components to produce the next big version (5.0) from scratch. I have to say that I like this idea for similar reasons:

  • There's always a risk of ending up with Vista-like model,
  • It will probably take equally long (or even longer) to incorporate majority of eZ Components into eZ Publish (with compromises possible/necessary on the way), than it would have taken to build a completely fresh thing,
  • Past limitations and problems will probably become even more concreted,
  • I believe that eZ Components with all their features would prolong the application's lifespan, secure its potential and make future port to PHP6 easier (I'm not sure if another platform "rewriting" would be a good idea).

There's another thing, but it deserves to be covered in its own paragraph.

Solid content model vs. feature richness

In my comparatively short experience with eZ Publish, I have already dug deep enough to see its few weaknesses, especially regarding the content and storage models. Don't get me wrong, by no means would I call eZ Publish weak, it's just that it has its limitations defined and there are only so many things you can do with it without hacking or severely extending.

Now, I do understand how big part various "rich" features play in the eZ business model and in those of many eZ partners. For example, extensions such as eZ Flow or Web interfaces that make it possible to have an advanced out-of-the-box product with time required for implementation significantly reduced. Having seen how business-oriented eZ people are, I do not expect this direction to be given up at any stage (and I like that).

However, I hope that that direction does not prevent from improving the application at its core, that is the foundation for all eZ business after all. Unlike presentation layer or even more advanced extensions, which can be developed independently, core upgrades would be rather difficult to be introduced by means of hacking the kernel. I'd like to be optimistic, but don't see alternative storage models or advanced class features coming any time soon. New rebuild could be an ideal opportunity to make eZ Publish even more versatile and fit to solve even more advanced content management tasks (and not only!).

Summing up

It doesn't seem like this issue is up for a discussion, but I haven't heard anything official on eZ Publish 5.0, yet. So, maybe it is not too late ;)

If you ask me, I think I could live in this 4.0 feature freeze mode... if what I was waiting for was a completely new eZ Publish 5.0 in a year or two, with even greater core features and as few compromises as possible.

Comments (2)

"Require flag" on the object attribute level

Sunday, 10 February 2008, 20:02
Categories: Lab
Tags: datatype, require flag, content object attribute, attribute, content class, validation, content model

Lately we've been having this discussion with André about different suggestions regarding ways to improve eZ content model:
http://ez.no/developer/forum/suggestions/in...

It was started by my own suggestion to introduce an additional flag that would sort of require objects attributes to be present (or, in other words, impossible to remove from the presentation/XHTML layer). And that actually resulted from my early eZ days questions on how does eZ Publish actually deal with missing attributes...

Back to the additional "require attribute flag"
  1. "Required" flag, that we have today, suggests by semantics that the attribute is required, however, that is not so. I hope I was the only user not to go in depth with this issue, however I expect otherwise. Today's "required" should in my opinion be called "Value required" or "Require value", because that's what the checked flag actually causes.
  2. Why isn't the default behavior of attribute validation such that all attributes are required to be present?
  3. Doesn't lack of all/any of the solution ideas mentioned above (or other) make the editing process vulnerable to any manipulation of the presentation layer? Isn't that comparatively easy to simply omit all uncomfortable attributes, for example datatype-based CAPTCHA, limits, identifiers, etc.?
  4. "Require all required" as a class attribute/flag actually doesn't make much sense with current "Required" meaning. What would it mean? Require all required values? This is why I suggest that there should be a separation of "required flags". We could leave today's required as "Require value" flag, as I suggested above. Then, there should be an additional flag that would decide whether the attribute itself is required to be present in the editing process. This would be much more flexible than earlier "require all required" and at the same time seems to make that idea useless.
Discovery

Well, I finally found some time to look at it again, especially into the eZ Publish kernel. I followed the path that an attribute takes from the edit view all the way to the datatype itself. Actually, I found out that no matter what you do, no matter how you manipulate the presentation layer, the attributes of a content class always reach input validation function in their datatype. So it is up to the given datatype to take further steps, but it's already a good news: it is possible to force attributes without any kernel/lib modifications! Here's an example (ezstring datatype):

function validateObjectAttributeHTTPInput( $http, $base, $contentObjectAttribute )
{
if ( $http->hasPostVariable( $base . '_ezstring_data_text_' . $contentObjectAttribute->attribute( 'id' ) ) )
{
// THE REST OF THE CODE
}
$contentObjectAttribute->setValidationError( ezi18n( 'kernel/classes/datatypes', 'Attribute missing in the presentation layer!' ) );
return eZInputValidator::STATE_INVALID;
}

A quick update on my four points above: I still believe the new flag would be a useful solution. I still believe there's space for both "required flags". I'm still not sure why checking an attributes presence is not default behavior in most (or all) out-of-the-box datatypes. But at least now I have it under control! ;)

And here's how the new flag could work:

function validateObjectAttributeHTTPInput( $http, $base, $contentObjectAttribute )
{
if ( $http->hasPostVariable( $base . '_ezstring_data_text_' . $contentObjectAttribute->attribute( 'id' ) ) )
{
// THE REST OF THE CODE
// Including use of: $contentObjectAttribute->validateIsRequired()...
}
elseif( $contentObjectAttribute->attributeIsRequired() )
{
$contentObjectAttribute->setValidationError( ezi18n( 'kernel/classes/datatypes', 'Attribute missing in the presentation layer!' ) );
return eZInputValidator::STATE_INVALID;
}
}

What do you think?

Comments (0)

eZ My Collected Info - manage your objects' collections

Wednesday, 6 February 2008, 23:32
Categories: Extensions
Tags: informaction collection, collected info, collections

eZ My Collected Info extension gives front-end access to one's collected info. The ownership of the collections is determined based on the ownership of the content object that collected the information. In other words, it is not who sent the information, but whose object it was sent to, that is considered the owner, and thus can browse/read, and optionally delete.

The extension makes it possible to browse though the collections by class and then by object (a tree-like menu is provided for easy access). A detailed class-level configuration is possible to allow/disallow collection deletion, custom identifiers, and custom/default templates.

The extension comes with two module views and two access functions for a flexible management. The standard browsing view can be accessed through: /index.php/siteaccess/mycollectedinfo/browse

Read the settings/mycollectedinfo.ini file's comments for more information.

You can download the extension from: http://ez.no/developer/contribs/hacks/ez_my_collected_info

Comments (0)