clsource

Hello I created this issue https://github.com/processwire/processwire-requests/issues/502 please I would love to see your comments on this matter. This would enable using other servers besides Apache by implemeting .htaccess rewrite rules in PHP, maintaining the security of .htaccess in other webserver technologies. Thanks

Hello, I made this little experiment, maybe useful for someone. YAWS (Yet Another Webserver) is a HTTP 1.0/1.1 webserver which is completely written in Erlang. YAWS has been noted well suited for dynamic-content web applications in many cases. Because Yaws uses Erlang's lightweight threading system, it performs well under high concurrency. A load test conducted in 2002 comparing Yaws and Apache found that with the hardware tested, Apache failed at 4,000 concurrent connections, while Yaws continued functioning with over 80,000 concurrent connections. Mixing Erlang and PHP is a powerful combination. PHP has a vast web development ecosystem and Erlang has more than 30 years of production ready concurrency solutions that scale well. https://github.com/joyofpw/pwyaws/ Cheers.

Maybe my https://github.com/joyofpw/inertia module can be of help ?

I think ProcessWire is perfectly capable of handling an ecommerce. My main consideration is that such project requires more time and expertise than for example configuring a Woocommerce, Open Cart or Prestashop type of ecommerce and just use their apis for showing up the products. If you would need a tailored approach, surely ProcessWire and Padloper can be handy ?

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 ?

I found this nice tool that helps generating SQL and diagrams https://www.dbml.org/home/#intro Example Table makers { id int [pk, increment] name varchar(100) } Table cars { id int [pk, increment] maker int [ref: > makers.id] // # one maker -> * cars model varchar(100) about varchar(100) image_url varchar } Maybe useful for ProcessWire site planification too ?

There are different ways of making a Rest API You can check https://github.com/Sebiworld/AppApi and

Thanks, although my approach to the manifest was just reading the json file after webpack ends processing the files. Then using the json create a new PHP file named templates/_mix.php that contains those values and helper functions. The module approach is fine too ?

I think PHP 7.4 is fine for now. I tested PHP 8 and PHPMyAdmin have issues running there. So I think is better to stick with the 7.x version until PHP8 is well tested. Maybe that would be a major version of ProcessWire since @Sephiroth pointed out module compatibility issues.

I will go to the PW channel on libera ?

I loved Svelte too. For the routing part I mostly use Laravel and now ProcessWire (With the Inertia Module) with the https://inertiajs.com/ Inertia adapters. That simplify greatly the flow and you got the best of backend and frontend ?

Inertia Adapter ProcessWire Module Hello! Long time no see. I created this module so you can use Inertia.js (https://inertiajs.com/) with ProcessWire. Description Inertia allows you to create fully client-side rendered, single-page apps, without much of the complexity that comes with modern SPAs. It does this by leveraging existing server-side frameworks. Inertia isn’t a framework, nor is it a replacement to your existing server-side or client-side frameworks. Rather, it’s designed to work with them. Think of Inertia as glue that connects the two. Inertia comes with three official client-side adapters (React, Vue, and Svelte). This is an adapter for ProcessWire. Inertia replaces PHP views altogether by returning JavaScript components from controller actions. Those components can be built with your frontend framework of choice. Links - https://github.com/joyofpw/inertia - https://github.com/joyofpw/inertia-svelte-mix-pw - https://inertiajs.com/ Screenshots

Thanks this is a nice improvement ? Now it's lazy loaded and the thumbnails are 200x200 px ?

https://processwire.com/api/ref/languages/get-default/ $wire->addHookBefore("Pages::saveReady", function(HookEvent $event) { $page = $event->arguments(0); if($page->template->name != 'mytemplate') return; if(count(wire("languages")) > 1) { $defaultLang = wire("languages")->getDefault(); $page->title->setLanguageValue($defaultLang, "New Value"); } else { $page->title = "New value"; } $event->arguments(0, $page); });

May be this can work? https://processwire.com/api/ref/pages-type/save-ready/ $wire->addHookBefore("Pages::saveReady", function(HookEvent $event) { $page = $event->arguments(0); if($page->template->name != 'mytemplate') return; $defaultLang = wire("languages")->get("default"); $page->title->setLanguageValue($defaultLang, "New Value"); $event->arguments(0, $page); });

$defaultLang = wire("languages")->get("default"); $page->title->setLanguageValue($defaultLang, "New Value");

Maybe is your internet provider configuration. https://watchmysys.com/blog/2015/01/unitymedia-is-blocking-vpn-connections/ Please try using another Internet provider maybe using 4G. Or similar network. Thanks.

check if you are using https ? https://aves.ninjas.cl/

Hello, I finished this toy project. A simple API to show data for Chilean Birds. Used to flex my PW and React muscles, since a lot of time has passed since making something with those techs. Code: https://github.com/NinjasCL/chileanbirds-api Frontend (React): https://aves.ninjas.cl Backend (PW): https://aves.ninjas.cl/api Hope you like it ? Thanks.

I didn´t mean to say which approach is better. I think RockMigrations is a good tool. SolidWire is not a replacement of any migration strategy or tool. It's just an idea to ease the communication and prototyping between developers and other people. It's in the same area of https://plantuml.com/ Just a tool to improving an eagle view of the system. The JSON output is just an idea similar to https://doc.mapeditor.org/en/stable/manual/introduction/ Any other proper migration tool could use it to generate a proper output. But is not mandatory :).

Ok I have been toying around with this lib https://mudgen.github.io/webscript/docs/ And make a somewhat implementation of SolidWire using Javascript. import builder from "webscript/src/webscript.js"; import createElement from "webscript/src/createObjectElement.js"; const { wire, templates, template, fields, field, pages, page } = builder( createElement ); const core = { fields: { textarea: field.class("FieldtypeTextarea"), }, }; const site = {}; site.fields = { body: core.fields.textarea.name("body"), about: core.fields.textarea.name("about").max(100), }; site.templates = { home: template .name("home") .root(true) .fields(site.fields.body.label("Content")(), site.fields.about()), }; site.pages = { home: page.title("Home").template(site.templates.home()), }; const render = (data) => Object.values(data).map((item) => item()); const solid = wire( templates(render(site.templates)), fields(render(site.fields)), pages(render(site.pages)) ); console.log(JSON.stringify(solid, null, 2)); executing that code brings this result in json { "tagName": "wire", "children": [ { "tagName": "templates", "children": [ { "tagName": "template", "children": [], "value": "", "__isElement": true, "name": "home", "root": true, "fields": [ { "tagName": "field", "children": [], "value": "", "__isElement": true, "class": "FieldtypeTextarea", "name": "body", "label": "Content" }, { "tagName": "field", "children": [], "value": "", "__isElement": true, "class": "FieldtypeTextarea", "name": "about", "max": 100 } ] } ], "value": "", "__isElement": true }, { "tagName": "fields", "children": [ { "tagName": "field", "children": [], "value": "", "__isElement": true, "class": "FieldtypeTextarea", "name": "body" }, { "tagName": "field", "children": [], "value": "", "__isElement": true, "class": "FieldtypeTextarea", "name": "about", "max": 100 } ], "value": "", "__isElement": true }, { "tagName": "pages", "children": [ { "tagName": "page", "children": [], "value": "", "__isElement": true, "title": "Home", "template": { "tagName": "template", "children": [], "value": "", "__isElement": true, "name": "home", "root": true, "fields": [ { "tagName": "field", "children": [], "value": "", "__isElement": true, "class": "FieldtypeTextarea", "name": "body", "label": "Content" }, { "tagName": "field", "children": [], "value": "", "__isElement": true, "class": "FieldtypeTextarea", "name": "about", "max": 100 } ] } } ], "value": "", "__isElement": true } ], "value": "", "__isElement": true } @bernhard maybe some JSON like that could be used in RockMigrations. So you have the best of both worlds. A simpler syntax and an output that could be used to define migrations using JSON ?

Althought Laragon is a great choice. You can also use Docker if you want ? Here I made a simple config for PW https://github.com/joyofpw/docker ?

Hey I updated the spec. Now it's more like Pseudocode than a whole language in itself. The idea is just to communicate better and make plans before building or thinkering with the fields. Example for this small project that I'm building https://github.com/NinjasCL/chileanbirds-api @document { @wire { @templates { home: template().options({@once, @strong, @root}), notfound: template().options({@once, @childless}).description("Used in 404 errors"), birds: template().options({@strong}).family({ parents: ["home"], children: ["birds-item"] }), birds-item: template().options({@childless}).family({ parents: ["birds"] }) }, @fields { title: text().options({@i18n, @global}), body: textarea().options({@i18n}), uid: text(), href: url(), file: files().max(1), migration: checkbox(), dimorfism: checkbox(), size: text(), order: text(), species: text(), image: images().max(1).mediatypes([@jpg, @png, @svg]), images: images().mediatypes([@jpg, @png, @svg]), value: text().options({@i18n}), habitat: textarea() .description("Stores the habitat property") .options({@i18n}), didyouknow: textarea() .description("Stores the did you know property") .options({@i18n}), iucn: pagetable() .max(1) .fields({ body: body().description("Stores the iucn description"), value: value().description("Stores the iucn value") }), audio: pagetable() .max(1) .fields({ file, title.label("Author") }), map: pagetable() .max(1) .fields({ image, value }), }, @pages { + "Home" (template:home) @many -> { + "Birds" (template:birds) @many -> { + "Bird 1" (template:birds-item, fields: { title: title().label("Names"), body: body().label("Description").description("Stores the bird description"), images, habitat, didyouknow, iucn, audio, map, species, migration, dimorfism }) } // /birds } // /home } // /pages } // /wire } // /document

I think another approach is just having a "Homily" template.That uses a repeater field to storage dates and seasons. Maybe a structure similar to this <homilies> <homily> <title /> <about /> <repeater> <priority type="int"/> <date/> <season /> </repeater> </homily> <homily> <title /> <about /> <repeater> <priority type="int"/> <date/> <season /> </repeater> </homily> <homily> <title /> <about /> <repeater> <priority type="int"/> <date/> <season /> </repeater> </homily> </homilies> So you can search all the homilies and put the different dates and season configuration for that homily. If one or more homily is on the same date then you can use the priority field to sort them out.

Also you can use this docker file I created for easy PW dev env ? https://github.com/joyofpw/docker