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

I get it, in PW it can be done too with $files->render() ..now do the example without partials ? I mean when a page has many moving parts, you have to dissection too much the "view" in files, and it becomes complex (not impossible) to handle... I want to make clear my first post says that it can be done now, in fact I have done it... but it would be much more productive and simple something like what I propose .. but it's only an idea based on my opinion

All that you describe is very good for simple examples like the ones you put here, but when it's a much more complex page, or a web application, with several different elements that you want to update, it starts to become complex. You need to start dissecting the template file into small partial files (or even worse build the markup with PHP variables) to be able to render different types of requests to the same template, and it's a mess! ex. complex forms with dependencies between the fields, updating graphs or tables, panels with details of the selected element, couple of counters in different location in the page, etc. The idea is to be able to use the same original template file that initially rendered the page, and that can be used with Markup Regions if you wish. Response with a whole page as @bernhard proposes (although it's already cached, you need to update it with the new query) and send the complete page each time you need to update something, ex. only one <select> element, small text or a counter, these kind of pages regularly weigh MBs ..It's very unreasonable ..is better to reload the page. The ideal is to send the exact piece of html that you need to update on your initial page render. @bernhard Latte already support this kind of rendering. Using the 3rd parameter to only render 1 block from the template $Latte_Engine->render('path/to/template.latte', [ 'foo' => 'bar' ], 'content');

I have been using HTMX recently and it really is a very good option. Of course all of its functionality can be achieved using the Processwire API, and including partial files in the template file. But it would be wonderful to have some kind of facilities in our framework. Maybe with a new method in the PageRender class, that allows to select specific elements of the template file markup. The following is a simple idea based on the Markup Regions syntax: <pw-region id="content"> <h1><?= $page->title ?> <?= $page->summary ?> <h2>Contact Details</h2> <div id="contact_info" pw-fragment> <p><strong>$page->contact_name</strong></p> <p>$page->contact_address</p> </div> <h2>Social Channels</h2> <div id="total_likes" hx-swap-oob="true" pw-fragment> <a href="https://www.facebook.com/">$page->likes</a> </div> <p>Please, Call Us!</p> </pw-region> Since I'm not a programmer and I don't really understand very well how PW works inside, perhaps one of the following options can work to execute the rendering of the fragments (It can use the Find method that Markup Regions has for HTML tags) $output = $page->render("#contact_info#total_likes"); $output = $page->render("basic-page.php#contact_info,total_likes"); $output = $page->render("fragment=contact_info|total_likes"); $output = $page->fragment("contact_info|total_likes")->render(); $output = $page->render()->fragment("contact_info|total_likes"); $output = $page->renderFragment(["contact_info","total_likes"]); wireFragment() Of course this method does not use the append file of the "_main.php", perhaps doing a: $this->halt(); Laravel Blade has this already implemented for precisely the same purpose. Check this video: https://youtu.be/3dPUsXsDZsA https://htmx.org/essays/template-fragments/ @ryan what do you think about this? Everyone, would this be a good idea? ..or something similar?

An immediate and simple solution, at least for online content, can be the meta tags but for training bots: https://developers.google.com/search/docs/crawling-indexing/robots-meta-tag https://moz.com/learn/seo/robots-meta-directives

@ryan maybe this could help: https://www.phpclasses.org/package/12821-PHP-Detect-and-block-spam-bots-from-accessing-sites.html

https://learn.microsoft.com/en-us/answers/questions/414790/check-if-lat-long-point-is-inside-polygons

I was there, read this:

What about this? https://htmx.org/docs/#polling + the Processwire pages API to build the response

Comments on this YouTube video:

Check: https://processwire.com/api/ref/wire-input/url/