BrendonKoz

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.

Seemingly quite similar to @ukyo's solution via Mystique. I have a local SQLite database that is a mirror of an external vendor's data for our event calendar (I use an API to sync their external with our local so that I can more easily integrate items into our website rather than constantly referring to their API). By parsing available data in the SQLite database (and making it available via a local REST URL) to determine options in the field, I can then use the chosen values as a filter to then query/display matching records in the SQLite database. This particular field was explicitly allowed as a RepeaterMatrix Fieldtype, and then added, in my case. My Mystique template: /site/templates/configs/Mystique.calendar.php <?php namespace ProcessWire; /** * Resource: Dynamic Calendar settings field */ return function ($page = null, $field = null, $value = null) { // Get the data to feed possible selection values $audiences = json_decode(@file_get_contents(input()->httpHostUrl() . '/calendar/audiences.php?activeMerge=1'), true); $categories = json_decode(@file_get_contents(input()->httpHostUrl() . '/calendar/categories.php?activeMerge=1'), true); $fields = [ 'event_type' => [ 'label' => __('Event Type'), 'type' => 'InputfieldCheckboxes', 'options' => [ 'events' => 'Library Events', 'meetings' => 'Public Meetings' ], 'required' => true, 'columnWidth' => 33 ], 'limit_days' => [ 'label' => __('Upcoming Days to Check'), 'type' => Mystique::INTEGER, 'min' => 1, 'max' => 60, 'defaultValue' => 1, 'initValue' => 1, 'inputType' => 'number', 'required' => true, 'columnWidth' => 34 ], 'limit_events' => [ 'label' => __('Maximum Events to Display'), 'type' => Mystique::INTEGER, 'min' => 0, 'defaultValue' => 0, 'initValue' => 0, 'inputType' => 'number', 'required' => true, 'columnWidth' => 33, 'notes' => __('Per event type. Leave at 0 for no limit.') ], 'not_found_msg' => [ 'label' => __('Message if No Matches Found'), 'description' => __('This will be displayed if no events match the given criteria. Leave blank for no message.'), 'type' => Mystique::TEXT, 'columnWidth' => 100, 'notes' => __('HTML cannot be used here. Markdown is allowed.') ], 'private' => [ 'label' => __('Include Private (Calendar) Library Events'), 'type' => Mystique::CHECKBOX, 'value' => false, 'showIf' => [ 'event_type' => '=events' ], 'columnWidth' => 33, 'notes' => __('This is not recommended.') ], 'output_style' => [ 'label' => __('Output Styling'), 'description' => __('Choose the presentation style for any events that will be displayed.'), 'type' => 'InputfieldRadios', 'options' => [ 'list' => 'A Simple Bulleted List', 'grid' => 'A Grid-Like Display' ], 'showIf' => [ 'event_type' => '=events' ], 'columnWidth' => 33 ], 'show_images' => [ 'label' => __('Display associated event images?'), 'type' => Mystique::CHECKBOX, 'showIf' => [ 'output_style' => '=grid' ], 'columnWidth' => 34, 'notes' => __('Images are always taken directly from the calendar and cannot be properly optimized.') ], 'fieldset' => [ 'label' => __('Filters for Library Events'), 'type' => Mystique::FIELDSET, 'collapsed' => true, 'showIf' => [ 'event_type' => '=events' ], 'children' => [ 'audiences' => [ 'label' => __('Audiences'), 'description' => __('Only show:'), 'type' => 'InputfieldCheckboxes', 'options' => $audiences, 'defaultValue' => '', 'columnWidth' => 20, 'notes' => __('Leave blank to show all.') ], 'categories' => [ 'label' => __('Categories'), 'description' => __('Only show:'), 'type' => 'InputfieldCheckboxes', 'options' => $categories, 'defaultValue' => '', 'optionColumns' => 3, 'columnWidth' => 80, 'notes' => __('Leave blank to show all.') ] ] ] ]; return [ 'name' => 'calendar_events', 'title' => 'Calendar of Events', 'fields' => $fields ]; }; Which then renders: I could've looped the field generation instead of the values generation, similarly to what Ryan did above, but that wasn't my use case here. Regardless of solution, it's a very handy way to generate fields, options, and values.

This is likely more of a pro module type of thing, but I feel one area that ProcessWire is lacking from other comparable offerings out there is a site theme that is extendable and customizable from the admin backend. Tying a site-profile to the architecture of the site makes sense due to how PW is built, but being unable to switch a theme (even if temporary, to preview what the same content on a site might look like under a different skin), stylistically, after a site-profile is chosen is a little lacking. Even as a developer I like the ability to change things up now and then, but we don't really have a built-in way (that I'm aware of) a way to alter the frontend CSS via the backend using a known definition of basic templating to create themes. We can create one-off site-profiles, but not reusable themes. Maybe @bernhard is getting there with RockFrontend(?) as a third-party offering, but it would be nice to see some way that this could be supported from a (potentially optional) core (or pro) module. Similarly, I think it may be a good idea to start seriously considering alternatives to our richtext editor. I don't mean actually switching, I literally just mean considering. We switched back to TinyMCE because the newest version of CKEditor was no longer handling data in a similar way and it wouldn't be backward compatible, but TinyMCE is still handling data in the same way, but then after we switched, the company that now owns TinyMCE enacted a new licensing scheme. Although they're allowing an opensource license for now, that may not be the case, longer-term. Having a core proof-of-concept alternative (however the data is structured) would be lovely. No one wants to be caught off-guard! ? 3.1 or 4.0: If only updating the core to support PHP 8+ capabilities, a 3.1 nomenclature sounds good. If in the process of doing that there were additional and significant enough updates applied, maybe a 3.5. If attacking even more functionality, then a 4.0 seems reasonable. ?

Not entirely helpful, but I use a Combo field to hold my blockquotes. I also wanted to make sure that there could be an optional cite available with the blockquote. Although there are plugins and adjustments that could be made to a WYSIWYG editor, they don't always transition easily from version-to-version, or from editor-to-editor. For scenarios like that, I prefer future-proofing it and going with a potentially less user-friendly interface, but one that likely won't break. An alternative that you could use, if you didn't want to find a TinyMCE plugin for this, could be to use Hanna Code. I'm guessing you don't want anything that looks like code of any sort, but shy of a button, it would definitely provide you the ability to keep things within the TinyMCE field and still render a blockquote (with optional cite).

What @da² mentioned above is kind of what I was thinking too, so I don't think he meant harm by it. You pointed out your comfort with HTML and confusion on multiline PHP, so the points are there for us to create an assumption. Apologies if it's wrong! ProcessWire is a content management framework, so it does require some level of understanding of development on both a higher and lower level, or at least the ability to read through code - it took me until just this year to realize that a lot of the documentation are actually in comments in the code, or in Markdown files that developers provide with their modules. I felt (partially) silly for only ever trying to look at written documentation. Like you, I love examples too; much of which exists in the forums, honestly. Anyhow, that being said, I may not be the best person to provide a response, but I do want to try to help you out here. The problem with these questions though are that each and every one can begin the response of the answer with: "It depends." Typically each template is not an entire HTML document, as you'll have one (or two) main layout file(s) that then get merged with your template in one way or another. This would depend on your output strategy as linked above. Since you're just starting out, it might make the most sense to give Direct output a try so that you can start to understand how ProcessWire works. I'm assuming though, since you read through the documentation, you'd also read the last part on the direct output page that mentions its drawbacks (I assume this based on question #3 above). Part of the solution to this, with direct output, is understanding the ProcessWire API. You can retrieve any "page" or page content within the system from pretty much anywhere by using the API. It's extremely powerful. Depending on your needs, you'd likely need to do some manipulation on the returned data prior to rendering it as HTML, but the point is that it's accessible to retrieve. This will depend on your own imagination on how you want to build your site profile out. If you've got some time, you might want to setup some test ProcessWire sites, and install some pre-made site profiles that you can examine and look through to understand how each developer decided how to set things up. There's no real right way to do things, and a lot of it will depend on the project's needs and requirements. Sure there are better ways to do things, but a lot of us don't figure that out until after we've made the not-better solution first. ? As a partial example to this question though - let's say you have a very simple blog. You have two system templates (thus far) - one that lists all blog posts, and one that views a specific blog entry (post). You have four template files: (1)header.php, (2)footer.php, (3)blog.php, (4)post.php. Posts are children of Blog, and Blog is the parent of Posts. (You could consider "Blog" as the homepage I guess in this very simple example.) Your header and footer contain your site's template, split up as expected. The blog.php and post.php files include the header and footer. (We won't worry about navigation at this point, this is a simple example.) The Blog template file uses the API to find and retrieve all Posts, or its children. It then outputs the title, as a hyperlink, to the blog post itself. (This could be adjusted to make sure entries are chronological - normally it would likely retrieve them that way, but depending on how you develop the system that might not always be the case.) if ($page->hasChildren()) { echo "<ul>"; foreach($page->children() as $post) { echo "<li><a href='$post->url'>$post->title</a></li>"; } echo "</ul>"; } The Post template file wouldn't need to know about any other pages; its purpose is to display the content contained for its own page. Surely it can though - it could display next, previous, or related posts. Again: The API can help with those scenarios (related would likely use tags or categorization of some sort). So when someone visits the post, as linked to from the Blog, the post.php file would use fairly simple PHP to output its own content. Let's assume the post system template has 3 fields: Title, Summary, and Body. The Blog excerpt above only shows how to loop through its child pages to output links, the Post excerpt below will have a bit more HTML just to hopefully provide more context. <h1><?= page()->title ?></h1> <div class="blog-summary"><?= page()->summary ?></div> <div class="blog-story"><?= page()->body ?></div> Remember, content above and below are handled by the header.php and footer.php files that are included in the post.php file, in this simple example. I could've added it above, but, well...oops. ? Are you asking about an HTML region, or a ProcessWire markup region? Verbiage with ProcessWire can get a little confusing, so I just want to be sure. Assuming you're just asking about some random area of HTML content on a page getting dynamically loaded from other areas of the system - you'd use the PW API. So let's say you want to get the title of the current page from the header.php file, which is a template file, not a (PW) system "template", so it doesn't have its own PW "page" fields, it's just a file. But you can still use the PW API to query all pages, get a resultset, and then process that data to output what you want. You've seen the children() method above. You can also use the pages()->get() method to retrieve the site's root homepage, which can be referred to either as "/", or 1...so that would be $homepage = pages()->get('/'); or $homepage = pages()->get(1);. From there, you can use the return value in $homepage and then find its children. You now have a first-level for your navigation links, if you decide to setup your navigation based on the tree structure of your site (you don't have to). I can't say whether this is any more helpful or not than other forum responses, or examples in the docs. Generalized questions are really hard to answer simply because there are so many ways to come up with a solution and a lot of it depends on many various factors.

Since this is a local database configuration we're discussing, don't forget that you are the administrator of your own development environment, so another possible solution would be to just create another (different) database user on your MAMP server, and give it access to your project's database. Since it would be a new user, you can choose whatever password you'd like. Then just update the config.php file with the new user's credentials.

Apologies for the confusion - my response was a bit generic since other people do visit topics like this for reference in the future. A blank page, with PHP, (especially when view-source also is blank) is typically indicative of a server-level PHP error - and if PHP is being used to redirect that error to an application's log file, if it fails before it can redirect the logging to that custom location, then you'd need to check the server's error logs. I mentioned both for thoroughness, but in your case since you didn't see any errors in ProcessWire's error log file, you'd want to check your webhost's server's logs. The question about the response being 200 - that's the HTTP response code. You can check that in the browser's developer tools. You can see it under the "Status" column of the Network tab in both Firefox and Chrome browsers. I suspect it's a 500 (error) response, and if it's not sending the error to ProcessWire's error log, the error messaging should be located either under your server's webserver error logs, or if separated out, your webserver's PHP error logs. I would check there. I wish I could pinpoint exactly what the problem is, but like Jan mentioned, the upgrade process rarely fails so it's hard to know for sure.

Getting stuck like that is not fun! Hopefully we can help you out. First though is a little self-help question: Have you referenced all of the steps from the following page? https://processwire.com/docs/start/install/troubleshooting/#troubleshooting-upgrades I suspect there's some sort of error being generated and either debug mode is off (due to the website being in production) so you can't see the messages by default, but the error messages should be in one of your log files, or in your server (apache / php) error logs.

@jploch's PAGEGRID sounds like a good match for what you're describing.

Because you're referencing the image dynamically, it's hard to say what it should be here. What you can do though is, if you have the Tracy Debugger module installed, do a few db() calls on $content to try to identify what is actually contained in the value you're retrieving within $link. Try $content, $block, $content->$block, etc. I suspect that you are just not referencing the correct object name, but since you're calling things dynamically, you'll need to do some debugging of your own to figure out what's going on.

Have a safe road trip! Make it a memorable drive back with your daughter, too, and enjoy the weekend! Thanks for the suggestion on the time fix, @bernhard! I'd seen it a bunch of times but never realized it was a mismatch. Good catch! Looking forward to checking the commit logs, especially for the InputfieldTextTags.

Is that able to handle multiple alignments within a single line?

It doesn't break, or negatively affect the other module now, does it? ? You've been struggling with this for awhile - glad you've made significant progress (and maybe completely solved it)! flydev definitely deserves the credit aside from yourself though, imho. ?

When I was adjusting the Page's editable, listable, viewable, and addable method hooks, I was testing access for one to determine access to another. This caused a bit of a recursively confusing mess. You aren't by chance doing something similar, are you? If so, different calls of the same method can/will return different values due to context, and data that either is, or hasn't yet been set (typically access to templates in my case).