Do not show Start date for nodes with Start date not set

How about adding the ability to set new nodes with an Event abiltity to NULL (and thus set no Date for them)?
Just a simple Checkbox that then sets the times to null would do that.

See http://drupal.org/node/20643

Technically 0 is still a date, so I dont want to apply this patch as such. If you have NULL values for start times, does if($node->start != NULL) work?

As I see it, that node types should be avoided because they're actually kind of inconsistency in the database. I mean, maybe you want to add dates to some existing nodes, then the update will fail because there's no row in event table...

So, whatever solution, I think it should be clearly stated in the module settings page, like "You wont be able to add dates to already existing nodes"

About checking for NULL values coming from the db, I'm not sure but I think something like is_null or is_numeric would be better.

Ok, here's a proposal -patch applies to both cvs and 4.6:

+ Added a checkbox, that reads "Save dates and show in event calendar".
This checkbox will be enabled by default for new nodes, and for existing nodes will depend upon the existence of event information for that node.
+ The existence of event data for a node will depend on the existence of a related row in 'event' table.
+ It is possible also to remove event data for a node that already has it, just unchecking this checkbox

As a side effect, this patch also addresses one problem that happens when you have some existing nodes of some type, then enable "events" for that node type and try to set dates for that objects. Currently, the update fails because there was no row in 'event'. But this patch also adds some code to check whether the data is already there, and does an "insert" instead an "update" if not.

All this makes possible to have event data on a node by node basis.

I've been thinking also of adding some additional option in content type configuration, like 'Never/All Views/Only in views.../On a node by node basis', but the problem is that it actually overlaps with the second and third options, thus it would require a new different option, maybe too complex.... ??

I am in principle ok with this patch. I suggest to get some people to test it on an existing installation.

Hrm for some reason I couldn't get this patch to apply.

Ah I see, have to convert it from DOS to UNIX format. I tested and it seems to do the job.

Applied, I'd prefer UNIX style line endings for patches, too.

This new setting confuses me. If I 'event enable' a node I shouldn't be asked every time I create an event if I want the event to show up in a calendar and I want my date saved. I can understand wanting to selectively 'event-enable' a node type but that shouldn't interfere with users who want to input events into their calendar normally.

Reverted patch. Zacker is right, the seting adds clutter. need more thought.

I wouldn't say it adds clutter but it adds "options". And one more option can be, as always happens with options, more confusing for users.
The point is that it fixes some potential data inconsistency, which happens when enabling event info on a node type with existing data. What it really confusing is having event info that is not saved, no errors, no nothing.

But, ok, I can think -an provide a patch- of two options to address your concerns.

1. Just dont show event info for nodes without event info -this would fix the 'inconsistency', but also wouldn't allow to set dates on already existing nodes.

2. Having an additional option, at the content type administration, for having event information on a 'per node' basis. The reason why I didn't implemented this from the beginning is that this option kind of overlaps with "Show in event calendar" option -which maybe would need to be split in two, like "Add event information" (Never, Always, Sometimes) and "Show in event calendar" (all views/only views for this type...)

Please, ideas, suggestions... and I will work out some other patch.

I don't think that information on a per-node basis makes sense if you look at the vent modules as a module for _events_. I agree that it can have benefits for blogs or somethign else, but this is outside the scope of this module.

I agree that we should allow adding of event info to old nodes.

Also, events without end date shoul dbe properly displayed.

Ok, let's go the middle way then?

This updated patch removes that option for normal users, which will be presented with events the old way.

Thus, only administrators ("administer content" permission), will have the option to add or remove event information from specific nodes. This way, admins will have the option to fix -or not- the old nodes without event info.

Patch for 4.6 won't work for 5.x and 4.6 is not getting new features.

Michelle