Currently we don't support non field dates (user->created) for example. We are *trying* to fix this as soon as possible.

CommentFileSizeAuthor
#28 fullcalendar-1049080-28.patch2.96 KBtim.plunkett
#23 fullcalendar-1049080-23.patch2.51 KBtim.plunkett
#16 fullcalendar-1049080-16.patch11.78 KBtim.plunkett
#15 fullcalendar-1049080-15.patch11.5 KBtim.plunkett
#14 fullcalendar-1049080-14.patch10.04 KBtim.plunkett
#5 fc-indirect_fields.patch1.2 KBben kuper

Comments

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented

We're talking about the following:

node->created
node->changed
users->created
users->access
users->login
comment->created
comment->changed
node_revision->timestamp
node_comment_statistics->last_comment_timestamp
taxonomy_index->created
tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented
Title: Support non field dates » Support non-Field API fields
Priority: Normal » Major

From http://drupal.org/node/1043222#comment-4039750, users->name should be a valid title field.

This is basically a duplicate of #1045530: Properly convert from node view to fields view in a way, in that Views can handle non-Field API fields, and we cant'.

geerlingguy’s picture

geerlingguy commented

That would definitely be a nice fix.

aspilicious’s picture

aspilicious commented

Users-> name is a valid title field under normal situations... (tested users->name and commentID)
That is working, only if you have situations where the info is not directly linked to the entity (in relationship stuff) it doesn't work. But I don't know how to test that. Could someone give me step by step insctructions to break our code :).

Thnx!

ben kuper’s picture

ben kuper commented
StatusFileSize
new fc-indirect_fields.patch1.2 KB

As asked by tim.plunkett, i repost my patch here.
It's not much for now and i don't know if it would fit most situations, but i works for me with a relationship profile->user.
I didn't want to break the current code so my code will run if $entity->title or $entity->url have not been setup by the current code.

There are a lot of data in $vars, i'm sure there is a way to get all the fields data we want without trying at multiple places.

PS : Does anybody knows where i can find the anatomy of drupal's and module's objects? Like a cheat sheet with user object properties and method, as well as node, entity, view.... That could speed up the dev and searching.

aspilicious’s picture

aspilicious commented
Title: Support non-Field API fields » Support non-Field API fields and relationships

How can I reproduce....
How do you do the relationship stuff...

ben kuper’s picture

ben kuper commented

Sorry, i'm a bit tired...
- Create a view (in my case profile view, with both latest profile2 & entity api dev modules).
- Add a profile -> user relationship
- Add a date field (must have created at least one date field in the profile).
- Add a user field (like user name or other, it must relies on the relationship)

In the FC Field settings, choose custom title->[the user field], and optionnally custom date->[the date field].

I guess you can use any view base type with any relationship to reproduce it, as the problem is that in the preprocess function, the fields datas are retrieved from the entity. From what i saw, the fields datas seem to present many times in the $vars, so i think there is a place in $vars where we can retrieve all the datas at once.

I didn't modify the date handling part of the preprocess, so it'll probably won't work if the date field comes from a relationship.

aspilicious’s picture

aspilicious commented

I can't find the profile view (installed everyhting you said)...

ben kuper’s picture

ben kuper commented

I don't know if it's a bug or something i forgot, i couldn't find it for a while too, tried a lot of version, but the patch we were working on entity to support the profile view has been integrated on the last commit (i don't think the downloadable version on the entity homepage is up to date). This is discussed here : #965860: Add views integration
If you downloaded the dev version via the module's homepages, try using the latest cvs version or try applying the entity-views.patch, i don't remember if i had to do it or not.
I also needed to do clear the cache a couple of times to finally see it.
But this is not the only scenario. You can test it with any field that depends on a relationship. If it doesn't belong to the base entity, it won't be found because datas are retrieved from the entity object passed in the $vars.

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented

#9, this issue was split off from #1043222: Remove the node (load) dependency. See comments #5-8 there.

aspilicious’s picture

aspilicious commented

Never mind..

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented
Assigned: Unassigned » tim.plunkett

There is a lot of confusion in this thread.
I know what proffy means, but I can understand why aspilicious is lost.
I'll work on this one soon.

aspilicious’s picture

aspilicious commented 
function options_form(&$form, &$form_state) {
    parent::options_form($form, $form_state);
    $field_options = array();
    foreach ($this->view->display_handler->get_handlers('field') as $id => $handler) {
      if (isset($handler->definition['field_name'])) {
        $field_options[$id] = $handler->definition['field_name'];
      }
      else {
        $field_options[$id] = $handler->definition['title'];
      }
    }
    $date_fields = array_intersect($field_options, array_keys(fullcalendar_date_fields($field_options)));

pasting code from irc

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented
Assigned: tim.plunkett » Unassigned
Status: Active » Needs review
StatusFileSize
new fullcalendar-1049080-14.patch10.04 KB

BOOM.

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented
StatusFileSize
new fullcalendar-1049080-15.patch11.5 KB

Updated to work with $node->created etc. The custom date field doesn't work with it yet, nor does the style validation warning.

Also, URL fields need work.

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented
StatusFileSize
new fullcalendar-1049080-16.patch11.78 KB

Okay, now the validation works.
It also prevents you from dragging or resizing when the date field is a timestamp.

Now onto URLs. Let's see how many patches I get in before aspilicious wakes up.

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented

The custom URL field was intended for use with the link module, and if you choose to output it as "URL, plain text", it works fine.

Also, if you use a custom field (either the global one, or by rewriting it), it works fine.
For example, add Node: Path, and set the Rewrite to be "[path]/edit", and it works.

So I think this needs to be reviewed as is, and the URL thing can be revisited.

aspilicious’s picture

aspilicious commented
Status: Needs review » Reviewed & tested by the community

Tested this very hard. And I still think the url thing is a regression. In previous version you could like to a username and it would be user/name not some kinda html output. OK you can rewrite the output but that is not rly user friendly. We can do that in a followup but it has to get in quickly.

Except for that this is good to go.

(and it works with profile2)

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented

If you uncheck "Link this field to its node/user/whatever", it works just fine. And that's an advanced feature that users of Views may have encountered before. Either way, it needs documentation.

Committing soon.

aspilicious’s picture

aspilicious commented

Not rly the solution, "link to .." field was alrdy unchecked...

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented
Status: Reviewed & tested by the community » Fixed

http://drupal.org/cvs?commit=497390

Link module is also broken in several ways, so the custom URL should live on as its own issue.

geerlingguy’s picture

geerlingguy commented

Sounds good.

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented
Status: Fixed » Needs review
StatusFileSize
new fullcalendar-1049080-23.patch2.51 KB

This was broken if no Field API fields were added to the view, which is now possible with node->created etc.

Here's a fix, loading the entity if it's not present. Needs some code comments, but wanted to get this up here today.

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented

Even though this works, I might try to move some of that into fullcalendar_handler_field_date.inc instead...

aspilicious’s picture

aspilicious commented

Watch out for strict warnings, you can't do all that stuf into the reset.
You need to do:

    $entity = entity_load($entity_type, array($eid));
    $entity = reset($entity);

I'm serious :) my browser is good at complaining.
But it actually works well now :)

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented

I took that directly from core!
modules/file/file.module, line 164, $entity = reset(entity_load($entity_type, array($id)));

What error does it give? How do I make sure I get strict errors?

aspilicious’s picture

aspilicious commented

Use latest version of php, the higher the version the stricter the errors ;).

Strict warning: Only variables should be passed by reference in template_preprocess_views_view_node_fullcalendar() (line 272 of C:\xampp\htdocs\calendar\sites\all\modules\fullcalendar\fullcalendar.module).
tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented
StatusFileSize
new fullcalendar-1049080-28.patch2.96 KB

Changed it in the update function too.

aspilicious’s picture

aspilicious commented
Status: Needs review » Reviewed & tested by the community

RTBC as it is now :)... But maybe you're planning to move the code around.
Nice job :).

I would say it is time for making a default view, and giving the people another alpha.

aspilicious’s picture

aspilicious commented
Status: Reviewed & tested by the community » Fixed

This is committed if I can trust the logs...
Marking this fixed.

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented

Yup, forgot to do my normal "paste the commit message and mark as fixed" routine.

http://drupal.org/cvs?commit=499022

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.