Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by dragan

  1. Yes, just a regular integer field. I was just thinking... Most fields in the pages / template I'm querying are optional. Granted, I didn't do extensive testing so far, but I guess it throws errors each time when there is no value in a field. (hence, the selector "only show if images.count > 0" was working fine). Could that be? Earlier it just outputted empty nodes or null instead (which I would expect and is totally fine).
  2. I finally found some time to install the brandnew version and do some tests. I made sure I cleared the modules cache, and cleared file compiler cache. But I get some strange behaviour in the test-tool (pw-admin/setup/graphql/) : Did anything major change in regards to query syntax? This used to work previously: Now I get lots of errors. Even something smaller throws errors: If I remove "budget" field, it works. I double-checked it's in the allowed fields in the module config. Something similar happens when I include images, and some pages don't have images. i.e. With this selector it works as expected: project(s: "industry%=verwaltung, images.count>0, sort=-year, limit=3") If I just do project(s: "industry%=verwaltung, sort=-year, limit=3") { I get stuff like this: Funny thing is, the output at the bottom after "data": { "project": { "list": [) still looks OK to me. Do I see these error messages only because the site is in debug-mode? Or because I do this in the backend as superuser?
  3. 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).
  4. 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 :-)
  5. 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...
  6. 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.
  7. 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)
  8. Try it with include=all as another filter.
  9. 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)
  10. well, whatever field-name it is - "body" or whatever you've named it.
  11. 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
  12. 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
  13. @dadish Great news indeed! Big thanks for this rewrite. Can't wait to try it out (probably not before the weekend).
  14. 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.
  15. 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...
  16. @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)
  17. 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.
  18. @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/
  19. @DV-JF Didn't you take this further? Did you read my suggestion and try it?
  20. 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.
  21. dragan

    actual date

    You could also try this: https://ckeditor.com/docs/ckeditor4/latest/examples/timestamp.html
  22. @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?
  23. Well, DB-user and host are wrong. Just compare the two screenshots...
  24. 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 New...