Support "Global: Custom Text"

Very expimental support for this added in Commit #205e825.

Followup: while testing #2064003: #039 character codes display in block timeline titles, I discovered this does not work for fieldnames containing underscores. Basically the explode() should be limited to split things into 2 pieces, otherwise your fieldname will be ripped apart.

I haven't tested extensively, but got a 'global text field' to show as my 'headline' field, after applying this...

AFAICT I have all the commits/patches above installed.

I added a Global: Custom Text field to my View (Block) - just set to render a simple string at the moment.
I'm trying to map the timeline TAG to this Global: Custom Text field in the settings for timeline.

The problem is that the Global: Custom Text field is not showing up as a "source" option for TAG.

The commits/patches above contain e.g.
In PLUGINS/text_sources:

$plugin = array(
  'name' => t('Global: Text area for TimelineJS'),
  'handler_name' => 'views_area_field',
  'field_type' => 'area',
);

I'm not quite sure how this gives me Global: Custom Text
1. is views_area_field the custom text?
2. the plugin above is PLUGINS/text_sources - should something similar be in PLUGINS/tag_sources for this to work?

To partially answer my own question, the Global: Text Area IS available in the Footer / Header.
If you define such a field there, it does appear as an option for FIELD-MAPPING for fields of type "text".

But not, obviously, for type "tag".

So I'm still stuck. Either I need to write a new "tag" source that picks up Global: Custom Text or I need (somehow) to get "rewrite results" to work for the tag sources already present; then I can use Replacement Patterns.

I've been through this issue queue and tried just about all the patches, but can't get global fields to show up as options in the select lists.

So I'm still stuck. Either I need to write a new "tag" source that picks up Global: Custom Text or I need (somehow) to get "rewrite results" to work for the tag sources already present; then I can use Replacement Patterns.

yep... pretty much in the same boat. I need custom text for the bodytext and neither rewriting nor global fields work. They should probably both work, but I lean more toward global fields since they would provide more flexibility.

anyone get this working with the current dev yet?

I'm still reading through the code, but a thought just occurred to me-- why does the plugin care about limiting the fields in the first place?

In other views plugins that do something similar, the field drop down is just a drop down of all the fields in the views. If you as a user, select something that doesn't make sense (ie plain text for a field that is expecting a url), then it's on you. We could simplify the code greatly if we refactored that way.

Ok, I've worked with this some more and I understand why date, media, and tag fields need to be plugins, but all view fields result in some sort of text that should be usable for the headline and body elements in the timeline.

Also, I can't figure out why header/foot/empty text as timeline item data was added-- it's not necessary for global field support and frankly makes no sense. The header appears on the view as a header and the footer appears as the footer.

Attached is a patch that does the following:

1. removes the global header/footer/empty code.
2. enables all fields in the view to be used as the headline or body.
3. uses views' rendering for those fields - this means rewriting, stripping tags, making links, etc is all handled by the view.
4. removed options for headline link, read more link, read more text and strip tags options from the timeline settings. Just format the field in views as desired.
5. removes the no longer necessary text_sources folder and plugins.

This enables ENORMOUS flexibility. Between field rewriting and using the native global text field you can pretty much put whatever you need to in the timeline text fields (headline, body, media caption, media credit) with all the flexibility of views' field settings. I've even successfully used a views_field_view to show a detailed view of the timeline item in the body and it worked perfectly.

Note that this requires the patch from #2120587: error The version of the timeline library could not be detected first to get the module to work at all.

I'll be using this module in a prod site for the forseeable future, so please consider adding me as a co-maintainer so we can get these critical patches applied and an official release created.

Thanks.

Many thanks WorldFallz! You seem to be providing good quality patches and have an understanding what this module is, what it should be and how to get it there. I'm more than happy to provide you the Co-Maintainer role. I've had zero time lately for this project, and it would be a shame to leave it in current unstable state.

Thanks for the vote of confidence juha! And the quick response!

I know what you mean about never having enough time... if it weren't needed for a current site I support, I wouldn't have the spare time either, lol.

I'll get these 2 critical fixes committed asap and roll a beta. Then I'll go through the issue queue and see what else I can add/fix.

Thanks again! I love open source :-)

Related issue: #2477529: views rewrite tokens not expanded

I am using a Global: Custom Text field as the source for Body Text.

Rewriting works but I get the same output for every item on the timeline. The output of my rewritten field always comes from the last item on the timeline.

If I switch to using an individual field as the source of my Body Text then the problem goes away, they are all different.

Am I missing something obvious?

@anthonyjhall I believe I have a fix for this at #2661896: Views rewrite not working as expected

@anthonyjhall - it looks like stella found the problem and submitted a fix. If you could test and verify on the linked issue in the comment above I'll commit asap.

The patch in the related issue was committed.