bernhard

Hey ProcessWire community! I'm excited to introduce RockCalendar, a new calendar module that brings powerful event management capabilities to your ProcessWire sites. Key features include: Full calendar view in the ProcessWire admin Easy event creation and management Drag-and-drop event scheduling Recurring events (SSE powered, needs RockGrid) Seamless integration with ProcessWire pages and fields I've created a detailed video walkthrough showcasing RockCalendar's features and installation process: Check it out and let me know what you think! I'm here to answer any questions you might have about RockCalendar. Download & Docs: https://www.baumrock.com/en/processwire/modules/rockcalendar/ Happy coding!

That's a great idea, but I think it would be better placed in a dedicated thread 🙂 Haha, well... it had to have some name 😄 Yeah that would be the concerns that I had... Let's wait a little for more feedback 🙂 Totally understandable. I've also thought about creating something like this totally open source, but this is not possible for several reasons. Thx for your input!

The --watch command is fine and as I said most likely what 99.9% of tailwind users do. I don't like it, because it does not recompile the css in the way "npm run build" does. It has some caching, so if you add classes during dev and then remove them, they stay in your css, which I don't like, because I want to immediately be able to "git commit" my changes without having to run "npm run build" before (and likely forget that). But if watch works for your setup its totally fine to use. Again. I can't recommend DDEV enough and in the time of your troubleshooting you'd likely had it installed and working ^^ I don't know why you added components here, but if you need them go ahead. The problem with adding anything other than what I do in the site profile is that these things often interfere with UIkit or whatever framework you use. If you don't use one and use only tailwind then of course you'll likely want to add components as well. For me all the necessary tailwind magic comes from the utility classes. Everything else I'm using UIkit for.

This is a request for honest feedback. --- first, some background --- It's the first of October and I'm doing my bookkeeping. This has been a pain for me for a long time, but nowadays I'm - believe it or not - really enjoying it. That's because I've developed a system over time that makes it fast and efficient for me to charge all my customers that have a maintenance contract. It's basically just a few clicks and some days later I have the money on my bank account. I try to provide as much value as I can for that money, which involves managing their web hosting (on a dedicated VPS), doing backups, monitoring their services for uptime, etc. I'm not getting rich from that money nor is it enough to live from (at least not in Austria 😄 ), but it is money that I get where computers do the work for me even when I'm having some time off, which I think is great. I try to make it visible for my clients that I provide a lot of value every month by a monthly performance report which looks like this: This is very basic at the moment, but I think it looks quite nice and it does its job. I also have another system that creates invoices for the work that I do (eg monthly contract, custom web development, bug fixing, new features, etc) and another system where I manage my time tracking. --- now here is my question --- All of that is based on ProcessWire and quite outdated. I want to rebuild this at some point, but I'm only having a handful of clients, so it's kind of overkill to develop something like this for just a few clients/euros. But I think it's very nice and I enjoy developing these things, so I'd really want to do it. Now I was wondering... Could other ProcessWire users also need this? I guess there are many self employed users in the community and maybe some are struggling with the same challenges or are working on the same goals? Or are you in a similar situation and have solved it differently. Maybe with some software that already works great for you. I know there is a lot of commercial and even open source software out there, but I love ProcessWire for its flexibility and customisation opportunities and perfectly tailored workflows - for me - make the difference between something being tedious or fun. 🚀 What do you think? If there is no interest I'm likely going to build it for my own 😄 If there is interest we can think of how to make it work and be beneficial for everybody. Now back to my bookkeeping ... 😅

@palacios000 Please also have a look at the discussion here: https://processwire.com/talk/topic/30449-questions-and-syntax-latte-template-engine-by-nette/?do=findComment&comment=244743

Hey @uliverse I appreciate your input! It shows me that there is interest and it shows me that something is not working. If nobody says anything I don't even know if anything is using the modules at all. I tried this and you can also try it: And this is what my AI says, wich sounds quite reasonable: So you need to make sure that exec is working fine. You can do so, for example, by executing something like "exec('touch /path/to/project/foo.txt');" if the file is created exec works. If not, exec doesn't work. Then check if NPM is available to your exec() command. And then we'll see how we proceed.

I guess that shows the problem. You can try if shell_exec works. Other than that I fear I cant help with this one as it's totally specific to your environment. You can try to ask an AI to help. And I can't recommend DDEV enough (https://ddev.readthedocs.io/en/stable/) Maybe anyone else has ideas? PS: Of course you can use any other npm based workflow and add another script like "npm run watch" that you start during development. I don't like this approach, but that's how 99% work I guess, so maybe you prefer such a setup too.

Hey @uliverse thx for that screenshots. I was able to reproduce the issue when installing PW in a subfolder. I never do that, so it causes trouble more often that I'd like, because I don't realise if anything doesn't work. Your issue is fixed now in the latest version 3.21.1 This works for me in my subfolder installation, so my guess is that exec() is not available in your setup? Could you try this /site/livereload.php ? <?php namespace ProcessWire; /** * This file will be loaded by RockFrontend whenever livereload detects * a change in the source files. By default it will run npm run build to compile * the css from tailwind, but you can add other commands to run other scripts * like running tests or linters as you need. * * If you are not using Tailwind or you don't need to compile anything, you * can remove this file. */ if (!defined('PROCESSWIRE')) die(); // early exit if not in debug mode or livereload is not enabled if (!wire()->config->debug) return; if (!wire()->config->livereload) return; // run npm build to compile css from tailwind // check if exec is available and allowed if (function_exists('exec') && !in_array('exec', explode(',', ini_get('disable_functions')))) { exec('npm run build'); } else { rockfrontend()->getLiveReload()->log('exec() not available'); } Or in Tracy try this: What does it show?

😎

Hey @uliverse I don't see the topbar error so I'm wondering if you might have an outdated cache or something? Can you try do do a completely new installation? Can you provide exact steps what you did? Regarding tailwind not recompiling... how does your /site/livereload.php look like? Does livereload work? PS: Here are the docs for livereload: https://github.com/baumrock/RockFrontend/tree/dev/docs/livereload

Great to hear that 🙂 Maybe, but I don't think so. Why would one want to do that?

That helps. Ok I tried the following: // _main.latte {include 'test.latte'} // test.latte {bd($wire)} // result // $wire is a ProcessWire object Next using {embed} // _main.latte {embed 'test.latte'}{/embed} // test.latte {bd($wire)} // result // $wire is NULL This is exactly the behaviour that the docs state: That's what I wished you provided, so I can easily try things out and can follow. But seems we are there now. Yes. Always remember LATTE = PHP, so you can do this, for example: {extract(\ProcessWire\wire('all')->getArray())} {bd($wire)} {bd($modules)} As you can see when adding the namespace to any function api it will also work! Again, it's just PHP. Or you could also do this: // _main.latte {embed 'test.latte', api: get_defined_vars()}{/embed} I'm sorry, but I'm not going to try to guess what you mean. Actually I tried, but unless you provide a simple step by step example like I did above I can't help, as I don't know/understand what the problem is. Maybe you already mentioned it, but I can't remember everything you wrote and showed in one of the extensive examples. I know you are busy, but so am I, so it would be nice to make it easier for me to follow and help 😉

Hey @wbmnfktr thank you very much for your honest feedback! I had to think about what you said, because I had good reasons (at least I thought they where good) for using my advanced techniques. I didn't think that showing a very basic, old-school installation via unzipping the module files would be interesting at all, so I wanted to pack more into the video. Not that old-school installations are bad in any way, I just didn't think that this is interesting or helpful for anybody. Also I thought I made it clear that this is nothing anyone has to use, but I think that got lost during editing. So I think you have a very good point and I'll try to not mix different topics in one single video. These alias commands would have been more helpful in a dedicated RockShell video, I guess, where I also show how these can be setup. Thank you!

Hey @FireWire thx for the detailed response. Unfortunately it does not help me understand your problem or request. What problems? I can't help if I can't understand the problem. Personally I don't agree here. But that might be a matter of preference. If files are growing you can also just put them in a folder, so instead of /site/partials/button-primary.latte you could simply have /site/templates/buttons/primary.latte, or am I missing something? I understand that. But to be precise this is only how ProcessWire works if the functions API is enabled, which might not always be the case. Personally I'm always using wire()->modules instead of modules() in my modules, because wire() is always available and wire('modules') does break intellisense in my IDE whereas wire()->modules does work. I'd be interested to see simple examples (like 5 lines, not 50 like the one example you pasted) how you are using those function calls and what exactly causes problems if they are not available. I'm sorry, but this example is too complex for me to grasp. I agree, but I need to fully understand the situation/scope/whatever first. I'd still appreciate to get an example. I'm sorry but I don't understand. Maybe some simple code examples would help. Same as above.

And another thing to mention / take care of. Just because ProcessWire seems to be running fine that doesn't mean that you are all done. For example what if one of the installed modules had a custom .htaccess in it's module folder that has some custom rules that are necessary to protect some files from direct access? As far as I understand nginx will not be able to read these instructions and you might be open to attacks, no? I think it should at least be clearly mentioned in this thread that anybody trying to use non-apache webservers for running ProcessWire has to take care of this risk on his own and check every single module and every single update or is otherwise really highjacking one of ProcessWires main strengths: Security. For me this seems like a very high risk to take and I'd really be interested in numbers of how much faster nginx is compared to apache so that one can decide whether it's really worth the risk and additional effort.

Hey @FireWire sorry to hear that you are having troubles. It seems that you are doing some quite complex stuff. I've never experienced any of these problems - maybe because I keep things very simple! What is "better" is a very subjective thing, but there are two things I want to mention upfront: Instead of listing all API variables you can just pass the $wire variable and then access anything you need in your template from there: // if you passed the wire variable you can do this: {$wire->pages->find(...)} {$wire->modules->get(...)} {$wire->...} // if you passed "page: $page" do this {$page->wire->pages->find(...)} // or this {var $wire = $page->wire} {$wire->pages->find(...)} I guess I don't have these problems because I'm always working with custom page classes, so I most of the time add those things to the pageclass and then I can just use $page->myMethod(). That has the benefit that template files stay very simple and I have all the logic in PHP and not in Latte, which has a ton of benefits. For example you can do this for debugging: // in site/ready.php bd(wire()->pages->get(123)->myMethod()); Or you could access ->myMethod from anywhere else, like in a cronjob etc. If you have your business logic in latte then you have to refactor at some point or you are violating the DRY concept if you are lazy and just copy that part of your logic from the latte file to the cronjob. I'm not sure I can follow... I put this in whatever.latte: {block foo} <h1>Hello World</h1> {/block} {define bar} <h1>Hello World</h1> {/define} {include foo} {include bar} And I get 3 times "Hello World" as expected. {block} does immediately render while {define} waits for the final include Also I don't know why you make things "complicated". When I need a reusable portion of code like for a button, I simply put that into /site/templates/partials/my-button.latte and then I use {include ../partials/my-button.latte} in my latte file. I'm usually always either in /site/templates/sections or in /site/templates/partials. That's it. Sections are full width elements, like hero, slider, breadcrumbs, main, footer, etc. and partials are things like buttons, cards, etc. Having said that I see that there might be potential to improve the experience though. For example we might make the functions api available to all latte layout files or we might make API variables always available. But to make that happen I'd need some easy to follow real world examples and not complex code examples like your specific setup. Also I'm hesitant as I didn't experience any of these "problems" for maybe two years or so. So we have to identify the real problem first. Maybe the problem is only lack of documentation for example.

Here you go @FireWire thx for your suggestion! Please check out v1.1.1 Now that I tried the different sort settings I must say that sorting by name rather than by group feels better, so I made that the new default 🙂 See the selected icon and the one to the right - same name, different group (filled/outline)

Just added docs to https://www.baumrock.com/en/processwire/modules/rockcolorpicker/docs/ with lots of examples and added some minor improvements 🙂

Sorry, wire() is not available in a latte file, because wire() is actually \ProcessWire\wire with the namespace. In PHP files where you have "namespace ProcessWire" at the top just adding wire() will work. In latte it is a different story, because the latte file has no namespace and it will be compiled. Therefore "wire()" is not available. But all ProcessWire API variables are, so please just use $wire instead of wire(). Pro-Tip: From any API variable you can access the wire object via ->wire, so this would also work: $block->wire->... or $config->wire->... etc.; So in hooks you might see $event->wire->... and that's the reason for this. PS: $block is not an API variable but is available in RockPageBuilder blocks! And as it is also extending "wire" it will also have its methods. Edit: I've just updated the example above and realised that it was using wire('modules') syntax that I'm never using. In that case you need to use $wire->modules->... or simply use $modules->... as $modules is also an API variable and therefore directly available.

And I've just pushed extensive docs to https://www.baumrock.com/en/processwire/modules/site-rockfrontend/docs/ If you haven't tried this site profile this might be a good opportunity to do so 🙂

The page transitions are very cool. Do you have any details about how you built those?

Ok this is solved now. I totally missed the corresponding PR to the SCSS module. It's now there in the dev branch and will be merged to main begin of October. Please mark this topic [solved] thx!

RockFrontend / Latte doesn't provide this syntax as far as I know. What are you referring to? Ah sorry, now I see $map should be a map marker object. The docs there state this: <?php $map = wire('modules')->get('MarkupLeafletMap'); ?> Which you could do in latte like this: {var $map = $modules->get('MarkupLeafletMap')}

This <?php echo $map->render($page, 'YOUR MARKER FIELD'); ?> would be this {$map->render($page, 'YOUR MARKER FIELD')} Your error message means, that $map is NULL. That means $map is not available in your latte file for whatever reason. That means you are not struggling with latte syntax, you are struggling with PHP 😉 😛 You can easily debug this via TracyDebugger: {bd($map)} {bd($page)} To help you with your specific problem I'd need more info in where you are trying to use this markup...

These videos are so much work 🙈 I have tried a different software and a different technique. What do you think?