-
Posts
1,290 -
Joined
-
Last visited
-
Days Won
16
elabx last won the day on March 9
elabx had the most liked content!
About elabx
- Birthday 04/12/1988
Profile Information
-
Gender
Male
-
Location
Mexico City
Recent Profile Visitors
20,012 profile views
elabx's Achievements
-
elabx started following Weekly update – 2 August 2024 , Pinkary.com , Developer environment for ProcessWire 3.x on Litespeed with MariaDB? and 5 others
-
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.
-
session variable randomly not set in multi instance context
elabx replied to elabx's topic in General Support
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.
-
Developer environment for ProcessWire 3.x on Litespeed with MariaDB?
elabx replied to tinacious's topic in General Support
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??
-
Request for Input: What features should a PW calendar module have?
elabx replied to bernhard's topic in Modules/Plugins
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! -
Request for Input: What features should a PW calendar module have?
elabx replied to bernhard's topic in Modules/Plugins
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!
-
Remove field from page edit or any repeater field within it.
elabx replied to elabx's topic in General Support
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! -
Remove field from page edit or any repeater field within it.
elabx posted a topic in General Support
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.
-
session variable randomly not set in multi instance context
elabx replied to elabx's topic in General Support
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.