Jump to content

Problem with inputfield config data


owzim
 Share

Recommended Posts

I added some input fields to the Textarea input tab with a hook:

$this->addHookAfter('InputfieldTextarea::getConfigInputfields', function(HookEvent $event) {
    // field generation here
});

The fields are rendered perfectly, all fine here:

eVjUimR.png

When I hit "save" the new config values are saved to the database. This is what I see in the field's config in the fields table, all fine, great:

{"textformatters":["TextformatterParsedownExtra"],"inputfieldClass":"InputfieldTextarea","collapsed":2,"rows":16,"contentType":0,"trackChangesInterval":777,"cssTheme":"theme-solarized-dark"}

But when I want to access the new saved data from anywhere, I can't, it's not there. Only the standard values from textarea are there but not the custom ones. What else do I have to do to make them accessible from the respective fields instance? The are there but do not seem to be added/set to the instances.

PS: PW's docs need some serious work =(

Thanks!

Link to comment
Share on other sites

In my render hook InputfieldTextarea::render:

$inputfield = $event->object;

$inputfield->getAttributes(); // only holds the standard ones
$inputfield->customCssPath; // null
$inputfield->cssTheme; // null
$inputfield->get("cssTheme"); // null
Link to comment
Share on other sites

Hi Nico,

that's very kind of you, thanks. I published a dev branch of the Textarea Preview Module on Github: https://github.com/owzim/ProcessTextareaPreview/tree/dev

As I said the code in InputfieldTextarea::getConfigInputfields (on field config -> input) works great but when I try to access the data in InputfieldTextarea::render (on page edit) it's not there. It's all in the file ProcessTextareaPreview.module

I hope you find your way through the code. I commented out the Chrome logger stuff, If you have @Soma's Chrome logger module installed, you ca use it.

Link to comment
Share on other sites

Found the error and corrected it. Also specified when this module should be loaded (I wrote a comment next to your "TODO" comment in your code about this :) )

It's all in the pull-request.

Edit: Think I oversaw something. I'll take a second look.

  • Like 1
Link to comment
Share on other sites

Thanks, I merged it. But:

1. the field settings won't show up no more in the input tab of the field (I guess because the autoload is limited to page edit now)

2. the $data variable is holding merely the default settings not the ones from the database

Edit:

1. is now working when I set 'autoload'   => 'process=ProcessPageEdit|ProcessField'

2. I read you comment in the code, it says it has to load the moduess setting, not the field settings. I don't want that, that would not make any sense, since I want per field config. Also it IS available in the database within the FIELD settings, see:

3rmwTSY.png

Link to comment
Share on other sites

Thanks for the efforts Nico, the autoload stuff has helped already.

The difference to TinyMCE module or CKEditor is that those are standalone Inputfields, my module only hooks into things, so there is no dedicated Inputfield config.

I could narrow the problem down into a very simple module, so it's easier to spot the problem.

Link to comment
Share on other sites

This works fine when done right: see https://github.com/boundaryfunctions/TextareaCounter

I'm not sure a process module is the right job for all those things you have now in a Process module that is loaded on every page edit even if no textarea preview is needed. I would have separated things more clearly. I might be wrong but I still thinking process modules should be used as such, not autoload and provide functionality that is bound to a admin page or admin url.

  • Like 3
Link to comment
Share on other sites

Also I found after doing many modules that it often can get complex and you have to be careful with doing advanced stuff, it can easily break existing stuff. Sometimes just because it's working doesn't mean it's the correct way. But then it can often get very tricky since there's more than meets the eye. I always tried to look at ryan's modules and how certain things are solved. I think I understood most of this stuff, but even then I sometimes think I didn't at all. :)

  • Like 1
Link to comment
Share on other sites

Thanks @Soma, will look into the Textarea counter code.

I guess I can restructure the whole thing and separate concerns more clearly. Since it's my first (actual) module I am still finding my way through how everything works or should work.

Also I found after doing many modules that it often can get complex and you have to be careful with doing advanced stuff, it can easily break existing stuff. Sometimes just because it's working doesn't mean it's the correct way. But then it can often get very tricky since there's more than meets the eye. I always tried to look at ryan's modules and how certain things are solved. I think I understood most of this stuff, but even then I sometimes think I didn't at all. :)

I am doing that, but his code base has grown over the years so certain things are done differently every time it seems, because some code uses newer features other uses older ways of doing things. It's a bit tricky at times.

I'd still like to know why I cant access the settings although they are present in the json config of that field in the database.

Link to comment
Share on other sites

Thanks to Niko I now know I can use selectors for the autoload value. Can I use selectors to the fullest? If so I could limit the autoload to pages that have Textareas in them with the selector only, right? Would that be possible?

Link to comment
Share on other sites

I think using a Process module here for this adding config is the problem, to start with. Process modules are meant for a specific thing. As I said it might work for every module you try to build but it's not the way to go I think, they should be used as such.

The hook to add config should be done via a WireData autoload=true module.

Link to comment
Share on other sites

It's hard to follow what's going on in your modue and maybe it's just the order of how the hooks are called, but not sure.

$this->addHookAfter('InputfieldTextarea::render', $this, 'hook_InputfieldTextarea_render');
$this->addHookAfter('ProcessPageEdit::execute', $this, 'hook_ProcessPageEdit_execute');
$this->addHookAfter('InputfieldTextarea::getConfigInputfields', function(HookEvent $event) {
            
Also you're using a helper module in construct and in the config hook, I'm not sure what that does have an effect to that config system.
Link to comment
Share on other sites

I'm not sure I can follow your code correctly. But you do add config to the process module and to the textareas inputfield config? I'd expected you only add additional config to the inputfield.

Link to comment
Share on other sites

I'm not sure I can follow your code correctly. But you do add config to the process module and to the textareas inputfield config? I'd expected you only add additional config to the inputfield.

You are right, it's only in the dev branch. The field config would later replace the module config.

It's hard to follow what's going on in your modue and maybe it's just the order of how the hooks are called, but not sure.

$this->addHookAfter('InputfieldTextarea::render', $this, 'hook_InputfieldTextarea_render');
$this->addHookAfter('ProcessPageEdit::execute', $this, 'hook_ProcessPageEdit_execute');
$this->addHookAfter('InputfieldTextarea::getConfigInputfields', function(HookEvent $event) {
            
Also you're using a helper module in construct and in the config hook, I'm not sure what that does have an effect to that config system.

Will look into that later this day. I am off now.

Thanks for the help.

Link to comment
Share on other sites

I agree that there could be more documentation on that subject, but I doubt there will be very soon or never at all.

These are quite advanced things you're trying to do, without maybe understanding it completely. I know how you feel and I recommend starting very small and experiment step by step try to understand what you're doing or what PW or PHP does. For some of these things , there's not always a "one" correct way. But one may lead to the wrong conclusions, as I had to recognize myself quite a lot.

First understand PW modules and what they're for, like a Process module, a Wire or WireData module. How configs and local properties and PW data is handled and they're scope. I only now began to understand some of them. So don't ask me, and I doubt you'll get the right answer from anyone here except Ryan.

Just and example, you can check if you're on a certain admin page using

if($this->page->process == "ProcessPageEdit")

but

$this->process will return "ProcessPageView"

Also things like in your Process module in the init first line there's:

public function init() {
        parent::init(); // required

parent::init(), isn't required at all here! Do you know what it does? It loads the styles and script using the same name as the Process module. Nothing else. SInce you don't have any styles or script associated there's no need to call this. No harm here either, just an example.

I just think the module system in PW can be very simple or very hard, depending on what you want to achieve. I find it kinda worrying that so many modules get released, copied and looked at and things done wrong or misleading will not help others as they study your module and learn something wrong or not really correct. I'm no exception here.

I know there's no way around that but also wish there should be a quality control (Ryan does some of it as I see) or a comprehensive documentation really. Butas I said this will take a long time seeing how long it takes to get on with documentation of PW and the API.

  • Like 2
Link to comment
Share on other sites

Thanks for the info Soma,

Better documentation would be handy, but it's an awful lot of work to do & maybe even more to maintain it all. We all know Ryan works his but off. The amount of work he does isn't possible but he's doing even more than that :-) What I think is possible is a set of really well written boilerplates for modules like the ProcessHello.module (Wonderful starting point). I would love to see a boilerplate for fieldtype & inputfield. The exchange of data information those two needs is still a little vague for me. Often the data you need is not net there.

All in all I do think we are in a very luxury position, as documentation in general ( API level ) is very comprehensive.

  • Like 1
Link to comment
Share on other sites

@owzim, don't want to discourage you in any way, your doing great work here. Really enjoy seeing many others finally get more serious with module development, I know Ryan is, and I'm maybe just nit picking here.

Yeah some good throughout documentation is a lot of work and I don't think I could pull it off. I did my contribution with the cheatsheet and that's already some work to keep it up to date, luckly enough it's now a ProcessWire site and can be managed some. :)

With your module here while I don't understand all fully (haven't studied all nor installed yet), for example why you have config to the process module and on the textarea field (inputfield)? As per hook https://github.com/owzim/ProcessTextareaPreview/blob/dev/ProcessTextareaPreview.module#L120 

Meanwhile you seem to have another config set in your process module too:

public static function getModuleConfigInputfields(array $data) {
        return TextareaPreviewConfigHelper::renderForm($data, self::$defaultConfig);
    }
 

But anyway, I think could that you're missing that the config is stored with the Field and not Inputfield? There's no storage for Inputfields, they're only for interface input and not DB.

So like this you should get the custom data.

$customFieldSettings = wire("fields")->get($inputfield->name)->customCssPath;
  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...