Jump to content

How to handle saving of the CKE-field content on my own, using an event listener


Heinz
 Share

Recommended Posts

I am new to PW ...

When adding the 'Save' option to a CKE-Field, the disket symbol, is shown when editing the page like below .

image.png.b2cccecbdb24786e8051d49655681c0d.png

The user of this page gets two buttons at the bottom of the page when activating the CKE-field because
frontend-editing is enabled. The disket symbol is not shown

image.png.c45a73099a723ece168025e4ba0e263e.png

Questions:

How to handle saving of the CKE content on my own, using a javascript event listener attached to the 'Save' symbol ? 
How can I make the disket symbol for 'Save' in the CKE toolbar, visibile and usable fro the above ?
How can I make the buttons at the bottom disappear ? 

 

 

 

 

 

Link to comment
Share on other sites

Hey @Heinz welcome to ProcessWire 🙂 

What you are asking is not so easy as it involves a lot of technical stuff and some of that are security related. That's why sticking to default PW procedures is usually a good idea, so you can trust on proven concepts.

But on the other hand everything is possible in PW. If you give us a context WHY you are trying to do that and what the actual goal is we might have another and maybe easier and better solution to your problem?!

Link to comment
Share on other sites

Hi to Vienna 🙂
Some of the nicest towns I have ever been.

To me it seems more in line to save the content of the editor via an icon from the toolbar as well as to cancel and close the editor
via icons on the toolbar.  You might have more then one CKE-field on a page, so save and cancel buttons on the page do save or
cancel for all CKE-fields ? What I want , is to grep the content and transfer it via http-request to my backend not to the PW-table,
the content might trigger some action on  my backend transfered back to the frontend etc... think of chat, monitoring.

I have done that many times in severel web-apps with my own editor-fields but up to now without PW.  I am just curious as
how this could  be done with only PW resources.    

  • Like 1
Link to comment
Share on other sites

29 minutes ago, Heinz said:

You might have more then one CKE-field on a page, so save and cancel buttons on the page do save or
cancel for all CKE-fields ?

Yes. In PW you have the concept of "everything is a page". Where a page can consist of multiple fields. And one fundamental part of the system is the page editor (ProcessPageEdit technically speaking).

If you are in the default page editor a "save" will take all fields' values, submit them, process them and save them to the database.

If you want to do that on your own you can, but it's for sure not the most efficient way. Though you can do so, because PW is not only a CMS, it is also a Framework just like Laravel and consorts.

Ok... so for your example let's say we had two fields, body1 and body2 on the page. And let's say we want to store something in those fields. The basics are really easy with the PW API (so there's no need for complicated mysql queries or such that you might be looking for when coming from other frameworks):

$page = $pages->get(123);
$page->setAndSave('body1', 'my example value');

Now that is populating the body1 field of page 123 with a hardcoded value.

Of course in a real world you'd have much more moving parts: A dynamic page id, maybe a dynamic field name (body1+body2) and of course a dynamic body text. You'd need to take all of that into account and do proper sanitisation etc.; Do you really want to do that?

29 minutes ago, Heinz said:

What I want , is to grep the content and transfer it via http-request to my backend not to the PW-table,
the content might trigger some action on  my backend transfered back to the frontend etc... think of chat, monitoring.

I partly understand. But I think you have some misconceptions in your head, which is a common thing when coming from other platforms. It might feel strange at the beginning (everybody is so used to mysql tables and mysql queries) but once you get the "everything is a page" concept it can really be eye opening and a great joy to work with!

Before I go into detail on what I'd do instead... What do you mean by "trigger some action on my backend" and "not the PW-table"?? Are we talking about the PW backend? The admin interface? That is usually found under your.site/processwire ? Are we talking about a test-project? Or are we talking about something real?

And if you tell us more about your experience we can provide better answers and understand you better 😉 For example if you came from something like WIX you might have totally different concepts in your head than coming from WordPress or Typo3...

Link to comment
Share on other sites

I have never before used a CMS or framework. PW is just to get my feet wet. I think I like it.

I am used to create databases manualy according to cutomer needs and operate on them using plain PHP and sql.
This is my backend driving a frontend and driven by events from a frontend (AJAX,websockets) where the UI/pages are constructed
serverside by PHP and dynamicaly altered by Jacascript, no twig, no smarty, no framewroks . All vanilla. 
Sounds complicated but it is not because over the years you have your own libs, so all is fine. 
Mind you I wrote my first program in 1975, Fortran IV  and my first PHP in 1994

 So with regards to the CKE field and PW, how would you build a protocol app where users of one shift have to pass information to
next shift being able to edit this info via just one CKE-field and being able to access the history, past entries. I have seen that
the content of such a CKE field is always stored in the same data field of a table dedicated to this field.  I would store this content
as a new entry in my own DB table called info along with the date and time.  Or is there a place for this in PW ?

Don't get me wrong I don't insist on doing it this way  or that way I am just curious, retired and a bit bored 🙂

 

 

 

Link to comment
Share on other sites

1 hour ago, Heinz said:

Don't get me wrong I don't insist on doing it this way  or that way I am just curious, retired and a bit bored 🙂

I'm also not saying there's only one way of doing it. I just tried to invite you to think out of the box and leave paths that you have been using in the past. That does not mean you should forget them of course, because as already said you can also use PW in a traditional database table way. It's just not the most common way I guess (which is a shame imho because PW can be a great platform not only for building websites but also as a framework).

1 hour ago, Heinz said:

So with regards to the CKE field and PW, how would you build a protocol app where users of one shift have to pass information to
next shift being able to edit this info via just one CKE-field and being able to access the history, past entries.

Thx, that's a very good example.

What you could do here is to create two templates: "protocols" and "protocol"

The "protocol" template would hold all the fields necessary for storing data for each protocol. That would be similar to all the columns needed when storing that in a DB table. For example: title, datetime, message

For the "protocols" template it would be enough to have a single "title" field.

Then you create the parent-child relationship on those templates. You set the allowed children of "protocols" to "protocol" and the allowed parents of "protocol" to "protocols".

Then you create a new page in the page tree and choose "protocols" as template. You can set the title to whatever you want, eg "My shift protocols".

Then go back to the page tree and add a page UNDER the just created protocols page. As only "protocol" pages are allowed as children you should only be able to add such a page here. Then you can populate all fields (title, datetime, message - which could be your ckeditor field) and save that page. --> You have created your first protocol entry, which would be similar to inserting a new row in the DB table in a usual database world.

So that's an easy example of how you can approach such things.

There are many benefits of doing it that way rather than doing everything by hand:

  • You have a GUI for adding, editing, deleting etc. those entries.
  • You can use all kinds of fields for adding "content" to your entries, for example it's extremely easy to add an images/files field to upload images/files. That would be very much work with plain PHP/MySQL
  • Every "protocol" entry is a PW page and you can do all kinds of great things with it. For example you could create a template file for that page (/site/templates/protocol.php) and you would have a publicly available digital version of your entry. As PW is built apon the page-tree paradigm you don't need to create "routes" or "endpoints" - they are already there. Out of the box, as soon as you add the mentioned template file.
    So in our example we could access that entry under yoursite.com/my-shift-protocols/demo-entry (where the parts of the url are the names of the created pages and you could of course make them random or auto-increment or things like that).
  • You can change some kinds of that GUI easily via GUI or via code. For example you could change the label of the "title" field to something like "Enter your name here".
  • You have a great system for access control on a field level.
  • You can hook into every single aspect of your GUI. No limits.
  • Multi-Language? Yep, easy to add!

And many many more things.

To be fair, there's also one thing that I've been missing when working with database-like data: Grid-Views. We have the page-tree which is great for websites, but it's limited when it comes to tabular data views. We also have Lister and ListerPro, but that's not great for such use cases imho. That's why I built RockGrid, which makes it possible to list ProcessWire pages as grid with other helpers like batch editing rows and adding custom actions, see https://processwire.com/talk/topic/26663-need-help-making-sse-work/?do=findComment&comment=220918 if you like and if you are bored 😉 

Of course you could always just code some custom view just like you'd have to do when building such an app with PHP/MySQL or any other framework. You can do that in the PW backend (https://processwire.com/talk/topic/17709-how-to-create-custom-admin-pages-aka-processmodules-yes-its-that-simple/ ) or you just code your own custom frontend for it.

3 hours ago, Heinz said:

the content might trigger some action on  my backend transfered back to the frontend etc... think of chat, monitoring.

Now that we have everything in place you can easily listen to events in the PW ecosystem:

<?php
// site/ready.php
$wire->addHookAfter("Pages::added(template=protocol)", function($event) {
  $page = $event->arguments(0);

  // send email
  $mail = new WireMail();
  $mail->to('your@mail.com');
  $mail->from('robot@yoursite.com');
  $mail->subject('new shift entry');
  $mail->body("See here: ".$page->editUrl(true));
  $mail->send();
});
  

Now whenever someone creates a new protocol page you get an email that shows the url where you can edit and review that new entry.

Hope that makes sense! Have fun exploring PW 🙂 

PS: Wondering what "INSERT INTO ..." would be in PW?

<?php
$p = new Page();
$p->template = 'protocol';
$p->parent = $pages->get(123); // page id of your parent page
$p->title = "John Doe";
$p->datetime = strtotime("2022-11-11 11:11");
$p->message = "Your shift message";
$p->save();

 

  • Like 3
Link to comment
Share on other sites

1 hour ago, Heinz said:

The user has to be logged in to the admin part of PW to create a new page as a child of an other page just
to enter some info ? 

Sorry for that, you didn't say anything about that in the "requirements" 😉 

1 hour ago, Heinz said:

If this is so, then this is a no go for me.

It is not so, it was an example. One possible way. Not the only solution.

Link to comment
Share on other sites

1 hour ago, Heinz said:

The user has to be logged in to the admin part of PW to create a new page as a child of an other page just
to enter some info ? 

You can also create a form in the frontend, but then you have to "build" it yourself.

Or you can use the paid module "FormBuilder", with which you can "build" your own forms in the admin and also create new pages via these forms (in the frontend).

There isn't just one way of doing it 😉 

  • Like 1
Link to comment
Share on other sites

@Heinzregarding communication via http-requests with the PW backend for retrieving, storing, patching etc with a Rest-ful approach you could use this module: https://processwire.com/modules/app-api/

For building custom frontend forms there is an excellent thread: 

It is a long thread but a nice read for bored people 😉

Link to comment
Share on other sites

Thanks to all of you for your input although it deviated a bit from my initial question 🙂

Meanwhile I had a look at Tinymce and this gives me what I want and I asked for.
I could not get the Tiny integration in PW to work, no toolbar an no menu, but on my own 
test it works perfect . 

image.png.3ee1abd0126d30529b25e3d3dea1d83d.png

The code for this is very simple.

 
 <script src="../core/js/tiny/tinymce.min.js"></script>
        <script>
            tinymce.init({
                selector: '#ttt',
                plugins: [
                    'save'
                ],
                toolbar: 'save | undo redo | formatselect | ' +
                        'bold italic backcolor | alignleft aligncenter ' +
                        'alignright alignjustify | bullist numlist outdent indent | ' +
                        'removeformat | cancel',
                save_onsavecallback: function () {                 
                    console.log('Saved ' + tinymce.activeEditor.getContent());
                    tinymce.activeEditor.remove();
                }
            });

        </script>

For now I leave as is.

Thanks again.

 

 

 

 

  • Like 1
Link to comment
Share on other sites

8 hours ago, Heinz said:

Meanwhile I had a look at Tinymce and this gives me what I want and I asked for.
I could not get the Tiny integration in PW to work, no toolbar an no menu, but on my own 
test it works perfect . 

I can confirm that not all TinyMCE toolbar options are available in the PW version (e.g. save, formatselect). I couldn't even find out how to add separators in the toolbar through field configuration screen in PW. So your implementation is the way to go if you want those customisations.

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...