Port more modules from the "Example for Developers" Drupal project

[docwilmot]

Meaning ported, tests passing

• action_example
• ajax_example
• batch_example
• block_example
• cache_example
• contextual_links_example
• cron_example
• dbtng_example
• email_example
• entity_example
• field_example
• field_permission_example
• file_example
• filter_example
• form_example
• image_example
• js_example
• menu_example
• node_access_example
• node_example
• nodeapi_example
• page_example
• pager_example
• queue_example
• render_example
• simpletest_example
• tabledrag_example
• tablesort_example
• theming_example
• token_example
• vertical_tabs_example

New core modules

• config_example
• layout_example
• responsive_table_example
• views_example
• uuid_example
• date_example
• path_example
• redirect_example
• add email, link etc to field_example?
• view_mode_example?

block_example is a direct port, but it will need some changes since Layout changes some of Block's workings.

[cellear]

@docwilmot++

[docwilmot]

Changes done to block_example as per backdrop-ops/contrib#58 (comment). See branch. No tests yet.

[docwilmot]

@cellear or @jenlampton when you get a chance, please have a look at the Backdropification of block_example (both the initial port and the branch with some proposed changes ) and action_example.

These two needed drastic changes (blocks are very different in BD, and there is no Trigger module).

The Examples were kind of integrated into the API site in Drupal as official examples and we still have references to them in BD API in a few places too; I think it would be great if you guys could give me a review before people start thinking that my port is also official.

And if they are up to scratch can you gimme a thought on how (and if) to start

config_example
layout_example @quicksketch already made suggestion re those
responsive_table_example
views_example

Thanks.

[docwilmot]

@quicksketch @jenlampton
Sorry for the bump, but trying to finalize my ports before releasing and

The Examples were kind of integrated into the API site in Drupal as official examples and we still have references to them in BD API in a few places too; I think it would be great if you guys could give me a review before people start thinking that my port is also official.

Thanks

[quicksketch]

I've done a little bit of review on the Blocks example. I'll take a look at action_example next.

how to start responsive_table_example

Responsive tables are super simple, but I think they'd be a good candidate for an example as well. In order to make a table responsive, the only thing you need to do is add classes to header cells. Two classes are supported: priority-medium and priority-low. If these classes are present, theme_table() will automatically add the responsive table JavaScript library. I would make an example that matches the tablesort_example.module, as it provides a good starting point.

views_example

Hoo boy. This could go on for a while. A views example should probably provide:

• A sample filter, field, sort order, and contextual filter (argument) using just hook_views_data() and existing classes.
• Sample plugins of all the above.
• A sample display style
• A Views pager plugin
• A Views display type (e.g. feed, block, page)
• A Views access plugin
• Possibly a sample Views wizard (the "starter" form you get when creating a view)

That's going to be a ton of work. 9/10 times though, the only thing people need to do is expose a table to Views. Most of the time, they don't even need to write any custom handlers, they can just use the handlers provided by Views (e.g. views_handler_field_numeric, views_handler_field_boolean, etc.) I'd probably start there.

config_example

Config examples are a little hard to provide without a use-case. There are two general ways of exposing config:

• A simple settings config file (most common)
• A "group" of settings config files (e.g. views, fields, image styles, layouts, or anything that has multiple instances)

Both of these have examples in our current hook_config_info() documentation. It'd be trivial to do a simple config file + a config form. But doing the multiple instances example will need a sample that makes sense and a UI for adding/deleting instances.

Besides the basics of config, we could really use more explicit documentation on the _config_static: true property that can be in config files. Some configuration like views and image styles can also be reverted back to it's default state see image_default_style_revert(), that would also be a useful tutorial.

[docwilmot]

Thanks again

[docwilmot]

I've updated all examples and tests to 1.7.0 compatibility. Added a few more potential examples to the checklist above. Anyone feel like writing new examples for these, feel free to have a go.

[docwilmot]

We need a layout_example.module, considering how significant layout module is to Backdrop. At least with the layout hooks and hook_layout_info(). It'll probably be quite a simple example but I think it would be ideal to have. We also probably also need to look at the list in the original post of additional example modules that were suggested to see if we could finally build some of those. We have also added a significant number of new modules to core since that post was last updated. Are there any other examples that we should be considering? @kiamlaluno do you think you would have the time to create a few such examples from scratch?

[avpaderno]

@docwilmot I can, but not in the next 15-20 days.

[avpaderno]

The config_example module should be added, since there are some config API functions/methods other example modules do not show.
In most of the cases, the example modules retrieve or set a config value. The config_example could show how to retrieve config objects whose names start with a prefix, show them in a table, and allow to create more config objects with a name starting with the same prefix.