Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 03/14/2022 in all areas

  1. Hello I wrote this small article https://dev.to/clsource/processwires-pros-and-cons-2o8n I would love to know if there any other considerations or ideas regarding that article. Thanks ?
    12 points
  2. ProcessWire 3.0.196 contains 10 minor issue fixes, but the biggest additions this week are 6 pull requests submitted from @bernhard. This most notable PR is an upgrade to AdminThemeUikit that enables greater customization of the theme's markup. If you recall, Bernhard also provided a PR last year that enables customization of the admin theme's CSS/LESS, so now he's now completed the circle and provided us with a direction for customizing the markup as well. This newest addition lets you provide your own custom render files for different parts of the admin theme by placing them in /site/templates/AdminThemeUikit/. Third party modules can also define custom render files. Furthermore, this addition adds a new hook that enables you (or your modules) to hook into and modify just about any part of the admin theme rendering. Rather than going into all the details and repeating all of the instructions here, see the new AdminThemeUikit README file "Customizing Markup" section which describes all of the different things you can modify and how to do so. You can also find all of the render files in the core AdminThemeUikit directory — any .php files beginning with an underscore are custom render files that can be overridden. While not as broad in scope, there were other useful PRs added this week as well, so be sure to see the dev branch commit log if you are interested in seeing what else was added. Thanks for reading and have a great weekend.
    3 points
  3. Hello Camilo, Nice to see you still blogging about PW. I like your post a lot, however maybe the "Requires some learning" bit is too vague. Yes, you explain it right afterwards but changing it to "At least basic PHP knowledge is required" or something similar would make it clear right out of the box. I think there is at least one more important bit to explain in more detail: frontend possibilities. "....way of code organization, neither force you to learn a new template engine." Sure, but it is an advantage that there are modules supporting template engines for those who need them or one can integrate any of them relatively easily. Also, the core provides Markup Reagons for those who prefer plain php templating for the output rendering, which makes life easier too. I would mention and point/link to these options as well, not just the JSON "alternatives". Again, nice blog post for sure.
    3 points
  4. I'd suggest that there are very much easier ways to go about things than using multiple databases. I can think of various possible approaches, but I might go about it something like this... You might have a set up like this, with the user pages below the home page having the users' names (to keep things simple for this example): home |____user1 | |____page1 | |____page2 | |____user2 |____page1 |____page2 To work with the pages for the current user, you could get the pages thus: // Get the user name $userName = $user->name; // e.g. 'user2' // Get all pages belonging to the user $userPages = $pages->find("has_parent=/$userName"); // Get page2 belonging to the user $userPage2 = $userPages->get("name=page2") An important thing to note is that in the above example $userPages is a PW PageArray (https://processwire.com/api/ref/page-array/), and you can work with this instead of with $pages (i.e. all pages). To deal with a superuser, you might do something like this: if($user->isSuperuser()) { $workingPages = $pages; // All pages } else { $userName = $user->name; $workingPages = $pages->find("has_parent=/$userName"); // As in the previous example } I've kept things simple here to illustrate the idea, but I imagine your set-up would be a lot more complex. But I hope this helps as a starting point.
    2 points
  5. Me too :) That's why I wrote this "cheat sheet" for myself and shared it just in case others find it useful too: https://processwire.com/talk/topic/23641-markup-regions-pw-vs-data-pw-different-behavior/#comment-201538
    2 points
  6. Hi, it is a choice of personal preferences, definetly! ? I would go with a parent page and sub pages. The parent page gets a template called concerts (NOTE the plural s at the end). The settings for that template includes a single page usage and a family setting like allowed parent is, for example, "home". And allowed sub templates are the yet non existent "concert" (NOTE: singular!) The sub pages get the template concert (NOTE singular), without count limitation, but family settings restricted to allowed parent(s) = concerts. (Children for concert are not allowed) The concert template gets all your fields: date, title, desc, link, ticket link This way it is faster in backend then opening a single page with hundred(s) of repeaters. More advantages can be better SEO URLs for each single concert, (think permalinks), or at least the native match of page tree and public URLs, without any abstraction layers like URL-Segments etc. Also a later implemented archiving is easier to realize with sub pages then with repeaters. But, as said above in this post and by @virtualgadjo, it depends A) on the number of concerts you will handle and B) on personal preferences. ? In your concerts template file, you can iterate over all sub pages with every filter and sorting selector you like: // $page is the single (parent) page with template concerts ! <?php foreach($page->children() as $concert) { ?> <ul> <li><?= $concert->date ?>/li> <li><?= $concert->title ?></li> <li><?= $concert->desc ?></li> </ul> <?php } ?> // optional selector is easily possible, e.g. show only current and future concerts <?php foreach($page->children("date>=today, sort=-date") as $concert) { ?> ...
    2 points
  7. this is what i was looking for in the very beginning, thanks for pointing me to the right direction!
    1 point
  8. hey everybody, you are all super awesome! thanks for the help and directions. i thought about the same processes but couldnt find a hook to start digging. now i got plenty of material from you all, thanks a lot!!
    1 point
  9. Thanks - yeah I'm thinking about what is best to use - this is a paywall type of situation, and I like that aMember pro has been around for a long time, and is a 1-time payment not an ongoing subscription... I think i will need to use PW users because this client wants a lot of stuff to change for subscribers, like no google ads, etc..
    1 point
  10. I just tried with PW 3.0.191 and kept everything default. Seems to work for me with a dot as a separator but not with a comma. Comma leaves the field empty afer save.
    1 point
  11. @millipedia oh yes you're right, there are so many options, replace, append, optional that i often forget to quote all of them (and even sometimes to use... too much of a php by myself guy ? ) have a nice day
    1 point
  12. There's also the pw-optional parameter for your Markup Regions: https://processwire.com/docs/front-end/output/markup-regions/#defining-an-optional-region You'd need to use an id on your section tag rather than the content div you have at the moment but that would remove the section if it was empty. <section id="section2" class="section" pw-optional> <div class="container is-fluid"> <div id="content2"></div> </div> </section>
    1 point
  13. I am, but only on a single site and it's for a feature that's only activated once a year for a short period (an annual vote). I think I might have a use case for the module in some updates to a site that will be happening in the coming months. When that happens I'll spend some more time getting familiar with the module and can submit any ideas that come out of that. Thanks.
    1 point
  14. Thx Ryan for pulling my changes and improving them ? I wonder if you have any numbers of how much more efficient it is to use a non-hookable method compared to using a hookable method? I'm usually not thinking too much about this as everything seems to be fast anyhow. But as you have refactored that approach it might be a noticable difference? I'd be very happy about some insights ?
    1 point
  15. Whoa! That is something I was wishing to have for years! Thank you! Recently I posted about donations and @bernhard's paypal link was on the list. But to my regret I have not donated to him myself. I wish I could fix my mistake, but things happened since then that do not allow me to pay online abroad anymore ? Please be so kind to help me out here and start donating to Bernhard. I know he will appreciate it. And I will join you as soon as I find a way to.
    1 point
  16. Hello @gerritvanaaken, there are new buttons in Repeater items for cloning before or after an item: https://processwire.com/blog/posts/new-repeater-and-repeater-matrix-features/ Also: Regards, Andreas
    1 point
  17. hi, my name is carson, and I created htmx and, since we're here, hyperscript.org (for lunatics only)
    1 point
  18. htmx supports using morphdom for swapping with the morphdom-swap extension agree 100% w/ @Craig's characterization of htmx as lower level than unpoly: it's an extension of HTML rather than a full framework (with, for example, a notion of layers). That can be good or bad, depending on your needs. Unpoly is a wonderful library that follows the same general html-oriented approach, but provides a lot more infrastructure baked into the core. I think either one (or, hotwire, for that matter, which is even higher level than unpoly) is a great choice for html-oriented development. I obviously prefer the lower-level "improve on HTML" approach, but they all have plusses and minuses. I'm (all to) happy to chat about htmx either here, on the htmx discord, or anywhere else. -t.totallyNotAnHtmxShill
    1 point
×
×
  • Create New...