Components for theme

[Oleg06]

Whether you can do something that the components were added only when you activate the theme?

[shawn_a]

Huh?

[shawn_a]

Oh you want to dynamically add components from a theme

[Oleg06]

Yes, I'm in the theme I create the file components.xml with my components, and if your users already have the file components.xml, they can not use my components.xml file.
So I'd like to add your components in a user components.xml file.
I'm not good at PHP and can write the desired function.

[shawn_a]

There is no built in way but there are some solutions some theme authors have come up with to add them manually to the components file.

[Oleg06]

Maybe in future versions can allow to create multiple files with the components and write them all in the file components.xml, as files page.xml and plugins.xml

[datiswous]

Yeah, or a components.xml file in the theme folder. If theme is activated, components are read in and shown in the standard components admin interface. Although it would be nice then to see which components are theme depended.

[shawn_a]

There is a gothub issue for that feature feel free to find it and add your thoughts it is not a priority atm

[datiswous]

There is a gothub issue for that feature feel free to find it and add your thoughts it is not a priority atm

You mean this one? https://github.com/GetSimpleCMS/GetSimpleCMS/issues/624

[shawn_a]

this one
https://github.com/GetSimpleCMS/GetSimpleCMS/issues/579

[lokothodida]

I'm not quite sure that I understand the discussion, so someone may need to explain it again to me, but here are my 2 cents.

You want to have component-like functionality for themes, so that theme developers can write PHP/HTML code snippets that are called through the get_component function, or something similar.

Components are meant to be a safe way for users to define PHP code without creating PHP files haphazardly in the GetSimple installation. A theme developer is already able to define PHP files of their own, safely within their own theme's folder, and the Edit Theme section already provides an interface for editing these files.

So, a theme developer could make a components/ folder in their theme (and an .htaccess file to prevent direct access to the folder contents), and define a file for each "component" that they want (and these "components" will be edited from Edit Theme rather than Components). Then they could define a short function get_theme_component:

PHP Code:

function get_theme_component($name) {
  if (file_exists($file = GSTHEMESPATH . $GLOBALS['TEMPLATE'] . '/components/' . $name . '.php')) {
    include($file);
  } else {
    get_component($name);
  }
} 


so that get_theme_component first checks if a theme-specific "component" is defined and uses that, and otherwise just gets the corresponding user-defined component. Unless I'm gravely mistaken, there isn't a need to save the theme components as XML files, or to merge them into the XML data structure of the components.xml file.

[Oleg06]

I would like to transfer these files to the admin panel is in the components to have access to edit.

[DimaYakovlev]

I'm not quite sure that I understand the discussion, so someone may need to explain it again to me, but here are my 2 cents.

You want to have component-like functionality for themes, so that theme developers can write PHP/HTML code snippets that are called through the get_component function, or something similar.

Components are meant to be a safe way for users to define PHP code without creating PHP files haphazardly in the GetSimple installation. A theme developer is already able to define PHP files of their own, safely within their own theme's folder, and the Edit Theme section already provides an interface for editing these files.

So, a theme developer could make a components/ folder in their theme (and an .htaccess file to prevent direct access to the folder contents), and define a file for each "component" that they want (and these "components" will be edited from Edit Theme rather than Components). Then they could define a short function get_theme_component:

PHP Code:

function get_theme_component($name) {
  if (file_exists($file = GSTHEMESPATH . $GLOBALS['TEMPLATE'] . '/components/' . $name . '.php')) {
    include($file);
  } else {
    get_component($name);
  }
} 


so that get_theme_component first checks if a theme-specific "component" is defined and uses that, and otherwise just gets the corresponding user-defined component. Unless I'm gravely mistaken, there isn't a need to save the theme components as XML files, or to merge them into the XML data structure of the components.xml file.

Good advice!

[shawn_a]

The components should be user editable along with other components, it would be confusing to have them somewhere else. Which means there needs to be a way for plugins to register the component, load its default values if not defined, and then allow custom editing by users and saving changes overriding the default.

They will also need their own namespace to not collide with user components, which could tie in to the get_theme_component(id,name) getter, so they are retrieved separately. Then there is the where do we store them, should be in data with other stuff.

[lokothodida]

It should be possible to write a plugin that has the same (or a similar enough) interface for editing components, but with an additional section for the template-specific ones (and redirect from the original components editor like I18N does for the normal pages list).

As for the default value discussion: how is it meant to work? Is it meant to be a default set of data that is copied over the first time for the user (and which remain unchanged in the theme directory), or just be the initial set of components?

I still think it is slightly strange to save theme components in the data directory given what is accessible for the theme developer already. It turns what could be PHP scripts (which are organised in a suitable place) into data formats that have to be parsed and eval'd. For global components this makes sense since there is nowhere for the user to reasonably organise these scripts. Again, I could be deeply wrong here, but something about it seems off.

As for namespacing, we could go for a slash prefix on globals, like get_theme_component('/component-name') for a global component and get_theme_component('component-name') for the template-specific one.

[shawn_a]

All data goes in data it is how we handle undo and archiving and permission checking and if ever versioning.
Although we allow theme editong i dont want to have a third place to store And edit user data it just becomes too complex.

3.4 already has support for abstracted components, they are called collections and it is how i abstracted components into snippets, i decided to make it scalable, so a plugin would have no problem doing this with barely any code.

I think integrating it with the existing uis and adding a unique flag or filter would be easier to use.

Not sure i understand about php scripts, is this something for theme devs only, like widgets? Or content inputs like components.

Themes already do this manually, they modify the components xml insert their components, and check if they exist etc. I want an interface for that, so core knows whats what. Then we can have standard ones that are usable across themes. A theme says HI GS I USE THE FOLLOWING THINGS AND NEED THEM DEFINED. Gs then provided a ui interface for the user to edit them. They can optionally have default stuff in them, we might even have core components that are read only or hidden or per user, who knows..

so my bootstrap theme says i use a carousel, it has this parent div with these classes and three divs with these classes inside it, and provided the template, this is not as advanced as tokenized widgets, but maybe that can come later, as components will also prpbably eventually get arguments.

[shawn_a]

Oh and to clarify components are just callouts, we eval them only because we do not have closures in php 5.2, nor do we have anonymous functions. A theme default component could just as easily be made to use a callback with thisnnew registration method i am thinking of, like plugins for themes, but with just the one function..

What indont understand is if you are saying you have php files and you edit them in theme editor, that is already a thing, so why do you even need a component wrapper?

There is also considerations on github to make components multiple file capable or multisourced or registered callbacks. Maybe it is not detailed properly.

[lokothodida]

Right. I think that makes things a bit clearer. So let's see if I understand now:

• The theme developer wants to have certain components defined when their themes are used. The admin wants to be able to modify these components through the same interface as global components.
  
• The theme developer defines default values for these components in their theme's folder, which are then copied to the data directory and stored in a particular data structure with extra information (e.g. XML, JSON, etc).
  
• The admin edits these components through the expected interface, and if they "delete" a component that is required for the theme, the default value for that component is copied back in (ensuring that all necessary theme-specific components are always defined).
  
• The theme developer is able to specify which components are read-only and which can be edited by admins(?)
  
• Both the admin/theme developer use one function for calling components/theme-specific components. The user is able to resolve naming conflicts through some kind of prefix, like get_theme_component('/component-name') or a flag like get_theme_component('component-name', $namespaced = false)
  

Is that right?

[shawn_a]

Pretty much but the whole copying part will be much more elegant, will probably not actually copy anything, just dynamically include stuff. Either way users don't need to know where these files are , they might even have links in the theme tab but will probably use the same editor as components.