Date module - views api

[Graham-72]

Ref issue #1063
Cannot remove a date from filter criteria

Selecting the entry in the Views form does not produce the required options.

[Graham-72]

Tried the form with javascript disabled and it seems it is calling the missing function 'ctools_dependent_pre_render' from date_views_filter_handler_simple.inc where we have
if ($which == 'all') { $form[$prefix]['#pre_render'][] = 'ctools_dependent_pre_render'; $form[$prefix]['#dependency'] = array($source => $operator_values);

[Graham-72]

Suggestions please - I have no idea what to do to fix this.

[serundeputy]

http://php.net/manual/en/language.types.array.php

php 5.3?

$form[$prefix]['#pre_render'] = array ('ctools_dependent_pre_render');

[Graham-72]

What should one do when a module uses a function provided in ctools but not in Backdrop? Copy across the whole function?

[klonos]

I'm not 100% sure about this, but from what I recall when merging Views in Backdrop core, the necessary bits required from CTools were also moved in core (see #136 and #138 for example). From Views added to core it seems that system.module was the place things were moved into. Will need @quicksketch to clarify/verify this though cause I'm no expert in all this.

In general, I believe that if things are to be used by other modules already in core or to-be-merged, then we move the functions in core in order to avoid code duplication.

[quicksketch]

Yes, for the most part, CTools has been merged into core. The one notable
exception is CTools plugins, which were a replacement for _info() hooks.
Rather than adopting plugins, which would eventually result in converting
*all info hook (a la D8), we stuck with info hooks as a the de facto
standard. Anything that used plugins should instead use an info hook.

In the case of ctools_dependent_pre_render, this a precursor to #states.
All of Views was converted to use #states instead of CTools dependencies,
as the two have essentially the same functionality.

On Mon, Aug 3, 2015 at 12:03 AM Gregory Netsas notifications@github.com
wrote:

I'm not 100% sure about this, but from what I recall when merging Views in
Backdrop core, the necessary bits required from CTools were also moved in
core (see #136 #136
and #138 #138 for
example). From Views added to core
https://api.backdropcms.org/node/26858 it seems that system.module was
the place things were moved into. Will need @quicksketch
https://github.com/quicksketch to clarify/verify this though cause I'm
no expert in all this.

—
Reply to this email directly or view it on GitHub
#1073 (comment)
.

[biolithic]

If anyone is interested in this problem, I ported the Feeds and Job Scheduler modules to Backdrop except for the CTools code, which someone will probably have to explain how it works in Backdrop. Or, if anyone is familiar with the where CTools stuff is Backdrop, you are welcome to fork and go from there. Thanks!

I actually have time tonight, so I think I will start porting:
https://www.drupal.org/project/migrate
https://www.drupal.org/project/feed_import

Relevant links:
https://github.com/biolithic/backdrop_feeds
#487

[Graham-72]

@biolithic I am very interested in this problem, and also am having difficulty when faced with CTools functions. I made a start on Feed Import - backdrop-ops/contrib#104 - and found it difficult to understand what was going on. And I was just (in the last 24 hours) looking at Feeds so I will now take a look at what you have done.

Thanks for the link to #487 - I think this is a most important feature to have available for Backdrop.

[biolithic]

Hi Graham, I just spent an hour and a half trying to figure out Feeds
Import with no luck. I've used Feeds before and I think I will wait for @
quicksketch https://twitter.com/quicksketch to comment on Ctools.

On Wed, Aug 5, 2015 at 12:23 AM, Graham Oliver notifications@github.com
wrote:

@biolithic https://github.com/biolithic I am very interested in this
problem, and also am having difficulty when faced with CTools functions. I
made a start on Feed Import - backdrop-ops/contrib#104
backdrop-ops/contrib#104 - and found it
difficult to understand what was going on. And I was just (in the last 24
hours) looking at Feeds so I will now take a look at what you have done.

Thanks for the link to #487
#487 - I think this
is a most important feature to have available for Backdrop.

—
Reply to this email directly or view it on GitHub
#1073 (comment)
.

[Graham-72]

I got back to this issue and tried the simple expedient of deleting the line
$form[$prefix]['#pre_render'][] = 'ctools_dependent_pre_render';
to see what happens. It seems to work without this! Now to find out what it was there to do in Drupal and is something needed in Backdrop to replace it.

[quicksketch]

Now to find out what it was there to do in Drupal and is something needed in Backdrop to replace it.

ctools_dependent_pre_render was the predecesor to #states FormAPI attribute in Drupal 7. It happens that even though it served no unique purpose in D7, it was still used all over the place (especially in Views/Panels) even though its functionality was redundant with #states. You should be able to delete any usages of ctools_dependent_pre_render, and switch to using #states. See the FormAPI #states example for syntax (thx @docwilmot).

[Graham-72]

@quicksketch Thanks for the link to the FormAPI #states example which is very helpful. I was also stuck on understanding how exactly to change from using #dependency to #states until I found your commit for views quicksketch/backdrop@1b9ed86

[quicksketch]

Looks like you've solved this issue already, as it's in the main PR and in commit 490d0561a6372d4ad1849ddef24ce92b0958c9b6.