dragan

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

yep

There's certainly a lot to be considered, and quite possibly I haven't thought about all pros and cons, but... If you have the multi-language settings* "what should happen when alternate language is empty (not translated)?" -> show default language content, then the authors would still only edit the original german default tab, and simply leave the 2nd "fake" german language version alone (just make sure it's activated). re: "don't confuse authors" You can simply hide the 2nd german language tab via custom admin CSS or/and hooks. That way, the default tab is still the relevant one for german and is only empty if this page is really meant to not exist in german. Only potential caveat I can think of: required fields. afaik you can't say field X is only required in one language and not in another. At least not out of the box. You'd probably have to adjust search, and navigations (don't show double entries, always rule out default, etc.) * this is defined at field-level, and afaik is the default option

You can also try the recently added https://processwire.com/blog/posts/pw-3.0.139/#new-toggle-field And then have no - unpaid yes - paid paymentAttemptFailed - user tried to pay, but for some reason didn't succeed To make it even fancier, you could log the 3rd use-case in another field (each attempt with timestamp)

use a hook? https://processwire.com/api/ref/fieldtype/create-field/ or wait for impeachment? ?

Why do you need to test them so often? The obvious advice would be: Test them on the development instance of the site. Depending on embed method (A-D), a query string may or may not work. Perhaps with a hook that checks for user-role? $this->addHookBefore('FormBuilderProcessor::emailForm', $this, 'testEmails'); protected function testEmails(HookEvent $event) { /* @var InputfieldForm $form */ $form = $event->arguments(0); if ($user->hasRole("email-tester") && $config->emailTesting === true) { $recipient = $form->getChildByName('recipient'); $recipient = 'foo@admin.com'; // or put inside $config too // some re-definition of the landing page, e.g. add query string or pseudo-landing page, or real-landing-page-url + url-segments /test-only/ } }

That actually seems to work! Meanwhile, with latest PW dev, I get an error on line 242 (my screenshot above): ProcessPageEdit: Method ProcessWire::getCurrentUser does not exist or is not callable in this context This error didn't occur with the previous dev version o_O

Just very quickly a few pointers, since it's getting late over here... Definitely create a PW-tpl and matching page for such tasks. Most people use one such special page for all kinds of API/AJAX stuff. Inside the page, you can check with a simple switch/case statement which action should be run. In that "AJAX endpoint" page (or whatever you want to call it), you can e.g. use if($config->ajax) and therefore (in the else clause) also re-use it for other purposes (classic GET or POST, i.e. data not sent via AJAX). (more examples on use-cases of $config->ajax) I guess this looks OK (though personally I prefer the more verbose form), but in your case I would definitely add input validation (sanitize / maybe add a hidden input field etc.). Also, I don't know where $randTitle or $randHas comes from - I guess it's there in your original code but you omitted to post it here for brevity? It looks like it comes from this code snippet. Just make sure you have initalized those two variables.

Yeah, the navigation is not ideal. I have to scroll 3-4 times down to see the next content below, which is counter-intuitive. There are also JS/Vue errors in projects. I can't get past the 2nd one and get [Vue warn]: Error in render: "TypeError: Cannot read property 'title' of undefined"

This is a very hackish solution, but then again it's Saturday, I have never used the LR module before, and I could do with more coffee :) Basically: Create an iFrame. May not be elegant, but it seems to work. You'd have to add a logic for the registration confirmation page, so that this doesn't load in the iframe, but in its own page. btw, the very first line above was me trying out another idea: create several pages with the LR-template and then tinker around with form targets or hidden input fields.

@abdulqayyum can you please delete your other two identical forum threads?

Yes, it's weird, and most probably a bug. Funny thing is that the current active language is recognized correctly (status10189 = 1), but language name and title are mixed up.