TODOs

[juek]

More editor controls needed:

• link-field done
• multi-select
• checkbox-group
• multi-image (Alex makes it) done
• fa-icon-select done as extra control
• predefined color swatches picker

Not actual controls but UI elements:

• separating/grouping controls
• Notes and in-editor messages (with trigger contitions and/or events)

List to be extended...

For more complex ones that need additional libs, css or server-side processing please consider building them as extra controls. Extra controls will only be loaded if required (used as control_type in editor.php of a section type) thereby not bloating the core editor and speed up loading.

If you're planning to build one of the above mentioned, please announce it here in order to avoid parallel develpoments!

[a2exfr]

multi-image (Alex?)

Yes

[juek]

BTW: For the new $debug_levels. Just change it on your behalf. Don't worry about leaving your levels in commits, I'll change them back for me.

[thomasfrobieter]

Hey Guy's,

first of all: Thank you both very, very much for your great work. It's so efficient using this plugin to build custom sections. Love it.

Some suggestion's / question's: Does it make sense to have global settings (at the CustomSections settings page), for each section inside _types?

Example: Currently i build a simple icon section, which should show up FA icons AND some custom icons (second iconfont), some Text next to the icon, etc. So, let's say the FA icons solved via "fa-icon-select"-control @juek pointed above, i still have to define my extra icon's another way. One possible solution could be a simple textarea on the settings page, so i can define something like ico-class|Ico readable name. So i don't have to customize my section for every project to keep it updateable.

Example 2: The planned "Form Sections" - there are some settings we would like to store globaly, like the public and private keys for reCaptcha, the captcha method itself, the (default) mail addresses, ...

[juek]

Does it make sense to have global settings (at the CustomSections settings page), for each section inside _types?

Certainly. We would have to implelemt a function that reads _types/some_section/admin.php or settings.php for that purpose, which would then hook into the Settings page. But such settings can vary quite a lot, so I wonder how much abstraction will make sense. We'd need to build sth. similar to universal editor's controls to make settings equally easy to use, but I fear they would have to be even more complex.

[thomasfrobieter]

We'd need to build sth. similar to universal editor's controls to make settings equally easy to use, but I fear they would have to be even more complex.

Not sure about this, most of this settings will probably be set once while page creation.. so do we really need those kinda beautiful control types for those "Backend Settings"? Maybe we should use the same simple forms, Typsetter using at the configuration pages (table.bordered configuration ..etc).

So from my point of view.. keep this simple as possible, only simple HTML control types.

[a2exfr]

Does it make sense to have global settings (at the CustomSections settings page), for each section inside _types?

That easy to implement, even with some auto UI, although that the examples are not very convincing to me. But nevermind.

I wonder how much abstraction will make sense.

IMHO if someone go for admin page for custom section type, he should know what he is doing) And we can not speed up process of dev here to implement some solution like controls for custom editor, because process already simple just insert and save. One thing we can implement is getter for admin setting for each type. But in this case all devs should follow one scheme of admin page(saving), to always get admin option in section type, for example in $admin_options array variable.

[juek]

For everything on the developer/designer side, I'd go for hardcoding, because its way more efficient, Admin page options only for… well … admins (w/o coding skills) - e.g. like Simple Button's Setup Page where admins can change presets and set default classes.

[juek]

@thomasfrobieter

Example: Currently i build a simple icon section, which should show up FA icons AND some custom icons (second iconfont), some Text next to the icon, etc. ...

The iconpicker extra control is now available. It's built with fontawesome-iconpicker. fontawesome-iconpicker allows to extend the icons list with icons from additional fonts - see the glyphicon example at the bottom of the page.

@a2exfr

Hopefully we have no code collisions with Catalog Easy's iconpicker. Please check it betimes–I haven't yet ;-)

[thomasfrobieter]

@juek Sounds great! Yes, this fit's exactly my needs ;) Thank's alot!

I've also spent some time of my holiday on the "Contact Form Section". It's working already very well, added nearly all kind's of HTML5 form controls, and some form validation things. Implemented just as a "_type" inside Custom Sections - except an entry inside the Custom Sections addon.ini (to add the formHandler.php). Optionally it send's a confirmation mail to the submitter. The admin- & confirmation mail can contain HTML, so we are able to create some nice looking header and footer inside the mails. Also thinkable to have some kinda overridable template files ...

Hopefully i will push a first alpha version online within the next week.

[juek]

@thomasfrobieter

Example 2: The planned "Form Sections" - there are some settings we would like to store globaly, like the public and private keys for reCaptcha, the captcha method itself, the (default) mail addresses, ...

For reCaptcha and mail address, why not use the System Config settings?

For other globally stored data: Well, it really depends on the particular case. While adding a plugin/extension interface to the CustomSections_Admin page would be one way to do it, we would still need to define a coding schema for it. I'd advocate for extending the plugin with an additional custom Admin page. This has some benefits:

• It can have a distinct label and independent UI
• You can directly link to it in the section editor component
• It can use it's very own configuration file that will be loaded and saved only for the particular section type thus preventing needless reads/writes with others. The save function would be part of the Admin page, the load function can be coded and called directly in section.php (if we want to store the settings in /data/_addondata/CustomSections, we should globalize $addonPathData in GetSection() in order to have it in .../_types/YourSection/section.php but it can also be done in section.php itself)

[juek]

Added to the TODO list:

Not actual controls but UI elements:

• separating/grouping controls
• Notes and in-editor messages (with trigger contitions and/or events)

[thomasfrobieter]

For reCaptcha and mail address, why not use the System Config settings?

Yes, we already use those settings. I never really noticed we have recaptcha right in TS core.

We have still some things we like to store globally, like the TLS encryption and "use html" settings for PHPmail, but this will also better stored right in the TS configuration. I will create an issue/request for those settings.

I'd advocate for extending the plugin with an additional custom Admin page. This has some benefits

I agree! Seems to be the better variant.

Current status with the contact form section: I reviewed my code together with my php developer, he gave me some homeworks ;) I have to fix some security things and improve the code quality. But ..not a big deal. We are close to finish this thing :)

[a2exfr]

@thomasfrobieter Wow I never though that customsections will be used to made something like this)

[juek]

Looks impressive!

I will create an issue/request for those settings.

Sure thing.

[thomasfrobieter]

Hey Guy's,

i have one last major problem here. I hope you can help me out.

As a logged in user the section ID appears as data-gp-section="3" inside the section wrapper markup. I need the section ID inside the section.php. But i can't figure out how to get this with php. I tried get_defined_vars() - but i was not able to find it.

PS: Maybe it would be a better, more solid solution, having a static ID inside the section array: array ( 'type' => 'contact_form', 'id' => 'bazinga3254', 'values' => array (

[juek]

Sections themselves in Typesetter may not have an id attribute, since it is reserved for editing e.g. "ExtraEditArea1" (1 based). The data-gp-section attribute (same but zero based) reflects this value. Both are assigned dynamically and I wouldn't use them as id for data processing/form submission.

If you need an id for your form, create one upon section creation as seen in the shop_item type (for the carousel). You can also store the value as custom key (e.g. "form_id") in the $section array.

The only problem with unique ids and sections is when they are copied, which will lead to duplicate ids and must be solved via Javascript and the SectionAdded event

edit: actually it would be a bood idea if we implemented some sort of uniq id handling (including recreation upon coying) into the plugin.

[thomasfrobieter]

Hi, @juek thank's for declaring! Sadly we are currently very busy, but we try to publish a first version soon as possible.

[thomasfrobieter]

In case someone looking for it, we published it int he meantime: https://github.com/webksde/Typesetter-Custom-Sections--Contact-Form