elabx

My internet persona was born in these sort of forums when I was a teen, and I think it'll die on this hill! I REALLY appreciate having a forum for ProcessWire! Wouldn't exaggerate to say it's one of the reasons I've found myself so comfortable in the community.

Yep, no success.

Fantastic! Really appreciate this @jacmaes

I'd really appreaciate if I could see these! I'm thinking of using Ploi for server management but they only support nginx.

Runcloud manages servers with OLS: https://runcloud.io/ they also use MariaDB. Maybe you can spin it up for a month, a VPS for a few days and you should be good to go.

Anyone using nginx in 2024?? Any updates on the available configs??

Nothing in particular just that it all looks really good! Made this comment thinking on how it's very complicated to setup the recurring rules, but I like the solution!

I've tried to tackle the recurrence part (to some success, I am still finding bugs) with: https://github.com/elabx/FieldtypeRecurringDates but it's not a calendar solution, I actually ended up building a calendar with HTMX like @Jonathan Lahijani 's and also a combined field solution like @monollonom 's. So interesting to see everyone's solutions! @bernhard I think I'd request the "Never" option, since there are situations where end users don't really think about when something is going to end at least that's why I ended up implementing a "Never" fake option. I haven't really solved it in my module in a way that would seem optimal, "Never" just means an absurd amount of events (eg 5,000 hard limit). The drawback I have faced is performance in queries of this absurdly large tables (At least they always look absurd taking into account that's it's just a few pages of the site sometimes). And as some feedback on the UI I have thrown this similar set of fields to the common folk editor and they just figure their way out, so I think you're on your way to success! I have thought of rewriting my module to use the second approach you propose @BrendonKoz doing more rrule calculations on execution and maybe relying more on cache instead of throwing it all at the db, I also read somewhere about saving the first and last date of the occurrences and save them for db querying purposes.

Hi @Robin S! Does setting the default value in the field setting help you to set the default selection option? (I am specifically using Radios input) Thanks for this great module!

Just trying things! haha My thought was to have it all scoped within the page edit process, since Inputfield render could pontentialy happen all around? I have indeed done that hook you show buildFormContent() but in the current specific scenario the field is within a repeater so I cannot edit it on the main form. I think this is what I was looking for, fantastic! Although I see an interesting observation from @bernhard in that topic. Will give it a shot and come back! Thanks everyone!

I had though of this hook: $wire->addHookBefore("ProcessPageEdit::buildFormContent", function ($event) { wire()->addHookBefore('Inputfield::render', function ($e) { $inputfield = $e->object; if (strpos($inputfield->name, "some_field") !== false && wire('modules')->SettingsModule->use_some_field == true) { $inputfield->label = "sample text"; $inputfield->collapsed = Inputfield::collapsedHidden; } }); }); I would have though that setting collapsed property before render would not allow the field to render. I want to handle some fields visibility in a settings module I use to manage enabling and disabling features in ProcessWire. An alternative strategy I do right now is that on the module save config I check for the module settings value and set the field to have it's input collapsed to hidden, but I'd like to think there is a more dynamic way at runtime? Does anybody have something like this working?

Would if be possible to base the array configuration based on a page tree branch? For example, to allow end users to define multiple taxonomies (like Skyscrapers City, Height, etc). This way the page that contains the custom field has "dynamic inputfield page reference fields" based on the tree branch.

Will try this right away!

Hi! Just want to check if anyone has come across this: I have this random scenario in which apparently the session variable is not set when a second instance is getting initialized: This seems to occur when the modules are getting loaded by the ModulesLoader, this is the last bit of the stacktrace being the last item the point where the second instance is instantiated: It happens randomly so not sure if I might be facing a load issue on the server? That is not allowing sessions to be initialized? Although I don't see anything in the Session class code or ProcessWire class code that would stop the variable from being available. @kixe I saw you struggling on the Github issues with multi instance haha so I'm just tagging you try my luck if you might have any experience with something similar. Both instances are running the same PW version and using file Session handler.

Hi crew! Does this field work with SEO Maestro? Thanks!

You'd need to add name to your checkboxes like (example only with offers): <input name="offers[]" value="<?=$m->name?>" class="w3-checkreq" type="checkbox" id="a<?php echo $a;?>" /> Then on form processing you'd need to do sth like this: // sanitize array input $offers = $input->post->array('offers', 'pageName') foreach($offers as $offer){ // do your saving or whatever; }

Hi @Ade! I think your next step is elaborating on the output strategy! Have you taken a look at this section? https://processwire.com/docs/front-end/output/ I think it should answer all of your questions. An also popular and more complete/opinionated output solution is RockFrontend.

Maybe you can do? $page->optionField->find("value=foo|bar|buzz") Not sure what's the property that actually holds the value ? Let me know if it actually works! lol

Nowadays, I might not be a huge fan of how ProcessWire evolved outside the "composer ecosystem", I also feel it might drive people away too. To put an example, popular http clients. Those seem to be very prevalent in its use along a plethora of projects (Guzzle/Symfony HTTP) and their "ergonomy" sometimes is almost like a standard ( i mean some part of it is with PSR haha), I feel PHP devs in general might get turned off very much a project with their own implementation of HTTP client, where they have to figure out how to use it or implement their own modules outside of the PSR-18 scope. Talking about PSR compliance, that could be another topic in itself. Personally, none of this matters to me much. I was kind of "raised by ProcessWire" and it always felt very empowering to be able to read the ProcessWire source code, this is the main thing I've always personally liked about ProcessWire's cohesive (?) and self contained core . Maybe a more experience dev would call me naive? Maybe the lack of experience working on larger teams/codebases, biases my opinion to not care (THAT much) about being more "embedded into the php ecosystem". All these issues probably fall beyond my expertise , I just have a lot of fun building things with ProcessWire ?, need no more than that. Edit: Also let's put in perspective that ProcessWire is older than composer. Would love to hear the opinions of others as well!

I guess static really takes you long ways don't you think?? Kind of the same reason why ProCache is so successful and clouflare is a go-to solution to make any site faster. Regular PHP can get resource intensive, I've experienced this a bit when having to do this 404 optimization , being hit by some bot still crawling wp-content/whatever.jpg it can choke a small server with relatively few concurrent requests. I'm nowhere close an expert at server optimization and leave this all to a 3rd parties like ploi when I can, so there's that too to consider along my experiences. Maybe I'm just cheap on servers ? How to make PW more compatible with JS Frontend Frameworks? Seems like similar CMSs with data-first approach like ProcessWire are using GraphQL for this purpose, and the modules in the ecosystem implement GraphQL queries too. In general the whole static js sites, api first approach seems way out of the league of the things I do, small to mid size corporate sites. Just thinking of adding a whole static project, with it's own dependencies, etc, it starts adding to the maintenance list lol.

We gotta pin all of these somewhere! Maybe here: https://github.com/jlahijani/awesome-processwire ??

Not an exact answer, but this excellent post might give you some direction on how you can approach this conversation with your boss and collueagues in terms of business.

I think ProcessWire's opinions are very worth it. The ones that I feel are right at hand are the selector API and the concepts associated with a Page. This allows you to reduce the amount of decisions you have to take and later execute, letting you go straight into making that real estate/portfolio/etc you want to build. I'd say that with very little backend experience you can build something nice and fast in ProcessWire, with a very advanced and minimalistic and powerful admin backend out of the box. I'd encourage you to give it a try, at least a couple days of work. Give ddev a try to setup your development environment. If you find yourself at trouble don't hesitate to write back, it's an awesome community!

My personal policy is to assume those will only be executable through shell, and save them in site/templates/cli or something like that, but always inside templates so that they are blocked by default by the default htaccess config.