WireCodex

This topic is truly interesting, as is how people react to it. But if you examine the data and statistics, many things come to light. It's true that data centers, both for AI and for hosting and cloud services, consume a lot of energy, but, for example, no one ever talks about gamers who also use powerful graphics cards. Check this out: - OpenAI is on track to operate well over 1 million GPUs by the end of 2025. Reports suggest that roughly 200,000 GPUs were used to train the GPT-5 model. - Total Gamers: Estimated 3.32 billion in 2024, projected to exceed 3.5 billion by 2025, representing roughly 40-45% of the global population.

Yes, @szabesz I'm sorry about that. First, I had to change my avatar since another forum user copied it; then I changed my name because I’m working on a series of modules and my name here wasn't available on GitHub, and I wanted to be "synced up" across both places. So, I went through a process of trial and error until I found one that was available. It might seem a bit pretentious—"The Wire Codex"—but it’s actually just a technical consequence. LOL

There are hundreds and hundreds of things we do every day that harm the environment, even things labeled as Eco-friendly. What's unfair is characterizing this community as disappointing for using those things, when the person making that assessment is also poisoning the environment simply by living in a modern society. @Ex-user, we are indeed a friendly community, and if you've been here a while, you'll know that, but we're also people free to express our opinions. There's no censorship here, and comments aren't blocked. If you don't like a comment, perhaps we won't like some of yours either, but that's okay: that's how it should be. This is my last comment in this thread, but I had to say it because it's not fair. I might even be wrong, but it's my personal opinion, not the community's.

Seriously? Is this why you're disappointed with our community? Are you even an adult person? If you're so worried about the environment, you should start by quitting programming yourself, dude. Producing a single new laptop generates approximately 331 kg of CO2 emissions, while desktops create up to 948 kg of CO2. The manufacturing process accounts for 75%-85% of this impact, consuming 1,200 kg of water and 239 kg of fossil fuels. Globally, electronics contribute significantly to 62 million tonnes of annual e-waste. The software industry, part of the broader ICT sector, is responsible for approximately 2% to 4% of global greenhouse gas emissions, a figure comparable to the entire aviation industry. These emissions stem from both the energy consumed during software operation and the "embodied carbon" from manufacturing hardware. Key Environmental Impacts of Laptops, PCs, and Software Development: Carbon Footprint: Manufacturing a new laptop produces over 300kg of CO2 Resource Intensity: Creating one computer requires 1.5 tons of water, 48 pounds of chemicals, and 530 pounds of fossil fuels. E-Waste Generation: Small IT equipment (laptops, phones) generates 11 billion pounds of global e-waste annually. Toxicity: Improperly discarded computers leak toxic heavy metals, including mercury, lead, and chromium, into the environment. Manufacturing vs. Use: For battery-powered devices like laptops, 80% of total emissions occur during production, not during usage. Industry Impact: The ICT sector is responsible for roughly 3.7% to 3.9% of global greenhouse gas emissions, a figure comparable to the entire aviation industry. Growth Projection: Emissions from this sector are expected to rise significantly, potentially reaching 14% of global emissions by 2040. Development Impact: Creating a single, light software feature can produce about 60 kg of CO2, while a "heavy-duty" feature can generate 300 kg or more. Key Drivers: Major contributors include data center energy consumption, network infrastructure, and the energy used by developers' machines. The rapid replacement cycle (typically 3 years) is driving these figures, with e-waste expected to reach 82 million tonnes by 2030. Only 17.4% to 22.3% of global e-waste is formally recycled, with the rest ending up in landfills, often polluting soil and groundwater in developing countries. Ryan's reasoning makes much more sense than yours. We should repeat politically correct slogans less like a parrot and use a little more common sense and human reasoning.

I think that for all the functionality you need, there isn't a ready-made module you can use out of the box. If I were in charge of the project, I would opt for the Shopify Starter plan at $5 per month. This plan includes Shopify's functionality, but without the online store. Then you can build your own store with your design/customizations, and use the Shopify API/Webhooks for everything else. The solutions to your points could be: 1. Shopify 2. Shopify 3. ProcessWire 4. ProcessWire 5.1 ProcessWire 5.2 ProcessWire 5.3 Shopify 5.4 ProcessWire Check the Shopify plan here: https://www.shopify.com/starter Check the Shopify PHP SDK here: https://github.com/Shopify/shopify-api-php PS: Also check this module too: https://processwire.com/modules/snip-wire/

I hit the same wall! It occurred to me to use the template's urlSegmentList not only as a whitelist, but also as a container for routable definitions, adding route definitions directly to the template configuration, which is intuitive and centralized. According to the API documentation, the following lines are allowed as template-level URL segments, using the syntax regex: to notify PW that the "next" string is a regex. 'photos' 'photos/new' 'regex:^photos/photo[0-9]+$' 'regex:^export-(json|xml)$' Following this, I tried to add a custom pattern and intercept the whitelist processing to control the process. I assume we are using custom pages to add new methods to the page. method:path @handler Example 1: /*PATTERN*/ 'get:/category/{id}/list @listCategory' /*REQUEST*/ /category/321/list /*RESPONSE*/ return page()->listCategory(id:321); Example 2: /*PATTERN*/ 'get:/products/{name}/categories @categories\listAll' /*REQUEST*/ /products/laptop/categories /*RESPONSE*/ return pages('categories')->listAll(name:'laptop'); This allows me to define a complete set of routes based on the same template's urlSegmentList feature, like this: 'get:/{id}/list @listCategory' 'post:/add @addCategory' 'delete:/{id} @removeCategory' 'put:/{id} @updateCategory' I implemented all the code for route processing and execution, etc., BUT... then I tried it as a Hook (with a lot of variations), as a Module, as a DefaultPage, etc., without success. It's impossible to 'effectively' stop the super-powerful 404 page! Then I gave up. I think the only way is to modify the PW code ...or not?

Great news! @ryan, for a completely new admin project, might you consider using HTMX, or something similar? It's perfect for PHP. I've used it on a large admin project, and it works wonders with ProcessWire. I also use these libraries to complete the package: https://github.com/gnat/css-scope-inline https://github.com/gnat/surreal

tursodatabase/turso-client-php: Turso - libSQL client libraries and utilities for PHP (github.com)

Set a placeholder in your text, and use the function wirePopulateStringTags() to output it, filled or empty. https://processwire.com/api/ref/functions/wire-populate-string-tags/

Read this, it might give you an idea using JSON files:

The method proposed by @ryan here isn't bad, but it doesn't allow nested fragments. In the case of complex views (web apps, calculators, etc.) with different user actions where several calls are needed for different sections of the page, and we (almost always) need fragments that are inside larger fragments. I'm currently working on my first Processwire module, which can help to use these fragment-based systems. I've been implementing several methods, and only one of them prevents the entire content of the template file from being rendered. It works but requires some conditions, ex. in the case of a single template file with markup regions, you should organize your code to put the creation of all content variables at the beginning of the file and completely separate from the output HTML markup. The idea is that during rendering it collects the requested fragments from the template file and saves them to a temporary PHP file, then includes it in the template file at the point before full HTML output occurs, and then stop the rendering the template file. It's basically like a dynamic partial. The advantage is that you don't need to split the template files into several parts (nested fragments will be a nightmare) and avoid to put a lot of conditionals in the code. It also helps that if you have a new type of request, you only need to declare in the request which parts of the page to fetch. @elabx if you're interested, I have a Hook version of this that I used during testing. Note: It would be great if the Render method, in addition to the current template file, would also accept an HTML string. This avoid the use of temporal files.

GREAT!!!!! ?

Check: https://processwire.com/docs/modules/guides/comments/

Off topic: htmx is in the first cohort of the GitHub Accelerator: https://github.blog/2023-04-12-github-accelerator-our-first-cohort-and-whats-next/

in fact I have a method in the custom page class for that: if (HTMX Blah Blah) $page->renderFragment("todo", [array], "200 OK"); function renderFragment($filename, $bag, $code) { header("HTTP/1.1 $code"); wire("files")->include("services/partials/{$filename}.php", array('view' => $bag)); exit(); } .. but I love to use Markup regions in my projects, and I hate using tens of partial files, that's the reason for the proposal. Get the "partials" from the same template file that I render in the page request. It's a simple helper in tune with Processwire Markup Regions