dragan

@dadish Great news indeed! Big thanks for this rewrite. Can't wait to try it out (probably not before the weekend).

Sure. For static resources, Cache API + service worker would probably bring speed performance. Ideally (to avoid DOM / GUI re-rendering on each page load) combined with an SPA setup. Or in PWA-speak, using an app shell.

I was getting the impression the discussion was more "in general", not PW-admin-specific. (concerning our so-called "frontend" product we ship to clients) There's always a lot you can optimize one way or another. With the specific tools / methods I briefly mentioned, you could certainly optimize a few milliseconds per page load in the admin. But the major bottlenecks would still be there. So, in brief - no, not worth to optimize in this regard (imho). Of all CMS backends I have come across, PW is already faster than most. The crucial thing of any "backend" kind of web-app is: You don't want anything to cache your current view when it shouldn't. If you just edited a page and went back to that same page, you expect to view the latest / current view. I can imagine that a (drastic, i.e. from-the-ground-up) refactoring of the entire PW admin, with a framework like Angular (Vue, React...) would significantly speed things up. But that's a completely new topic, far from trivial, and would really mean a LOT of refactoring... As someone once mentioned, PW admin loads all template and field infos, plus role-/access-based stuff on load. And this takes a lot of time. Of course you could cache that in order to save a few milliseconds, but then again - an admin web view needs the latest state, always. Without completely switching to a modern SPA framework and radical code-rewrite, I don't see much (noticeable) benefits from just using resource hints. The DOM itself is one of the biggest show-stoppers here...

@franciccio-ITALIANO Start the server and then open http://localhost/processwire-master/ in your browser. (or, if you have enabled it in Laragon, http://processwire-master.test)

If you're serious about performance and don't have http2 available, you can optimize a lot with resource hints and service workers + cache API.

@verdeandrea Sounds like a cool project! If I had to do this, I guess I would go a similar route like @wbmnfktr suggests. However, gradient generators are a lot more work than just (single) color-pickers. I'm not sure it's worth re-creating all that stuff just so your authors can finally insert some CSS for a given section. I would perhaps rather use a markup inputfield*, and just open a gradient generator in a (pw-) modal, and instruct the editors to copy and paste the generated CSS into a regular textarea. Would certainly not look as polished and streamlined as a native PW inputfield, but it would get the job done way faster. * https://modules.processwire.com/modules/fieldtype-runtime-markup/ or https://processwire.com/talk/topic/21982-rockmarkup2-inputfield-to-easily-include-any-phphtmljscss-in-the-pw-admin/

@DV-JF Didn't you take this further? Did you read my suggestion and try it?

While you're at it, do yourself (and your client) a favor and try to upgrade to PHP 7.2 or higher - official PHP 5.6 support ended a year ago.

You could also try this: https://ckeditor.com/docs/ckeditor4/latest/examples/timestamp.html

@abdulqayyum has version 1.0.1, while the latest seems to be 1.0.3, maybe that feature was added in-between those versions? What version of PW are you running?

@a-ok Works for me... did you fix it?

Well, DB-user and host are wrong. Just compare the two screenshots...

Then simply add both, and hide the PWLink items via a hook (based on role) + CSS: Inspect such a page, and find the two buttons (pw link + unlink). Each have unique IDs: body.ProcessPageEdit-template-basic-page #cke_43, body.ProcessPageEdit-template-basic-page #cke_44 { display: none; }

Create another textarea field, type CKEditor, and in the RTE settings simply replace PWLink with Link, this will give you CKEditor's default link dialog. To customize that CKE plugin, you'll have to dig into their docs / code. Maybe this is a good start.

Did you edit your hosts file accordingly? i.e. 127.0.0.1 processwire.test