BrendonKoz

I still follow soma on Twitch. He occasionally has (digital) painting sessions. 🙂 Signed up for Pinkary. Hopefully they'll offer an API like the original Twitter days to build out supporting apps. Interestingly, Pinkary runs completely on SQLite.

It looks like you've each chosen the differing options. 😉

Been trying to get my buddy to field test all of these suggestions you all have been making so I can just wait until a clear winner surfaces after a decent amount of time. 🤣 His feedback after I mentioned Sourcegraph Cody was that Cursor makes it ridiculous easy for the AI to auto-generate, and auto-modify multiple files for him. He's saving to Git far more often due to the lack of a single-action, multi-file undo, but otherwise that's the "gotcha" between all of the other suggestions made after Cursor. The assistants are really coming along blazingly fast.

Using a service to determine holidays is one option, but then which holiday(s) do you want to support? Governmentally observed holidays, or perhaps even the silly ones, too? Things can get tricky when assumptions start to be made. A (potentially) simpler approach would be to have two other option areas: Dates to Include Dates to Exclude Since you're attempting to tackle recurrence: it may be desirable to have events occur within a range, but then a business will be closed due to an observable organizational holiday (like an owner's birthday), or alternatively a date exception is made where an additional entry would want to be added, and it's known ahead of time. Alternatively, it's just as easy to delete some after creation, or similarly clone. 🙂

Calendaring and/or events management is a large undertaking, unless feature requirements are kept extremely minimal on purpose. The hardest, but often most requested aspects of a calendaring solution would likely already have discussions in the Recurme module's discussion topic, and Ryan's Date Range Fields (ProField) topic...so, essentially, recurrence (RRULEs), and how to handle them. I remember you even broke down the various problematic ways of attempting to solve searching, or retrieving, for events with, I think, a Fieldtype module, where the problems were with recurrence and ranges. For storing recurrence of events, there are also two potential scenarios, architecturally: Create individual unique entries (PW pages, in this case) for each event that is part of a series - it can then be modified independently even if mildly associated to the original group. Create a single entry that stores metadata about the recurrence to extrapolate virtual entries from the original. Both options have their pros and cons, but I'm not familiar enough with the research behind them to understand what would be best, or if there's even a hybrid approach. I'd imagine the first would be far easier to implement and maintain. Related to RRULE would also be vCalendar/iCal/ICS support. Best suggestion: If feature suggestions are calendar/event adjacent, but don't actually belong to calendaring, do not support it. I was just thinking how iCal is used to help customers remind themselves about events, but more often customers don't know how that technology works, so offering an email reminder for the event could be a feature suggestion. However, emailing could easily be handled by a developer that is taking advantage of your module and expanding on it, so although emailing a reminder about an event is related to an events calendar, emailing itself is not an integral part of an event calendar. 😉 @Jonathan Lahijani might have some suggestions too, with his use of one with the Geffen Playhouse. His solution was different, but issues he dealt with may be of use. Good luck, Bernhard!! 💪

Hard to know exactly what to suggest as many different scenarios could affect responsiveness. (Re-?)Rendering images could easily slow things down, as could page reference properties that aren't loaded until called/necessary. Depending on your setup, using findRaw() or findMany() might have a positive impact, as would your autojoin; if you think an autojoin might only be necessary for your one scenario, you could look into findJoin() and whether it accomplishes the same end-result on that page. For a ProcessWire (Pro) module assist, there's always ProfilerPro, as well.

Alternatively, you can just use different logic on your interactive procedure. I do something similar to this with just a single field, where the first image (manually sorted) in an images (Multiple Images field) is used as the primary/cover photo. All of the rest are placed into the standard gallery. The API makes that easy with the WireArray class methods of first() (only retrieve the first when using the "cover photo" as a portfolio thumbnail) and shift() (if you wanted to separate the first/cover photo from the rest of the group in a template). Images are files, so you can use the same logic for file fields. If you don't want to modify your template(s) and would prefer to keep your logic flow intact, what dynweb mentions should work too. 🙂

Thanks, Ryan, for implementing that change, and Pete for making the suggestion! It's obviously not a huge headache, and the slider interface itself is a quicker and easier way to modify things rather than going into each field individually, but I too kept looking for a simpler option, so this is a nice change. I'm sure I'll more often use the double-click method moving forward (esp. since 33/33/33 looks weird, so I set things to 33/34/33 for thirds). With regard to the dedicated column width range slider, since there's no photo example of that in your post, does that also include a direct numeric input, or is it only a range slider? It may be nit-picky, but I think a numeric input might be even simpler/quicker. (Will you be using a <dialog> as the UI for that?) Either way, this is such a small and simple thing that will just make me smile, so your effort here will definitely not be wasted!! Have an awesome weekend.

Good catch. Neither of those modules are enabled by default. Looking up that module and finding a discussion, this might be useful to read up. In the description of the module, it states that it is under development (i.e.: not finished). ?

If the JavaScript filenames are the same per theme (likely), your browser might just be caching them. Do a hard refresh and see if that updates how the alerts are rendered. I can't tell what browser you're currently using, so... Firefox: CTRL+F5 Chrome and Microsoft Edge: SHIFT+(clicking on)?️

Yes, please.

Success. ?

Good catch! I never thought about that, but yes, I always enable that upon first installation too, and disable it as needed. Another good catch because, honestly, I never really look at the host's customizations. If I want something different, I used to have to compile and configure PHP myself, so I aim not to have to do that. That said, PHP's output buffering functions (ex: ob_start()) are usually used when dealing with session handling, and I just presumed Ryan was using them. Perhaps not. I'll have to try @poljpocket's install.php file and see, quickly, if it fixes things (easier than searching the entirety of the codebase for ob_start calls and if/how they're used!).

For the production server, I SSH'd in and used wget from the PW download/core URL of the zip file. I then unzip'd, and rm'd the zip file. `mv` the files from the processwire-dev (including the dot-files) so that everything was in root, and then ran the installer. The access rights of the files look ok: 775 for folder, 664 for files (600 for session files). The session folder is writeable.

Production (shared) Server (Host: Dreamhost): Completely fresh install of the DEV version (v3.0.241) Host OS: Ubuntu Jellyfish v22.04 PHP: 8.2.18 w/Zend Opcache v8.2.18 running as CGI/FastCGI MySQL: 8.0.28 running on Ubuntu 20.04 Apache: 2.4.52 running a custom (unpublished, by the host) mod_security There are no logs generated in the asssets/logs folder aside from modules.txt and system-updater.txt, and both were informational, none contained actual errors. Here are the errors captured from the server's errors.log file, which unfortunately are unlikely to be too terribly helpful, beyond what the image itself shows: PHP.ini file:

Development Environment Host OS: Windows 11 devilbox (predefined docker config, so a DDEV competitor) using shared drives between host and guest PHP: 8.2.1 Apache: 2.4.54 MySQL 8.0.32 ProcessWire (recalled as tested) from 3.0.229-3.0.241 I truly do believe it's due to my test environment (which also seems to cause a Tracy error when using the console) causing race conditions, and primarily because of the shared drives. I'll try to spin up a test on our host just to verify that though and report back.

It might be best to disable Frontend Editing on fields that are going to be handled with Markdown (or possibly any fields that have Textformatters that swap in/out content dynamically). I'm thinking that because Frontend Edit is not aware of the additional processing that a textformatter will do, it is only presenting and saving the data as it sees it based on the Fieldtype, and (in the case of textarea) Content type therein. @bernhard You have front-end editing in your Rockfrontend; does it use the core's frontend page editor, or did you use your own? I'm curious if you've run into any similar issues.

If you're intermingling this field with actual HTML on purpose, it would make sense that there are problems. As I mentioned earlier, Markdown should accept HTML, but due to how this all works together, I can see scenarios where there would be issues. I just manually typed in <strong>Test this</strong> into the Frontend Editable textarea for the body field, and saved. The text was bolded. OK. I went back to edit it and the text was still bolded, but there were no HTML tags for me to modify to un-bolden it. CTRL+B didn't work because that's a browser control to open my bookmarks. It would have to be modified in the backend, or I'd have to combine Markdown with a richtext editor (which I have not tested, and there are other modules for that, too). Therefore, any broken HTML would just be broken HTML. NOTE: I did not adjust any Input settings, so "Strip Tags" is not enabled. I don't believe HTMLPurifier is processing this input as it's currently configured, which is its own problem... See below (the "Edit this page" should not be bolded, it's hardcoded text, part of the page template, not part of the body field.)

I was curious, so setup a test environment. Blank profile. I created a `body` Textarea field and applied it to the `basic-page` template. I enabled the core's TextformatterMarkdownExtra module, and configured it as such: - Parsedown Extra - Safe mode: No (realistically this should be "yes", but setting it to yes caused HTML to be HTML encoded) For the body (Type: Textarea) field: - Text formatters: Markdown/Parsedown Extra (ONLY this; HTML Entity Encoder caused issues when combined with the Markdown formatter) - Inputfield type: Textarea - Content type: Markup/HTML - Markup/HTML (Content type) [options]: None selected, though this is only due to it being a test; these should be fine to adjust Choosing "Unknown/Text" for the Content Type while using Markdown seems to cause some issues when combined with Frontend Edit since the rendered text after being formatted is HTML, not text. I also had a strange scenario with Frontend Edit at one point where the text generated by Frontend Edit into the `body` field using contenteditable was "<div>Body text</div><div>More text</div>", but interestingly, ProcessWire only rendered "<div>Body text</dv>" into the HTML, though when I activated Frontend Edit to modify the field's value, the full text was displayed. I believe that may have to do with choosing "Unknown/Text" for the content type while using Frontend Edit due to how contenteditable works. That being said, once I configured things as it is configured above, I was unable to reproduce any extra newlines being produced in the final markup, no matter how many times I edited and saved.

This is likely caused by my development setup using Docker and shared drives (slow read access), but I'm just wondering if anyone else is seeing these (warnings) at the end of (or during) installation, or if it's just me. Oh, this is the current DEV version of PW: 3.0.241, though I've been seeing these errors as far back as I can remember.

That appears to be a result of contenteditable being applied and used on an element; it creates newlines and <br> tags on each ENTER/RETURN press (or similar end-result with pasted content to render it similarly). FrontendEdit does take into consideration the difference between standard Textarea and Richtext fields...unfortunately, Markdown technically does validly accept HTML in its markup, so although it doesn't provide a WYSIWYG interface, I'm assuming it doesn't parse out and remove embedded HTML by design. I guess the problem here is that ... Actually, since the Markdown/Parsedown here is applied from a Textformatter and not a custom fieldtype, and the fieldtype is still a standard Textarea, I'm back to being confused. ? It might require a deeper dive into the code of that module than a cursory glance like I gave just now.

I haven't tried frontend editing yet, but since no one's yet replied, I have two possible thoughts: You said there's a Markdown/Parsedown TextFormatter. Is there, by chance, a Newlines to XHTML Linebreaks TextFormatter enabled too? That might do it. If you're manually typing this content in, just in case the interface is adding Windows' style line endings, try holding SHIFT when pressing ENTER/RETURN at the end of a line in order to remove the possibility of extra line-endings being included (ex: \r\n instead of just \n). If you're copying and pasting, similarly make sure the source text doesn't use those line-endings. ?

I've been wanting to review the 5 pages of responses and summarize the findings, but what I will say before (if?) I get to that: There seems to be three primary audiences that PW is catering to, or that it can potentially cater to: Developers (ease of development, API, headless, documentation, module development/sales, etc) Clients (security, continuously developed, version stability, availability of developers) Consumers: A developer and client all in one (all the ways in which it competes, and how it's different) It may not be evidently clear what the project is primarily aimed at catering to, and perhaps that needs to be clarified, whether directly by Ryan in terms of what he is interested/able in supporting, or by the community's desire (as Ryan seems amicable to our opinions on steering it). That may also help guide any potential website redesigns. I think this is an important question to really consider and have answered. Although it can be done, it's really hard to properly target all three of the above, all at once.

It doesn't look like you're actively using a ProcessWire Fieldtype for generating or storing the values of your checkboxes (upon/after submit), and that you're manually creating them instead (which is fine, and more often expected on the frontend anyhow), so that means the checked() method won't do you any good. @Mirox has the right idea. In that example, the value of $selectedCategories likely came from the ProcessWire API for inputs: $input->get->category. Be sure to read over security precautions/implications when dealing with user input, and properly sanitizing it. ?

When dealing with checkbox or radiobox inputs, if the name of the individual checkbox/radio inputs remains the same, you can set the name to an array-style, such as: <?php foreach ($pages->get(1104)->children() as $category) : ?> <div class="flex items-center"> <input id="<?= $category->id; ?>" name="category[]" value="<?= $category->id; ?>" type="checkbox" class="text-gold-600 h-4 w-4 rounded border-brown-300 focus:ring-gold-500"/> <label for="<?= $category->id; ?>" class="ml-3 text-brown-800"><?= $category->title; ?></label> </div> <?php endforeach; ?> Note the name="category[]". This then assigns the returned value(s) of the form input into the $_GET['category'] variable as an array. The way it's written now, whatever is chosen last will overwrite what was set/chosen prior, which is why you're experiencing what you're experiencing. Unlike a (multi)select element that provides option values that are assigned to the select's name, the radio and checkbox items are individual inputs with an expected (by us) association.