wbmnfktr

FrankenUI was the sole reason for me to dig into UIKIT again after years of ignoring it. Still not using either of them but it's great to have options.

$out = ''; $out .= <<<EOT <div class="player youtube"> <iframe src="" data-src="https://www.youtube-nocookie.com/embed/$video" data-category="external_media" data-ask-consent="1" frameborder="0" scrolling="no" width="640" height="480" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> </div> <div class="link youtube"> <a href="https://www.youtube.com/watch?v=$video" rel="nofollow" target="_blank">Watch on YouTube.com</a> </div> EOT; echo $out; This already has PrivacyWire attributes to make it work with it. Here is the HannaCode export: !HannaCode:youtube:eyJuYW1lIjoieW91dHViZSIsInR5cGUiOiI2IiwiY29kZSI6IlwvKmhjX2F0dHJcbnZpZGVvPVwiSHNEamxrZGpMZHdcIlxuaGNfYXR0cipcL1xuJG91dCA9ICcnO1xuJG91dCAuPSA8PDxFT1RcbjxkaXYgY2xhc3M9XCJwbGF5ZXIgeW91dHViZVwiPlxuICAgIDxpZnJhbWUgXG4gICAgICAgIHNyYz1cIlwiIFxuICAgICAgICBkYXRhLXNyYz1cImh0dHBzOlwvXC93d3cueW91dHViZS1ub2Nvb2tpZS5jb21cL2VtYmVkXC8kdmlkZW9cIlxuICAgICAgICBkYXRhLWNhdGVnb3J5PVwiZXh0ZXJuYWxfbWVkaWFcIlxuICAgICAgICBkYXRhLWFzay1jb25zZW50PVwiMVwiIFxuICAgICAgICBmcmFtZWJvcmRlcj1cIjBcIlxuICAgICAgICBzY3JvbGxpbmc9XCJub1wiXG4gICAgICAgIHdpZHRoPVwiNjQwXCJcbiAgICAgICAgaGVpZ2h0PVwiNDgwXCJcbiAgICAgICAgYWxsb3c9XCJhY2NlbGVyb21ldGVyOyBhdXRvcGxheTsgY2xpcGJvYXJkLXdyaXRlOyBlbmNyeXB0ZWQtbWVkaWE7IGd5cm9zY29wZTsgcGljdHVyZS1pbi1waWN0dXJlXCIgYWxsb3dmdWxsc2NyZWVuPjxcL2lmcmFtZT5cbjxcL2Rpdj5cbjxkaXYgY2xhc3M9XCJsaW5rIHlvdXR1YmVcIj5cbiAgICA8YSBocmVmPVwiaHR0cHM6XC9cL3d3dy55b3V0dWJlLmNvbVwvd2F0Y2g/dj0kdmlkZW9cIiByZWw9XCJub2ZvbGxvd1wiIHRhcmdldD1cIl9ibGFua1wiPkRpcmVrdCBiZWkgWW91VHViZSBhbnNjaGF1ZW48XC9hPlxuPFwvZGl2PlxuRU9UO1xuXG5cbmVjaG8gJG91dDsifQ==/!HannaCode

As @qtgurusaid. Thank you @Wanzefor Template Engine Factory and the Twig extension for it. Can't go without it.

I know I used this module a while back but moved on and used custom HannaCodes for video embeds for several reasons. Maybe this could be your way as well - combined with HannaCodeDialog to insert the code into your textarea fields.

🥰

Even though I haven't used jQuery in a long time I know that both backend and frontend are independent from another in most cases - unless you use some modules like FormBuilder or LoginRegisterPro which use jQuery on their own. So therefore it shouldn't be a problem to use different version until some backend modules (like those mentioned aboved) come into play. There could still be issues for when you are an admin and both jQuery scripts are loaded (in some weird cases, like cache or whatever). In your case ProcessWire's jQuery might be necessary for frontend-editing to make it work. Your solution works for now, but maybe you could try another approach like putting your scripts into an if-statement and only load your jQuery in case someone is NOT logged-in. See: https://processwire.com/api/ref/user/is-loggedin/

Wow... 🤯

They will be ready soon. Update/additional details to make things clear: While I was pretty happy with the first iteration of my ProcessWire rules (from Grok and others) they seemed to be too large in total for Cursor and Windsurf to handle them each time. Right now I'm splitting that one rule file into smaller chunks so that whenever a PW-specific topic comes up, the IDE can find a single file with details (or I mention that file to make sure). Especially in regards to modules, which is a larger topic, or URL hooks which is only a blog post and therefore was probably never in any training data (I'm assuming here, as ChatGPT and Sonnet all imagined their own version of that that could have been). For those wondering: I always added snippets/recipes/examples to each section to make sure the IDE uses the code I want to see as a result later on. Sure, with placeholders and relying most of the time on basic PHP code, yet PW is a different animal. Neither Cursor, nor Windsurf are really keen about what's going on. The sample/training data was probably way too little at all. Hallucinations were way too common and ... you could imagine. How I found these issues: I have two larger and more complex projects on the desk right now and it didn't work out as expected and I had write most of the code by myself on a basic level with inline docs and @TODO comments, and just asked the IDE/AI to make it follow PHP's best practices - such as error handling (which didn't work most of the time, as PW has it's own way - kind of). So...: While I'm still super happy with the outline of rules created by Grok3, the IDE/AI needed and needs more input and details about PW most of the time. It helps to have snippets, like RockMigrations by @bernhard provides - which was still off for quite some times but were easy to fix manually.

Based on the given Rephrasing prompt from @gebeer I played around and created this file/rule to import either globally or put it inside my rules file - could be a self-contained .mdc file as well in the future: <!-- Global Rule: 1 --> --- name: Global Rule #1 description: The very first global rule to apply the moment the user starts a task globs: **/*.* alwaysApply: true --- # Before starting a task 1. analyze the given prompt and understand the intention 2. rephrase the user prompt in concise technical terms focusing on: - specific technical task scope - affected components/files - required functionality changes 3. preserve the users intent in the rephrased prompt 4. output the rephrased prompt and ask for confirmation with exact phrase "Act on the rephrased prompt? [y/n]" 5. IMPORTANT: after asking for confirmation, STOP and wait for explicit user response 6. proceed ONLY after receiving "y" confirmation, otherwise ask for clarification 7. when proceeding, act only on the rephrased prompt and start your output with "✨✨✨" and {name} of rule <!-- /Global Rule: 1 --> It's pretty much the same prompt but in a different structure with additional metadata. Cursor and Windsurf seem to love those little nuggets of metadata. The frontmatter - indicated by leading/trailing triple dashes - allows to add metadata. In this case you could output the rule name later on when needed like in #7., or give additional context whenever this rule should be applied. So far it works pretty much as expected in my testcases - which where in bash scripting (.sh), Laravel (.blade.php), PHP, PW-specific, AstroJS (.astro, .tsx), NextJS (.tsx). In total about 100 credits in Windsurf through various projects I had to do stuff in. Example 1: Built this maintenance script - based of 3-5 other scripts, with about 15 prompts to make it work on Ubuntu, Debian, Arch. I'm pretty happy so far as the script also adds whatever I need - like NPM, PNPM, Flatpaks if not installed. Could become a whole project on its own. Super stoked! Example 2: Asked for optimising my .gitconfig file and put suggestions into a new file. The result... looks good, not sure about each and every detail based on personal preferences but... YEAH!

I'm a bit short in time right now so I might have to write a follow-up to give you a real and more complete answer here. But in the meantime - a short summary: each and every client/side project of mine get's a click-dummy of the final product to see how it could work out, what's needed and so on. I use Astro JS for that as it's super flexible to work with, I can deploy it somewhere at Netlify, Vercel, or Cloudflare. Each commit is a new build. I can share it with everyone - frontend and backend-wise. It's more or less just HTML, CSS, JS - some parts of it might have a TailwindCSS or AlpineJS flavor but still super basic. And the big plus: ALL build steps (TailwindCSS, AlpineJS, ...) are already in place. If needed I can connect it to an API to fetch articles, news, or whatever kind of data to make it look more real or to go super fast - especially when migrating from WordPress where there is a RestAPI or GraphQL almost always in place already. For sideprojects I connect to api.domain.tld, grab JSON and render out either pages or just parts of the project on-build. for side projects in very early stages that would be the state for the next 3 to 6 months to see if the project get's some kind of traffic - for client projects this is the base to start the real work. from there I take all the component and move them from .astro to .twig - the difference is so minimal I could use Regex to make the changes most of the time. feeding all layouts, components, partials, blocks, however we want to call those code snippets into ProcessWire is pretty easy, when you know where things have to go and most of the time you only change the parts that define the source - so from a JS fetch() to a $pages->find('...') - and of course you have to build out the ProcessWire backend stuff, hooks, automation, and whatever you need or want. Some would say there are a lot of unnecessary steps in this process and they could be right, but I prefer to test projects early on and hate to look at Figma files or Illustrator screenshots. So there is that. I always worked that way and that will probably never change. On the technical site you have think about 2 systems running side by side. Astro JS on Netlify, Vercel, Cloudflare or a VPS with NodeJS and ... lots of other stuff ProcessWire with database and everything it needs on a sub-domain. You could fit everything onto one server but it can be quite painful to get this up and running so I use a regular hosting provider for ProcessWire and one of those mentioned above for Astro JS. The output is, most of the time, 100% static and build on-demand with data and content available at that moment. You could make it more dynamic with AlpineJS or HTMX but only for small parts, and not for articles and news - as those wouldn't exist within the static build. As this turned out to be broader as expected please feel free to ask about more details where needed.

Put those posts here in the Dev Talk in their own topical threads. I personally love those posts and looks behind the scenes. So... a +1 from me here.

Add a 2nd build file that only uses parts of your CSS/less. / ├── dist │ ├── backend.css │ └── frontend.css └── src ├── _index-backend.less ├── _index-frontend.less └── less ├── blocks.less ├── buttons.less └── ... In the build file you only import those parts you need/want in the backend or WYSIWYG editor, while the frontend will have everything. // _index-backend.less // we only need the buttons in the backend @import "buttons.less"; That's how I structured my .less/.sass/.scss files.

Just a little side note for those that like to play and experiment: I was playing around with Grok 3 beta (via x.com/grok.com) and asked for specific Processwire rule files to use in Cursor/Windsurf. And let's say: I'm quite impressed how good those rule files look. 🤯 I'm in the process of moving everything around and can't tell if they work as good as they look but Grok3 seems to be even better than Sonnet 3.5 and 3.7 for technical tasks like these.

Back when I started this thread I tried multiple ways, modules, and custom exports. From JSON to AppApi to GraphQL and everything in-between. I still use basic JSON in some projects or just grab what I need via HTMX nowadays. I pull in only simple data via JSON I might need on build time or fully rendered HTML with HTMX in my AstroJS projects. Whenever I start a new project and need a MVP-like skeleton of it, I go with static content in Markdown/MDX in AstroJS, later on I'll migrate to 100% ProcessWire in most cases. It just works, I feel home, know how to handle stuff, have everything I need and with ProCache, LoginRegisterPro, and FormBuilder I can keep everything on my server and don't need things like Supabase, Neon, FormSpark or whatever. So to finally answer your question: no, not anymore

Is there a chance you are using RockMigrations and somehow triggered an older migration that removed fields from that template? Happened to me yesterday and took me a while to find. And to make it clear: it's intended behaviour - see screenshot. The minus tells RockMigrations to only have listed fields in that template. Without the minus I could add fields via backend and run migrations without removing manually added fields.

Is your database set to utf8mb4? // site/config.php $config->dbCharset = 'utf8mb4'; If not... saving emojis and emoticons won't work as expected. Not sure about the steps to convert a db to accept it. Sorry.

Publish it as a gist on Github or in case you are interested write a full recipe and publish it on processwire.recipes.

It's not you. That's me. I need to narrow down things first before I start thinking more deeply about problems and solutions. it happens so often that those exact tiny details can make a huge difference.

First idea... is there an actual homepage template in all folders? Does your logic always return the correct strings on the homepage and other pages?

The user here is only on the frontend aka consuming content from those websites? Well, than those 400ms can be squashed by using Cloudflare as CDN. Cloudflare is close to everyone, especially regular users. Your backend users/admins/whoever might probably be just fine with the additional 400ms when adding content, notes, and other data.

... but it feels like home.

To dump my thoughts here: What's the main goal? Or ... What's the reason you need an off-site user management system? How real-time does it need to be? Putting everything on one server (#1) would be perfect as you then could bootstrap ProcessWire into other instances quite easily and go that route - which actually would be #4 - but you would lose those juice ms on each request you already mentioned. Ideas #2 and #3 sound fun but yes, probably total overkill. Never used or tried those, so no idea how well that would work out at the end here. #4 as mentioned would probably need all sites/instances on one server as well. Not sure if and how you wouild do this across multiple serveres. But here comes idea #5: Get a server that's somewhere in the middle and build a your user management there. You then could put an API on top with either your custom code or something like the AppApi module and roll your own auth for some or all users. Probably a bit overkill as well, yet another approach could be some kind of API to sync accounts from and to that server. Trigger actions via webhooks in case new users were added or removed somewhere. Could be fun. Could be pain. Not sure for now.

I love it!

Not 100% sure but isn't this the default behaviour of browsers or maybe even the web server to encode umlauts/special characters? I know we can enable them in ProcessWire itself and use them in page names but not sure this would change the behaviour in Jumplinks as well. For the time being you could at these to the redirects. How often do you experience these kind of URLs?

Is that one public? If so... change that! For everything else... I'm absolutely not sure this was or wasn't a hacking attempt but at least it looks like someone was scanning the website and the server/hosting - especially the database - couldn't handle that much traffic/pings/requests. This could have been Google, ChatGPT, or whatever crawler/bot/spider is active right now. That FieldtypeText log at the beginning seems to indicate there is something it can't handle for whatever reason. Might be a hook that updates a text field or something. I'd probably use this as starting point for everyting PW-related. Please check the other /site/assets/logs/ files for more entries, check server log files to see what happened elsewhere on the server and so on.