Jump to content
owzim

Problem with inputfield config data

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!

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

Could you send me the whole code so I could try to reconstruct it..

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

Well your code is kind of komplex (don't know why you are using an "inputfieldhelperclass"). But I would take a look into TinyMCE module or CkEditor module on how they handle it. Because there it's working...

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
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?

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By jploch
      Hey folks,
      Iam working on a module that extends InputfieldPageTable. I use PageTableExtended as a starting point and all went well so far, except I can't access my config values outside of the module file. The config values allways return the defaults, and not the values in the pw field settings. 

      Here is the code that sets the defaults inside my inputfield module file:
      public function init() { parent::init(); // defaults $this->set('gridMaxWidth', '1600'); $this->set('gridColumns', '12'); } Here is how I add the config field:
      public function ___getConfigInputfields() { $inputfields = parent::___getConfigInputfields(); $fieldsetGrid = $this->modules->get('InputfieldFieldset'); $fieldsetGrid->label = $this->_('Default Grid Settings'); $f = $this->wire('modules')->get('InputfieldText'); $f->attr('name', 'gridMaxWidth'); $f->attr('value', $this->gridMaxWidth); $f->label = $this->_('Container max width'); $f->description = $this->_('Grid container max width in px'); // page name format description $f->notes = $this->_('default is 1600'); // page name format notes $fieldsetGrid->append($f); $inputfields->append($fieldsetGrid); return $inputfields; } Accessing the values outside my module files like this (this gives me the default: 1600, even if I insert another value in the backend field settings):
      $default = $this->wire('modules')->get('InputfieldPageGrid'); $default->gridMaxWidth; Any Ideas?
    • By picarica
      so i am trying to put CustomHooksForVariations.module, a custom module, i am placing it into site/modules direcotry yet my modules page in admin panel gives me errors
      so this is the screen show when i refresh modules, i dont know why the shole hook is written on top of the page :||

      and this next image is when i try to install it, i saw that it is not defiuned modules.php but it shouldnt need to be ?, any ways i dont want to edit site's core just to make one moulde work there has to be a way

    • By Peter Knight
      Hi all
      My .htaccess file is correctly redirecting all requests to
      https:// www. That's great until I want to work locally.
      I thought I had seen a blog post by Ryan where there was a new config setting to ignore both of these if working from localhost?
      I can't find it now so wondering if I was imagining 😕
       
       
    • By Andi
      Continuing my journey into PW hooks, I'm trying to find a way to retrieve all images from a page that explicitly *do not* have a certain tag (or tags) attached to them.
      Found this post from 2015
      But I'm wondering if there's a more elegant way to go about this.
      Let's say I have a multi-image field called "images_header" and instead of
      $page->images_header->findTag('mytag'); I would like to do this:
      $page->images_header->excludeTag('mytag'); So I'd be able to do
      // find images that don't have the tag "mytag" $images = $page->images_header->excludeTag('mytag'); // check if there's any images if (count($images)>0) { // do something.. } Would this be possible by hooking into Pagefiles somehow?
      There's this bit in /wire/core/Pagefiles.php Line 626 that I'd basically just need to reverse (or at least in my mind 😄 )
      public function findTag($tag) { $items = $this->makeNew(); foreach($this as $pagefile) { if($pagefile->hasTag($tag)) $items->add($pagefile); } return $items; } Any ideas on how this could be done in a graceful manner?
      Thanks in advance!
    • By Andi
      Getting a little deeper into the ProcessWire state-of-mind here. I seriously think I wouldn't have come back to webdev if it wasn't for this wonderful little gem of a CMS.
      I have an "Options" field added to all users on a site. If the user has anything other then "default" selected, I would like to show a permanent message in the admin like the one in the screenshot, only so that the user can't close it. As a friendly reminder that he changed that option from default to something crazy 🙂
      I've read up on how to send messages to users, but where would I hook into to make this show up all the time in the backend?
      https://processwire.com/api/ref/wire/message/
      Thanks in advance!

×
×
  • Create New...