Jump to content

wbmnfktr

Members
  • Posts

    1,851
  • Joined

  • Last visited

  • Days Won

    44

Posts posted by wbmnfktr

  1. Woah... (positive and surprised emphasis here)

    The graph I posted above made it super easy for me to understand differences in loading JS while the one you mentioned... did the absolute opposite.
    It did almost nothing for me on first look to understand anything.
    I have to read, have to compare, this, and that... which isn't that of a problem but for a quick first look while trying to understand. NOPE.

    Sure, the one from your example explains a lot more (which is great), talks about differences, and you learn way more yet ... just looking at it doesn't work for me, what the other one does.
    Sometimes I just need a good visual hint that explains a more or less complex situation, which mine did (for me at least). That was the reason I posted it here.

    So we are quite different in consuming such information, and that's super interesting.

    • Like 2
  2. @elabx what's the reason behind the setup you describe here?
    I probably missed a lot or just don't understand it what's in previous parts of this discussion.

    You mentioned this:

    On 8/13/2023 at 6:36 PM, elabx said:

    here's what worked for me for now to develop composer packages locally while having them working in a ddev project

    So... as far as I can understand this - combined with the rest - it's something more or less outside of the usual ProcessWire realm aka developing/working on a composer package. Am I right with this?

    I am just wondering if I missed something in regards of handling composer packages in ProcessWire and DDEV while working on a project.

  3. 20 hours ago, FireWire said:

    His content isn't really my style (I think this is one of the first "reaction" videos I've ever watched)

    He has different formats, but yes... "reaction" videos are special. Still I really enjoyed this one (and the original video).

    • Like 2
  4. 13 hours ago, ryangorley said:

    I wanted to start doing things the ProcessWire documented way before layering on too many third-party templating tools so I've been building my first site using markup regions to render the front end. This approach is very foreign to me. I think direct output is closer to what I've seen and used in WordPress. Do you think there is merit to learning the methods in the documentation or should I just jump to trying RockFrontend or TemplateEngineFactory (with the TWIG / LATTE goodness)?

    Markup regions are a super interesting concept but I never really used them. It always felt a bit weird. So can't say that much about that concept in everyday use. I prefer using Direct Output. There is absolutely nothing wrong with it. I'd go so far and say it's the perfect way to start playing with ProcessWire. All you really need are some echo and foreach statements to start.

    That's the code I needed to start exploring the base concepts of ProcessWire.

    echo $page->yourTextField;
    
    foreach($page->yourRepeaterField as $repeaterItem) {
    	echo $repeaterItem;
    }

    You will see results pretty fast and will see how some field types differ or behave in one situation or another. Create a few demo projects, break them, try to fix them, install them again and start over.

    The moment you know how templating / output strategies work in ProcessWire look into something like TWIG or LATTE. To use these you should know a bit more about how ProcessWire, fields, templates, output strategies, etc. work.

    Start here: https://processwire.com/docs/tutorials/

    Even though this video is quite old and the backend looks outdated 99% of this is still true and works in the same way:

     

    • Like 1
  5. On 8/24/2023 at 10:05 PM, ryangorley said:

    for GNOME and Ubuntu Desktop, and more recently helping Thunderbird redesign their website

    The people around might enjoy and maybe even love ProcessWire. As it is free, as in beer and in freedom. At least outside the ProModules and some other third-party modules. Yet, with that background, you probably could make bonus points in one way or another. The ProcessWire docs are probably one of the best, the API is easy to understand even for beginners, and the community is unmatched, absolutely awesome! Probably one of the best around. Another great option for you with ProcessWire could be: ProcessWire is probably the best CMS to run a data-driven website.

    But back to your questions, and a very warm welcome.

    On 8/24/2023 at 10:05 PM, ryangorley said:

    Have you found it difficult to convince clients to use something other than WordPress? What do you tell them, if so?

    Most clients who used and knew about WordPress just knew the name and were told it was awesome. Almost all were annoyed by those upgrades each and every day and that things broke once in a while that resulted in another invoice to fix those issues. So... no, most of my or our clients looked for something that caused less stress and minor headaches. We market our websites as helpers, that do most of the jobs and take care of some parts of the site and even remind editors to do their job. But that's another story.

    Those who wanted to keep WordPress didn't become clients and were directed to other agencies that knew WordPress. That easy.

    On 8/24/2023 at 10:05 PM, ryangorley said:

    If you've worked in the WordPress ecosystem, what do you miss?

    Some plugins, aka modules, from WordPress would be nice-to-have, yet we have absolutely everything around in one way or another. ProcessWire can do things just with its core capabilities that WordPress needs at least one, two, or even more plugins for. For example: ACF, CustomPostType, Caching. It's all there—maybe no batteries included, but you could just add those/whatever you need, especially in terms of ACF and CustomPostTypes. Caching is a bit more tricky, yet even for beginners, it is quite easy to handle (just like me, years ago, in 2016 or so without almost no knowledge about PHP or ProcessWire). I'd go this far and say ProcessWire is a great way to start a PHP-Dev journey.

    On 8/24/2023 at 10:05 PM, ryangorley said:

    What are your top three (or more) dev tools or must have modules for making ProcessWire life easier?

    RockFrontend has an easy built-in page reload on file changes. It's probably my most-needed feature ever. Besides that, I use Rockfrontend or TemplateEngineFactory to enable TWIG support (others enjoy LATTE more, but ok). While it seems that almost 95% of us here use TracyDebugger, I am not using it for the following reasons: I am not a programmer or developer. I do way more frontend, concepts, and SEO so I enjoy things that make my life easier, like LazyCron, ProCache*, FormBuilder*, ProFields*, and some additional 3rd-party modules to fix and boost SEO, like SEOMaestro, or automate things, with LazyCron, Hooks in ready.php, and maybe even some small custom modules.

    The real kicker is probably: Custom Modules and/or Custom Page Classes

    My preferred CMS before ProcessWire was Textpattern which was totally different, yet minimal and easy to use. It took me about a week to feel home in ProcessWire, built my first client project the same year, and never left ProcessWire - since 2014/2015. I built almost everything from simple landing pages to full-fledged projects.

    See those Site of the Week entries here:

     

    • Like 5
  6. On 8/23/2023 at 6:53 PM, heldercervantes said:

    Although I did try to make AlpineJS part of my boilerplate and quickly gave up.

    I use AlpineJS all the time in ProcessWire.
    See the package.json here.

    In terms of AlpineJS it's almost a one-time-build unless you place all logic in an external file.
    That takes minimal more effort to make it work.

    This is how I use it:

    package.json

    "scripts": {
        "watch": "npm-run-all --parallel watch:*",
        "build": "npm-run-all build:*",
        "watch:alpinejs": "npx esbuild site/templates/src/alpinejs.js --bundle --target=es2018 --watch --outfile=site/templates/js/alpine.dist.js",
        "build:alpinejs": "npx esbuild site/templates/src/alpinejs.js --bundle --target=es2018 --minify --outfile=site/templates/js/alpine.dist.js",
        "watch:appjs": "npx esbuild site/templates/src/app.js --target=es2018 --watch --outfile=site/templates/js/app.js",
        "build:appjs": "npx esbuild site/templates/src/app.js --target=es2018 --minify --outfile=site/templates/js/app.js"
    },

    src/alpinejs.js

    import Alpine from "alpinejs";
    // import mask from "@alpinejs/mask";
    // import intersect from "@alpinejs/intersect";
    import persist from "@alpinejs/persist";
    // import focus from "@alpinejs/focus";
    // import collapse from "@alpinejs/collapse";
    // import morph from "@alpinejs/morph";
    
    // Alpine.plugin(mask);
    // Alpine.plugin(intersect);
    Alpine.plugin(persist);
    // Alpine.plugin(focus);
    // Alpine.plugin(collapse);
    // Alpine.plugin(morph);
    
    window.Alpine = Alpine;
    Alpine.start();

    src/app.js

    document.addEventListener("alpine:init", () => {
      Alpine.store("myStore", {
        list: Alpine.$persist({
          listDaysDefault: 1,
          revision: 0.1,
          startDate: "",
          endDate: "",
          items: [],
        }).as("localStorageMyStore"),
    
        // disable scroll on body
        scrollLocked: false,
        toggleScrollLocked() {
          // if either or overlay or category menu is active
          if (this.showOverlayMenu || this.showCategoryMenu) {
            // console.log("true");
            this.scrollLocked = true;
          } else {
            // console.log("false");
            this.scrollLocked = false;
          }
        },
    
        // Getter, Setter, Functions
        // https://alpinejs.dev/directives/data#methods
        // funFunction() {
        //   return value;
        // },
      });
    });
    
    // we check for updates on local storage and reload all browser showing this website
    // enable when necessary
    // window.addEventListener("storage", () => {
    //   location.reload();
    // });

    _main.php

    <script defer src="/site/templates/js/alpine.dist.js?=<?php echo time(); ?>"></script>
    <script src="/site/templates/js/app.js?=<?php echo time(); ?>"></script>

     

    Let me know where it breaks your boilerplate setup.

  7. I didn't work on pure PW projects lately but I think that RockFrontend could be The Tool-Belt for PW Frontend Devs one day. 

    Features like the ones @Stefanowitsch mentioned are the reason I use and like it.

    Almost ZERO-setup just by installing the module.

    • Auto Refresh (THAT'S THE FEATURE I LOVE!)
    • Compiling CSS from whatever
    • Minifying files
    • ...

    Yet there is so much other stuff I need nowadays that just don't work without additional steps.

    Like TailwindCSS or AlpineJS.
    I need Node.js/NPM, some scripts, and an additional workflow that runs parallel to ProcessWire/Rockfrontend all the time.

    I can't give you a straight answer to your question but maybe explore the frontend-world without UIKIT, look into something like Astro (JS) and Laravel (PHP) to see how and what's working there.

    Right now I'm deep into Astro and I love it - even though there is way too much JS involved for my likings.
    Building frontends is almost fun again. Pulling in data is quite easy. Yet... it's not for all kinds of websites or projects, at least not for me. I still know when to switch to a full PW setup.

  8. 9 minutes ago, ryan said:

    I usually like to merge dev to the master/main branch first, let it marinate for a day or two, and then tag it. That's because once we tag it, it triggers other services to pick it up and broadcast it. So letting it marinate for the weekend just adds a layer of comfort, for whatever silly reason. That's pretty much how I've always done it.

    Never release on fridays! 😁

    • Haha 8
  9. When everything is up and running again, as it was before, you could initialize a Git repo on your server.
    Every change in every file would be totally transparent from that moment.

    At least in theory.

  10. 4 minutes ago, kunago said:

    However, it's not only this file being present on the server.

    Give us a screenshot and list those files, please, so we can check AND please download the whole directory and archive it in case someone wants to look into it further.

    • Like 2
  11. Maybe you could try to check what was changed. There are two modules I used in the past to do so.
    Install them in a test-environment to find out which works better in your case. 
    For now I can't really recommend the one or the other.

    https://processwire.com/modules/version-control/
    https://processwire.com/modules/process-changelog/
    both by @teppo

     

    PageHitCounter had this issue in an early version... so page hits resolved in an update BUT... that was long ago. 

    • Like 1
×
×
  • Create New...