bernhard

Ah and I'm not sure if that is a good idea. wire('page') is the current PW page. Did you check if that is really the correct page and not the page with id 10 that is responsible for rendering the page edit form?? I'd better get the edited page from the HookEvent: $page = $event->arguments(0);

I think you are just missing this after $field->description = ... $page = $event->object->getPage(); $field->value = $page->meta('custom_text_field'); ... and maybe some sanitisation in saveCustomField() ?

Adding custom PHP code to any page in the backend is extremely easy as well (if you know how) ? <?phhp // in site/ready.php $wire->addHookAfter("ProcessPageEdit::buildForm", function ($event) { $form = $event->return; $page = $event->object->getPage(); if ($page->template != 'home') return; $existingField = $form->get('title'); $out = "Show 5 random pages:"; $pages = $this->wire->pages->find("limit=5, template=basic-page, sort=random"); foreach ($pages as $p) { $out .= "<div><a href={$p->editUrl}>{$p->title}</a></div>"; } $newField = [ 'type' => 'markup', 'label' => 'foo', 'icon' => 'check', 'value' => $out, ]; $form->insertAfter($newField, $existingField); });

I've just tested this: $home->of(false); $home->rockfrontend_favicon->add(__DIR__ . "/Test$$$.png"); $home->save(); bd($home->rockfrontend_favicon->uploadName()); Which resulted in this: So that confirms that uploadName() does not work for API added files.

I've added your example to the mentioned issue: https://github.com/processwire/processwire-requests/issues/56#issuecomment-1704363956

How did you upload the file via api? Can you give a quick example to reproduce the issue? If you do that and post it to this issue and mention Ryan I guess chances are high that he will fix this quickly. At least I suggested the uploadName feature on Feb 16 and he implemented it on Feb 17 ? Maybe he just didn't think of API uploads.

New video about DDEV is out ?

We are live and have a very special guest in the video ???

Hi @ryangorley and welcome to ProcessWire and the forum. Thx for your introduction, this sounds impressive and it sounds like you can have a lot of fun with PW and maybe even help us to make PW more popular one day as PW really lacks good marketing in my opinion, but that's another story ? Back to your questions and back to the mentioned modules RockMigrations and RockFrontend, which I created. This is definitely a topic for me and I've talked to many other PW devs and it's a topic for many. I don't know what to do about that, but it's a fact that PW is very unpopular and infamous and it's also a problem for many that it's basically developed by one single guy somewhere in the world and nobody really knows what happens if something happens to Ryan. Also I often hear from clients that with wordpress they just use google or youtube and instantly find a solution for their problems. If that is good or bad is another story (I'm talking about the plugin ecosystem and the idea that anybody can build a website without any knowledge). But in my experience this is a very common opinion or perception among clients when they think about websites. "WordPress is so easy to use" is another one. On one hand I totally disagree, because the PW backend is usually so much cleaner than WordPress and my clients usually can manage their websites on their own instantly without any education, but on the other hand every website that we create with PW is an individually developed piece of software and works like the developer thought it should work. There are almost no restrictions and no standards, which most of us here love because we can develop everything the way we want and we think it's best, but on the other hand everybody knows how hard it can be to take over a PW website that someone else developed... Maybe it's a little like Windows vs. Linux - you can customise Linux a lot more, you have a lot more options, you have a lot more security, maybe a lot more power and possibilities. But it's more work. Windows is easier to understand. It has a solution for everything that you just install (like WP with its Plugins). Is it hard to convince clients to use Linux instead of Windows? I guess nobody here knows that better than you ? RockMigrations TracyDebugger RockFrontend RockMigrations is #1 because it installs #2 and #3 for me ? Actually the very first thing I install is RockShell, but that might be very opinionated and advanced. RockMigrations is also advanced whereas Tracy and RockFrontend are a no-brainer in my opinion. TracyDebugger A must-have for me in every project. It made me understand PW and PHP a whole lot better. It makes me a lot faster in my everyday work. It's an invaluable tool and I can't thank Adrian enough for developing it and sharing it with us. Pssst: https://github.com/sponsors/adrianbj The beauty of PW is that you don't need all this if you don't want to! Just use direct output for your first project and just put <?= $page->something ?> in your template files and enjoy the magic. Once you are familiar with the basics and you found out about the limitations of direct output have a look at the delayed output approach. I've been using markup regions for a while, but I don't like them any more. I think they are confusing and I think they should be removed from the default profile as they are adding another layer of complexity that should not be there at the very first impression that someone gets when discovering PW. Usually PW does a really good job in hiding complexity. It is really easy to use from the very beginning (both for the developer and the clients) but it provides all the power once you get more familiar and your projects get more complex. Markup regions violate this concept and your statement seems to support that impression. RockFrontend Whatever output approach you choose RockFrontend can make your development life a lot easier. It does not dictate you anything and there is not really anything you need to learn unless you want to. You can use RockFrontend solely for it's invaluable live reload feature. Just enable it in your config and you get instant reloads whenever you change a file. This can even be combined with TracyDebugger: I'm often using /site/ready.php to quickly test something and I'm using bd($foo) to dump the result to the tracy debug bar. Whenever I save the file I instantly get the result in my tracy bar without moving my hands away from the keyboard. Productivity ? If you want, you can then discover all the other great options that RockFrontend provides. LATTE/TWIG for example which is really just "echo $rockfrontend->render(your/file.latte);" or helpers for asset handling (you get automatic cache busting timestamps for example). I've created a video about all that one year ago: But again: If you only want to use the live reload feature - only use the live reload feature and nothing else ? RockMigrations This is a gamechanger. For me and in the meantime for several others. But it is totally worthless for others. It's an advanced module, but this does not mean that it is hard to use. Quite the contrary is true. Once you get the concepts it is really easy to use and it makes you a lot more productive and a lot more professional. It's like driving a car vs. going by foot. Learning all the rules and signs is not that easy. It takes some effort. But driving the car itself is not hard. It's in fact very easy. Steer, gas, break. That's it. When using RockMigrations you simply do in code whatever you usually do via mouse clicks. $rm->createField(...); $rm->addFieldToTemplate(..., ...); That's it. If you prefer to do that manually - do it manually. Carrying a bike from A to B might be easier by foot than by car. You might even ride the bike which makes it even easier if the road goes downhill. But what if it goes uphill? A car might be easier. What if you need to carry two bikes or three? A car might be easier. What if you want to carry the bike 200km? A car might be easier and a lot faster. So if you want to create reusable components (like modules) RockMigrations can be invaluable for you. If you want to develop projects in a team of multiple developers RM can be invaluable for you. If you want to deploy your project to several places (like DEV/STAGING/PRODUCTION) RM can be invaluable for you. Video time again ? Have fun with ProcessWire! PS: As @elabx mentioned DDEV is a great tool as well! I've done a talk about it lately and the video about it will be on my channel next week, so if that's interesting for anybody just subscribe to my channel or to the Rock-Monthly newsletter: https://www.baumrock.com/rock-monthly/

Very cool to see a new AdminStyle! ? Also the font downloader looks great!! Need to take a look how you did that...

Thx @Jan Romero and both images have 25,7kB which is exactly what I tried to show ?

Hey @howdytom I might be wrong, but I think that you misunderstand the concept of DPI on images on the web. This is a good blog post to read: https://daraskolnick.com/image-dpi-web/ So as far as I understand DPI should really not matter at all on the web. All that matters are the pixel dimensions of the image. More pixels --> bigger file size. Less pixels --> smaller file size. I think that this statements are wrong. I tried to prove that using affinity photo but it doesn't even offer a DPI setting for exporting JPG images. You only get a DPI setting if you export a PDF, which makes sense, because there the DPI define the size of the image when printed and there it makes a huge difference if you print 1000 pixels ad 72dpi or 300dpi ?

@heldercervantes shared a very cool project lately that has a neat text-reveal animation. I was wondering if it could make sense to add these effects to RockFrontend. Now I have two questions: Do you think it makes sense to add these to RockFrontend? As @Stefanowitsch was asking how it is done and is also using RockFrontend we'd at least be 3 users ? What about the technical part? What would be the best way of adding such scripts to RockFrontend? The problem that I see here is that adding everything to a global RockFrontend.js file will bloat that file over time. On the other hand having a single .js file for very small features will maybe result in many many JS files loaded in the document's <head> Or would you just use NPM or something to load all needed scripts? Or would it maybe be possible to load js snippets on demand via JS itself? What about the pro's and con's of every approach? I'm not so much into frontend development and I'm mostly using UIkit so I just include one file and have (almost) everything that I need. So maybe that's totally basic questions, or maybe it's something that can't be done "right", I don't know? Thx for your help in advance ?

Hey @gornycreative thx for your question. Sounds like a bug, but I just tried on my website and it works as expected. It sets the page name and doesn't change the published state.

Interesting idea! I've just found https://github.com/meyfa/php-svg which looks also like a good option?!

I don't understand what you are saying here. And it sounds totally contrary to what you say afterwards. RockFrontend's "addIf()" for adding single scripts depending on conditions is one thing, but replacing the whole markup is something totally different. If you are trying to do the latter you have two options. One is what you describe and make ProcessWire NOT use the _main.php file. Another option would be to be more explicit in _main.php and put something like this on top of the file: <?php if($page->template == 'foo') return $rockfrontend->render('my/custom/markupfile.[php|latte]'); ... // content of _main.php here that will be loaded for all templates except 'foo' Another concept that RockFrontend provides is the renderLayout() method. The concept is to put this in _main.php: <html> <head>...</head> <body> <?= $rockfrontend->renderLayout() ?> </body> </html> Which will tell RockFrontend to load /site/templates/layouts/default.php by default and load /site/templates/layouts/foo.php for all pages with template "foo". So you have lots of options ?

Thx. Yeah sounds good. Regarding the text I was wondering if it is a good idea to have that as text rather than converted to paths. Usually I convert it to paths for maximum compatibility, but that would make things more complicated I guess. But I didn't do any research here, maybe there are some linux tools update, seems I could do that with inkscape: https://stackoverflow.com/questions/15203650/programmatically-convert-svg-shapes-to-paths-lineto-moveto Or maybe I can include the font file in my svg?? https://stackoverflow.com/questions/71060147/why-is-my-svg-file-not-using-my-font-file Any advice would be welcome ? Edit: transfonter is an interesting tool! https://transfonter.org/ --> ubuntu bold with letters A-Z and a-z results in an 13kb css file, wich sounds ok compared to the alternative of installing inkscape on my server and converting text to curves on save...

I'm working on my new website that will list all my modules with docs etc.; I also want to have a logo for every module, but I don't want to have to manually create it. It's basically always the name of the logo plus an icon on top of a green hexagon: https://raw.githubusercontent.com/baumrock/RockFrontend/main/docs/logo.svg Are there any SVG experts that know how I could create those SVGs dynamically? I'd like to really create an SVG file, not only the SVG markup or a fake image with some CSS layering magic. I'd like to have an SVG created on page save so (after entering the module name and uploading the icon) that I can then instantly use for the docs on Github as well. Any ideas are welcome, but obviously if that is too much work it would also be an option to just create those images manually... It's just more fun if it's automated ? Thx in advance ?

I'd love to help, but I don't think I understand the question. This would be very easy: <?php foreach($pagearray as $page) { echo "<div>Parent: ".$page->parent->title."</div>"; echo "<div>Grand-Parent: ".$page->parent->parent->title."</div>"; } But I think that was not your question, was it? I guess your code-block with all the venues has some meaning as well, but I can't imagine what exactly you are asking for. And I also don't understand what exactly you mean by things becoming "unwieldy" at some point? If you are asking for some kind of search engine that's a whole other topic and can quickly become a lot more complex depending on what you need or want, but then again you'd have to be a lot more specific with your questions (at least for me to understand, maybe it's clear for others already). In general looping through pages and requesting data from parent or grandparent pages via API means that you load pages into memory. That can be inefficient if you are dealing with lots of pages. That's why I have built RockFinder and later we got findRaw() in the core. Both can load lots of data with an efficient and fast SQL query rather than loading everything from PHP. That's especially handy if you work with tabular data like data grids or such where pagination and sorting is done on the client side. For search results you could also add pagination and limit the number of results to 20 for example, then it shouldn't really matter if you load data via SQL directly or you loop some pages via PHP.

Hey @Stefanowitsch thx for the question. I tried, but it's not so easy. The feature has been developed for RockCommerce where I ship a fully working checkout that is both easy to integrate and to customise. All files are in /site/modules/RockCommerce/frontend/... and can be overwritten by placing the same file in /site/templates/RockCommerce I don't think that this will be very helpful to anybody else, so I thought it's better not to bloat the docs with that feature at the moment. But I've added docs for the static rendering feature, which can be very helpful for many projects I think: Static Rendering Static Rendering is a convenient feature offered by RockFrontend that simplifies the process of developing new websites or features. It provides an alternative approach to generating markup by allowing developers to write static markup for specific pages or components, rather than utilizing multiple includes and delving into the intricacies of the entire project's architecture. How it Works If your project is already using RockFrontend's renderLayout() method to generate page layouts, integrating the Static Rendering feature is straightforward. All you need to do is create static markup files and place them within the designated folder: /site/templates/static. When a user requests a particular page, RockFrontend's Static Rendering functionality kicks in. It examines the requested page's URL and checks whether there is a corresponding static file in the /site/templates/static directory that matches the URL's structure. For example: If a user requests your.site/foo/bar, RockFrontend will search for a static file located at /site/templates/static/foo/bar.[php|latte]. Benefits Static Rendering offers several benefits for developers, including: Simplified Development: Writing static markup can be more straightforward than dealing with complex includes and understanding the project's full architecture. Quick Prototyping: Static Rendering enables developers to quickly prototype ideas without the need to set up dynamic functionality. Unique Custom Layouts: With Static Rendering, you can craft highly distinctive layouts for individual pages, allowing you to create designs that stand out from the rest of the website and cater to specific visual and functional requirements. Isolation: Developers can work on specific pages or components in isolation without affecting the rest of the application. Implementation Steps Create Static Files: Write the static markup for the desired pages or components and save them with filenames that match the URL structure. Place these files in the /site/templates/static directory. Access Static Rendered Pages: Once the static files are in place, RockFrontend will automatically use them for rendering when a user accesses the corresponding URLs.

Thx guys that helps a lot and I'll try to check your suggestions when I experience the issue for the next time!

Thx for the input @netcarver I don't think that it can have anything to do with anything on the backend. PW itself is fast, I'm just experiencing a very laggy console on the frontend. Sometimes even the mac os spinner pops up for some seconds. Do you think that can have anything to do with sessions or cookies? I'm thinking maybe the SSE stream of RockFrontend/RockMigrations livereload could interfere somehow? Just throwing in an idea as well ?

Not sure if I'll post every issue here, but at least here's the first one ? --- Hey there, RockStar developers! ? What's new in the Rock Universe? ? baumrock/AdminStyleRock v1.3.0 Make your ProcessWire backend truly yours with the latest AdminStyleRock update! Version 1.3.0 brings a super cool feature that allows you to effortlessly set a custom logo in the ProcessWire backend. Your admin experience just got a whole lot snazzier! ? ? baumrock/RockFrontend v3.3.0 Get ready for greatness with RockFrontend v3.3.0! We've introduced exciting new features, including static site rendering and a nifty view-folder feature. The top bar's hidden style has been polished for that sleek look. While we're working on documenting these gems, be sure to explore and experiment with these additions! ? ? baumrock/RockShell v2.1.0 Our new db:download command streamlines database management even more. And here's a treat: an alias for your laptop lets you simply call "rockshell db:pull staging." Say goodbye to the lengthy commands and hello to efficiency! ?️ ?️ baumrock/RockMigrations v3.29.0 Prepare to be wowed by RockMigrations v3.29.0! This version brings a fresh approach to shipping your modules with custom page classes. Plus, our new path helper methods ensure your paths are on point, with normalized separators and no more pesky multiple slashes. Another really helpful feature was added to RockMigrations this month, but then removed because it's now part of TracyDebugger itself! Say hello to the "Redirect Info" section in the "Request Info" panel! Have you ever been redirected by something and didn't know why? That belongs to the past as you can now clearly see that the redirect was triggered by line 3 in /site/templates/home.php  ? Sneak Peek: Exciting Commercial Modules We've got some fantastic updates brewing for our commercial modules, slated for release soon. Brace yourselves for RockCommerce, the power behind the shop on baumrock.com, where you'll find our incredible modules up for grabs. And speaking of modules, RockPdf has been making monumental strides. It's now responsible for crafting the invoices that accompany every order. ?️ ? Stay Connected: As we rock and roll into the future of development, there's plenty more where this came from. Stay tuned for more exciting updates, innovative features, and game-changing modules that will take your projects to new heights. Thank you for being part of our developer community. Your passion and feedback keep us strumming along. Until next month, keep coding and keep rocking on! ?? Keep rocking, Bernhard

I've often heard people say "It's hard to keep track" with all the updates to my modules. That's why I work on the DEV branch now in all of my modules for one month and then merge the changes into MAIN and create a new release that lists all new features and bug fixes. If you are interested you can sign up here: https://www.baumrock.com/rock-monthly/ ???

Just kidding ? Maybe it's one of my modules if @gornycreative is also using them and also seeing the issue?! Maybe we can track it down further. Can you check if it only appears with RockFrontend or RockMigrations for example? I always have both installed, so I can't test ? Good to hear that I'm not the only one seeing this. Maybe others can also report their observations and we can put all pieces together and find something. PS: I'm also on Chrome.