wbmnfktr

It's been two weeks now since I switched to Cursor Pro full-time and I have to say... "Thank you, Supermaven. It was an awesome time. Fare well, enjoy your life now. Was a pleasure to meet you. 😊" I'm there, in a different way as planned, yet... I reached that point. And I am super happy. Best part... Docs included. Anyone else of you moved completely or at all to Cursor?

There is so much the community already has a solution for... we just have to remind ourselves about these solutions. (to be fair... I regularly can't remember core functionalities as well) Especially in cases like this, I would vote for something like a "merge this module into core"-principle of some kind, yet I want to see module authors thrive for and because of their efforts. Similar to the Weekly update – 2 August 2024 announcement - where we saw similarities to already existing solutions:

I became so used to use Template Field Widths that I almost always install it on larger projects. Super fast editing of values, tabbing around and done.

Oooh... that's where those screenshots came from. Sorry, no idea what's happening there with Language Packs. Your Language Pack doesn't look that different compared to other packs.

Never did this but you need an account for that part of ProcessWire.com and have to register an account here: https://processwire.com/modules/login/register You can link to your profile here in that process, too. Seems to be separated from the forums.

Damn... you are right. That should probably work even better. Always forget that we have that option. Sorry.

Podcast you probably want to watch:

Besides your workflow makes me feel a bit uncomfortable with all that raw HTML in input fields, and things like that, I struggle to really understand what pages you are looking at for changes you made and how you look at them and test them. You mention the change of session keys, which only happens in case the session changes, which is rarely the case while working in the backend. There could be of course things like enabled developer tools in the browser, using a CDN on the website, and maybe even code you use in your custom login screen. To make it clear: Usually working in the backend should NOT take two tries to save a change. That's rarely an issue someone would face. I can happen, when for example you are behind a VPN (like in Opera, without knowing), cookie blockers, adblockers, and even a not so perfect setup of Cloudflare CDN that tries to cache everything in your backend. To get you going: is this a local or remote setup if local: what kind of setup is that? (DDEV, Laragon, Docker, Custom) can you post screens of your editing and testing pages (so we know where you actually are in ProcessWire)

In my Front-End Page Editor settings there aren't even any image fields listed, so I guess: No, not possible. Maybe there are hooks or other ways to achieve that, but I wouldn't bet on this. Just an idea and never tried it but what about using a custom/different field like image_description (text or textarea field) you show somewhere in the frontend/on the page but only for admins, so you can edit it, and use it for the image desription by referencing it in the image tag. This way you can activate it for frontend-editing, edit it, and use it with the image. Multiple images wouldn't work here. // the normal way <img src="<?php echo $page->image->url(); ?>" alt="<?php echo $page->image->description; ?>" /> // the other way <?php if($user->isLoggedIn()):?> <div class="show-image-description-text-to-edit-in-front-end"> <?php echo $page->image_description; ?> </div> <?php endif;?> <img src="<?php echo $page->image->url(); ?>" alt="<?php echo $page->image_description; ?>" />

Ok... that looks really weird. First... make a backup, then... Check all installed admin themes, disable, and uninstall those you don't use. Stick with the default for now. Do you use any other modules that change styling and or behaviour in the backend?

You forgot the screenshots.

New off-topic: The moment you remember you can easily disable mandatory fields in FormBuilder with just a few double-clicks and can finally stop entering data into 20+ fields. ??

How do you put the files on the server - FTP, SFTP, Rsync, Samba share or so? Do the access rights (read/write) of those files look ok? Is the session folder writeable?

So... at this point you, @BrendonKoz, and others should post all details about their setups to find the issue. Those warnings might not have an impact, BUT they are a very bad look when trying/installing ProcessWire for the very first time. For my current DEV-setups: latest DDEV (Host: Ubuntu 23.10, not virtual) PHP 8.2 MariaDB 10.4 Apache FPM InnoDB, utf8mb4 Latest successful ProcessWire version: 3.0.241 For my current PROD-setups: PHP 7-4 to 8.2 MySQL v. ??? on webgo, and whatever on Hostinger Apache - not sure how it runs there (webgo, Hostinger) InnoDB, utf8mb4 and a lot of MyISAM with utf8 and utf8mb4 ProcessWire from 3.0.165 to 3.0.241

Nothing like. Not even similar in the last couple of months. Even when installing it into an Nginx environment. And the worst part... not even a clue where to look. Is there more in the logs of either PW or Apache or Docker? Just installed a 3.0.241 (fresh download) a couple of minutes ago without issues (PHP 8.2, MariaDB 10.4 via DDEV).

That'a a core module. So it's in the /wire/ folder for a reason as it is part of ProcessWire itself. In this case you also don't download it, you just activate it. Nothing to worry here as well.

Ok, we have the same settings now. Besides mine is actually a Textarea (Multi-Language) field, but I don't think that's the issue here. I uploaded a short clip of how the field and/or frontend-editing now behave. It worked way better before. https://youtu.be/OOUKdEzH4Tc After all I maybe really just disable it again. As mentioned before I rarely use it and I have a quick link to the edit screen anyways.

I could support that statement, yet I now have worse problems than before and makes it totally unusable. I might missed something from your settings. Otherwise this is cursed. Can you post screenshots of your settings, please.

Until today I didn't know how burnt CPU cooling paste smells. ? I had enough fun for now with importing those datasets, time for the frontend shenanigans.

I am still not sure it this is a weird glitch or bug or maybe even expected behaviour. Until this very thread here I never really noticed any issues and didn't find any messed up articles so far, yet to be frank I rarely use that feature on a daily basis. I mostly enabled frontend-editing for some fields to clean up formatting, adding a sentence, fixing a typo, and similar tasks while browsing through the site. On the other hand I'm in the process of migrating some client projects over to Markdown textareas as those clients feel more comfortable using plain-text than HTML editors - and they just can't really f**k up things that bad in there. So it could become a concern when I enable frontend-editing there. It's not planned, but could be the case. @ryan , maybe you could give us more insights here? Is this expected behaviour or a weird glitch/bug?

I won't try to rebuild the NextJS version of it just to mimic every detail but build a usable app like it - don't know yet how every part will work and look. But for sure I won't load tons and tons of stuff just because something was in hover state or so. Maybe there is a reason for that but there wouldn't be one in my version of it - probably. I just want to see how nice and easy it could be to build such a tool and how fast it is at the end. As said before: I won't copy the app to the detail, I will try to build an app/tool that works and has all or most of the features. The most fun part until now was to realise that importing 50k items is something different than handling 50k items that grew over years. A nice reality check.

Couldn't resist and started playing around with it. What I can say so far: Importing 50,000 pages via ImportPagesCSV isn't the way to go I somehow remembered it to be faster and a bit more reliable even with such a large set of pages. Maybe I am wrong on this but I almost always use this module for CSV imports. wired together a custom import script Not all books and details where imported due to weird symbols/letters/words in the book titles and didn't bother fighting through that. ? I skipped almost everything on the first run and just created pages with titles. The database growth was kinda surprising for me. All that took less time, than trying to import everything with ImportPagesCSV. Those weird symbols/letters/words I mentioned earlier: Database difference pre/post import 50k pages with just the title: Created a public Github repo for this: https://github.com/acabelt/pwbookinventorydemo Feel free to play around with it. Added a working basic search function using HTMX and Twig Commit: bdf60d3 Will update this post with more details as they occure.

That sounds nice. I think. Could be fun. Doesn't Discord allow such things? If so we could go there. There is a ProcessWire channel already. However... love those Community Calls, Office Hours or how others call them.

That sounds great. Would it be the cloud-hosted version of TinyMCE then we would have in ProcessWire? If so GDPR could become a new issue and topic.

Changing the order results in chaos as the markdown will be shownas unrendered HTML - which is actually correct behaviour here and makes sense. I just removed HTML Entity Encoder, disabled Safe Mode, and played more. The result stays the same: at some point the textarea field or it's rendering becomes unstable and lots of <p> tags were added. Then I looked into the dev tools and saw that being in frontend-edit mode it outputs actually HTML and not real markdown - like it does in the admin. With CKEditor or TinyMCE fields it's fine and expected as those are WYSIWYG editor but here in Markdown it's not. Tested further and found that it is the same with real plain text textarea fields. It makes the rendered HTML editable and doesn't render the textarea as InputField like in the admin. Frontend: Backend: So... not perfect for plain text/markdown fields. I might be totally wrong here but it's either: Output Formatting or the fact frontend-editing doesn't load the real InputFields It's curious that I only ran into this problem because I tried to run into it. I use this for quite some time now, 3 months at least, and never noticed an issue. Maybe I should look into each and every page now. ??