Backport to Drupal 6

Hi
as this field is making use of entities and fields, porting this module to cck would require a complete rewrite.
I don't think that this is worth the efforts but anyone who has more experience in cck development and also needs this functionality can feel free to backport it and post it here. (I wont).
Sorry

I'd really love to see this, thanks

Great!

I had a look at it and it's a little hard to properly review differences because this is rather a rewrite than a backport with some changes of the general implementation.

Could you provide me a more detailed list of all changes?

Issues I have with it so far:

• It probably doesn't make much sense to use this module without CCK, what about adding 'content' as dependency?
• Theres no need to get a absolute path to include piwik_stats.field.inc. just doing include 'piwik_stats.field.inc'; does the same without wasting time
• Rather than "Piwik hidden" I'd call the widget "None" like in the current d7 version.
• In the field config there are some form elements that are useless for our usecase and should therefore be hidden: "Help text", "default value", "Global settings" such as "Required" and "Number of values".
• Also I'd rather not mix up the piwik_stats_definitions() with the database field schemas of hook_field_settings(), as piwik_stats_definitions() is this way vulnerable to small changes in the piwik api. Having the piwik api definitions and the piwik_stats table schema seperated makes it a lot easier to handle api changes without messing with the database.
• I've newer worked with CCK's API much, but are you sure about _piwik_stats_field_update()? Is it really necessary to poke around in the database directly, no API functions for this? (I know d6 api wasn't as good as in d7, I just wonder). And if it really has to be done this way, why not using drupal_write_record()?
• A readme would be useful
• The "Piwik XML settings" field settings are nice advanced options but, IMHO too hard to understand and probably not useful for everyone. Maybe it's better to make it optional, collapse the fieldset.

Thinks that should be discussed:

• XML-file cache lifetime - we should figure out whether this is really necessary to expose as setting. IMHO it is not, but maybe I'm totally wrong here
• piwik_stats_last_update is set in piwik_stats_cron_queue_info(), but just because the queue was filled, it does not mean that the fields theirself were updated successfully. We should find a better place for this and port it to d7.
• Porting the "Minimum value for one of the parameters" setting as advanced options to d7.
• Also setting 301 as enabled response code in d7
• Generally try to make the code of the d6 and d7 version as similar as possible to make back and forward patches easier to apply. (Talking about function names, distribution of functions over files, order of functions, etc)

As said, the problem I have with your backport is, that there are too many side-changes that have nothing to do with a simple backport; there are too many changes of the general implementation.
The common way to handle such issues is, first cleanly backporting the module and only make changes where absolutely necessary to work with d6. If then there are alternations needed, open a new issue for each one as feature request / bug report.

Sorry, I just can't push this as it is currently, it would simply take too long to figure out what the "the actual backport" is and what "the new setting you added".

Yes, I understand that my solution is bad and I'll think how improve it.

I'm not sure if it is bad, just wondering whether there's a better way in d6

I hope you don't mind about it.

Sure not :)

I'll try to reduce to zero differences

That would be awesome

I think it'll be useful if field will have a period "all time".

As long we support queued import, that should be no problem to implement and will definitely be worth it
good idea!

Hello!

I do not have git, how could I help with tests? Can you publish a DEV version?