Jump to content

dragan

Members
  • Content Count

    1,610
  • Joined

  • Last visited

  • Days Won

    19

Everything posted by dragan

  1. My only concern would be that a lot of page references can slow down page-loading in edit-mode in the admin. But just for updating / creating / reading such values, I don't think performance would suffer. You can always completely hide these PR fields in the admin (or choose to only load via AJAX when opened).
  2. https://superuser.com/questions/7327/how-to-add-a-custom-search-engine-to-firefox https://addons.mozilla.org/de/firefox/addon/custom-search-engine/ Or just bookmark my Google Custom Search Engine (or create your own): https://cse.google.com/cse?cx=013706179141317928628:dendm4c3gpq The nice thing about GCSE is that you can freely configure several domains/sites where it should search: As you can see... it's been used quite frequently :-)
  3. To increase the chance that Ryan even sees your suggestion, I'd create a post in the Lister Pro forum (feature request). Who knows, maybe with a hook it can be already done somehow today...
  4. Yeah, well in that case it really seems impossible. Can't you narrow it down with some other condition? has_parent, template, or similar? I know you said you want something future-proof, but certainly you are not adding new templates every day? Field dependencies let you write your own logic in plain PHP (one of many options), I guess Ryan has a reason he didn't allow such freedom when it comes to Lister (Pro or not) - probably security concerns. You might want to take a look at @bernhard's RockGrid module instead. A bit more work initially than just creating a new Lister Pro instance, but you're totally free to list / select / query whatever you like.
  5. grumble... sorry, but my first example doesn't indeed work. It seems that this (quite surprisingly) does seem to work: page.fieldname= At least in my test-environment, it lists all pages (my field only exists in only one template)
  6. Try it with include=all as another filter.
  7. Well, there's no selector "if template / page has field_x", so a workaround could be two custom selectors: custom (field=value) 1 = meta%= custom (field=value) 2 = meta!= Make sure to check the checkbox on the right (make it OR rather than AND)
  8. well, whatever field-name it is - "body" or whatever you've named it.
  9. Do you mean you place that class in CKEditor? You have to enable inline classes, otherwise the richtext editor strips it away when saving. Admin => Setup => Fields => Your field => Input => Extra allowed content Enter something like a[*]{*}(*) config / syntax examples: https://ckeditor.com/docs/ckeditor4/latest/guide/dev_advanced_content_filter.html#custom-mode
  10. Maybe you need to add a getForPage() in there? https://processwire.com/talk/topic/18880-getting-one-repeater-items-as-content-for-other-repeater-item-on-the-same-page/ Try to use Tracy Debugger and see what dumps you get. https://adrianbj.github.io/TracyDebugger/#/debug-methods?id=bardump
  11. @dadish Great news indeed! Big thanks for this rewrite. Can't wait to try it out (probably not before the weekend).
  12. dragan

    HTTP/2 Push

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

    HTTP/2 Push

    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...
  14. @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)
  15. dragan

    HTTP/2 Push

    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.
  16. @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/
  17. @DV-JF Didn't you take this further? Did you read my suggestion and try it?
  18. 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.
  19. dragan

    actual date

    You could also try this: https://ckeditor.com/docs/ckeditor4/latest/examples/timestamp.html
  20. @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?
  21. Well, DB-user and host are wrong. Just compare the two screenshots...
  22. 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; }
  23. 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.
  24. Did you edit your hosts file accordingly? i.e. 127.0.0.1 processwire.test
×
×
  • Create New...