bernhard

Hey @nurkka thx for your questions!

5 minutes ago, nurkka said:

I set up a new website with all new versions of RockSuite today,

What do you mean exactly? Which modules did you install?

5 minutes ago, nurkka said:

and my added scripts and styles are not compiled into one JS or one CSS file.

This is expected. RockFrontend will only compile all .less files to one.css file. All other files will stay single files. This is because on some pages we might need some scripts, on others not. If all were compiled to one single file we'd have different files on different pages or we'd keep recreating this file over and over again when viewing different pages.

7 minutes ago, nurkka said:

Is it possible to minify and concatenate scripts and styles to compile them into one single script file and one single styles file?

At the moment no, for the mentioned reason. I thought about adding such a feature, but I think it would cause trouble.

8 minutes ago, nurkka said:

Additionally, I would want to prevent RockPageBuilder.min.css and RockFrontend.min.js from being loaded in the Frontend when debug mode is off and the site is not accessed by a superuser or frontend editor user.
Is that possible?

RF/RPB try to be as unopinionated about the frontend as possible, but some things need to be there to make it work. Can you please show me the content of these files?

I've mentioned several times that one reason why I love latte is that LATTE == PHP (almost)

This tool shows what I mean: https://php2latte.nette.org/

@FireWire

Hey @FireWire thank you for the composer file, that helped!

10 hours ago, FireWire said:

So it's in addition to the Composer file in RockFrontend since that won't register as a namespace available globally when it's located in the RockFrontend subdirectory

Sorry to say that, but this is nonsense 😉 

I didn't know for certain, but from my understanding if I do "composer require latte/latte" it should not matter WHERE I do that as long as I use the correct path in my require_once /path/to/autoload.php

So I tried doing "require_once /path/to/rockfrontend/autoload.php" above the CustomLatteExtension class and that fixed my error. The reason is simple: In ready.php the latte autoloader was not available, because I have added the "require_once /path/to/composer/autoload.php" in the "loadLatte" method of RockFrontend, since I thought it would be more efficient to only load it if needed.

I think that was wrong and I moved it into init(), because that's the whole purpose of the autoloader... to load things only if necessary, right?!

So with the latest version on the DEV branch you can add your extension without installing anything in your root folder and without adding any require_once anywhere.

21 hours ago, bernhard said:

I have an idea, but I tried adding your example to /site/ready.php and I get this:

I experimented with this:

<?php

namespace ProcessWire;

use Latte\Extension;

final class CustomLatteExtension extends Extension
{
  /**
   * Define functions available in all Latte files
   * These can be anything ProcessWire related or not, any functions defined here will be available everywhere
   */
  public function getFunctions(): array
  {
    $functions = [];
    foreach (wire('all')->getArray() as $key => $value) {
      if (!is_object($value)) continue;
      $functions[$key] = fn() => $value;
    }
    return $functions;
  }
}

But that is not a reliable solution. I'll ask for help in the nette forum. I think the only reliable solution would be to add the ProcessWire namespace to all compiled latte files. That sounds like side effects though. But we'll see...

This is what RockFrontend has in its composer.json:

  "require": {
    "latte/latte": "^3",
    "sabberworm/php-css-parser": "^8.4",
    "matthiasmullie/minify": "^1.3",
    "wa72/htmlpagedom": "^3.0",
    "baumrock/humandates": "^1.0"
  },

How does your composer.json look like?

I've recently hit 10.000 views on my youtube channel (over all videos since the beginning 2+ years ago) 🥳

I'm counting 218 subscribers and all have watched 800 hours of (almost only) ProcessWire content.

The best performing videos so far are:

Recent videos have been by far less popular. I don't know why. Maybe it's the thumbnail. Maybe the video length (the RockFrontend video is over 40min long!). Maybe it's the algorithm. Who knows.

But Ive learnt a lot and recently I found a way to be more efficient with creating those videos - unfortunately I didn't get any feedback in that regard, but feedback is rare on my channel in general. Maybe that's part of the youtube game 🙂 

So I'm asking here:

What is your opinion about these videos?

Are the videos helpful? Could anything be improved (easily 😅 )? What would you like to see as a next video?

• RockMigrations Deployment
• RockMigrations in general
• More about RockFrontend
• More about the commercial modules
• Less about the commercial modules
• Anything else?

Thanks for "watching" and have a great weekend 🙂 

In ProcessWire as always you have the freedom to choose from a variety of options. What fits best for you and the editors depends on a lot of factors, but I'd say your options are (from easy, but with default style and options to hard with full freedom):

• Stick with PW page tree, organise your pages well and properly define access of your users so they see only what they need to see. That's probably the easiest solution, but you get the default PW backend which has pros and cons.
• Use a module to adjust the backend to your needs. Possible modules are AdminRestrictBranch or the dashboard module. Or any other module that helps you to customise the backend.
• Create custom admin pages. This is still very easy and you stay in the "safe" PW backend, which means you don't have to take care of everything on your own and you can build on top of proven and battle-tested concepts and code.
• Create a custom backend. The ProcessWire backend is on its own just built around the PW api, so you can build something similar on your own. This is by far the option with most freedom but also the hardest option, as you have to take care of almost anything (access control, rendering, navigation, etc...)

Somewhere in-between those options might be to enhance your frontend with some shortcuts, like buttons to "add new blogpost" or to "manage items" or whatever. These buttons could directly link to backend pages, so it might be easier for clients to find what they need, because what many often forget is that even though the PW backend is super clean and easy to use, there is a barrier or gap between "frontend" and "backend" that for clients is sometimes harder to grasp than one might think!

RockFrontend, for example, comes with ALFRED, which adds hover info with an edit icon:

And when clicked it opens the dedicated page from the backend directly in a modal in the frontend:

There are other modules with similar solutions as well. You have the freedom to choose 😉 

11 hours ago, FireWire said:

This is a pretty smart solution! I didn't think about that. I'm still wrapping my head around the Latte === PHP situation. My brain hasn't connected the two yet. Slowly but surely...

Thx, but I don't think it's very smart 😄 It's really just PHP, that's one of the main reasons why I like latte so much. They don't reinvent PHP or invent another syntax, they just use PHP and add some helpers here and there.

It's really easy to understand, for example create the file php-demo.latte:

{file_put_contents('php-demo.txt', 'latte-is-cool')}

This will do two things:

• It will create the file php-demo.txt in the folder of the .latte file
• It will output "13", which is the strlen of "latte-is-cool"

You can think of { ... } being similar to <?= ... ?>. That's why tracy will instantly work inside latte via {bd(...)} as bd() is a globally available function without any namespace and it does not return/output anything.

To prevent our previous example from outputting anything you can simply add "do":

{do file_put_contents('php-demo.txt', 'latte-is-cool')}

Also when using {var $foo = 'whatever'} there is no output.

Now consider the following file "php-demo.latte":

{wire()->page->id}

This will cause the following error:

You can click on "PHP" and then you see which file it actually renders and why wire() is not found:

Once you click on that file link, it will open up in your IDE:

So you can see that this is the compiled PHP file that latte uses to render your .latte file. And your IDE shows, that wire() is not available!

So using our IDE we can fix the issue:

Which will add this to the PHP file:

Now since we can't add the use statement to our latte file like this:

{use function ProcessWire\wire}
{wire()->page->id}

We just use the inline syntax for namespaced functions:

{ProcessWire\wire()->page->id}

And that's all you need to understand 🙂 

But I'll probably add the functions api without namespaces to all .latte files once you help me get the mentioned issue sorted 😉 

Hey @FireWire thank you very much for taking the time to explain everything. That's great and I understand now! I have an idea, but I tried adding your example to /site/ready.php and I get this:

This is my ready.php:

<?php

namespace ProcessWire;

if (!defined("PROCESSWIRE")) die();

/** @var ProcessWire $wire */

$rockforms->setErrors('de');



use Latte\Extension;

final class CustomLatteExtension extends Extension
{
  /**
   * Define functions available in all Latte files
   * These can be anything ProcessWire related or not, any functions defined here will be available everywhere
   */
  public function getFunctions(): array
  {
    return [
      'wire' => fn(?string $property = null) => wire($property),
    ];
  }

  public function getFilters(): array
  {
    return [
      'bit' => fn(mixed $value) => new Html(filter_var($value, FILTER_VALIDATE_BOOLEAN) ? 1 : 0),
      'bitInverse' => fn(mixed $value) => new Html(filter_var($value, FILTER_VALIDATE_BOOLEAN) ? 0 : 1),
    ];
  }
}

$wire->addHookAfter(
  "RockFrontend::loadLatte",
  fn(HookEvent $e) => $e->return->addExtension(new CustomLatteExtension),
);

Do I have to require_once something? I have never added a custom extension yet.

Looks great. Wouldn't that be worth a PR?

Hey @zoeck thx yeah that test2.l was helpful and I've fixed that in v3.21.2

Some of you may be interested to know that yesterday I released RockCalendar, which also has recurring events and will be actively developed and maintained for the foreseeable future:

Hey @zoeck thx. I just tried and it seems to work. What exactly do you mean by "didn't work"? Steps to reproduce please.

RockMigrations v5.3.0

• Added an automatic Modules::refresh() before executing $rm->installModule()
• Added GET_PHP_COMMAND for deployments as requested by @snck
• Added docs for the great filesOnDemand feature

RockFrontend v3.21.1

• Several improvements in the docs
• Added support for nested AJAX Endpoints (see video below)

I've just released RockCalendar with a hopefully helpful intro video.

I want to thank @monollonom and @BrendonKoz for all the input you gave here. If you want a free single site license for testing (and eventually reporting bugs 😅 ) please write me a PM.

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!

2 hours ago, monollonom said:

What would be nice though is having a thread (this one?) so people can share what they put in place (PW-based that is) to help them managing this aspect of their work. Not going as far as sharing a whole site-invoice profile, but something along the lines of the associated blog post 🙂

That's a great idea, but I think it would be better placed in a dedicated thread 🙂

2 hours ago, monollonom said:

I love it that you called it “RockCare”, to rockfinity and beyond... 🙃

Haha, well... it had to have some name 😄 

2 hours ago, monollonom said:

In all seriousness, IMHO I don’t think this is something worth developing for others to buy (nor as a free module). Everyone has their own set of requirements (and their own way of doing) and this would make it a very hard time on you to figure out a “one-size-fits-all” solution. I would advise to save yourself this burden, knowing you’re already going on big endeavours with other modules (e.g. RockCommerce).

Yeah that would be the concerns that I had... Let's wait a little for more feedback 🙂 

2 hours ago, monollonom said:

In my particular case though, this is something I wanted to tackle for a while now, also with ProcessWire. But I know for sure that I would want to do it all by myself, as a way to experiment (and have fun like you said) but also to make sure it’s perfectly tailored for my usage.

Totally understandable. I've also thought about creating something like this totally open source, but this is not possible for several reasons. One is that I'd have to reinvent several of my modules (RockPdf, RockGrid) and another one is that it has to generate income. I know some don't like this, but nobody can live from love and likes.

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 ^^

12 minutes ago, uliverse said:

@tailwind base;
@tailwind components;
@tailwind utilities;

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:

Quote

Thank you for providing the context. Let's explore some potential issues that could prevent the `exec('npm run build');` command from working for the user in the forum. Here are some possible reasons and suggestions for troubleshooting:

```php:subfolder/site/livereload.php
// ... existing code ...

// run npm build to compile css from tailwind
// exec('npm run build');

// Improved version with error handling and logging
$output = [];
$return_var = 0;
exec('npm run build 2>&1', $output, $return_var);

if ($return_var !== 0) {
    // Log the error
    wire()->log->error('npm build failed: ' . implode("\n", $output));
    // Optionally, you can also display the error to the user
    // echo "Error running npm build. Check the ProcessWire logs for details.";
}

// ... existing code ...
```

Here are some potential issues and explanations for the changes:

1. **Path to npm**: The `exec()` function might not be able to find the `npm` executable. This could happen if `npm` is not in the system's PATH or if PHP is running under a different user context.

   Suggestion: Use the full path to npm, e.g., `exec('/usr/local/bin/npm run build 2>&1', $output, $return_var);`

2. **Permissions**: The PHP process might not have the necessary permissions to execute npm or access the required directories.

   Suggestion: Check the permissions of the directories and files involved in the build process.

3. **Working Directory**: The `exec()` function might be running in an unexpected working directory.

   Suggestion: Change to the correct directory before running the command:
   ```php
   chdir('/path/to/project/root');
   exec('npm run build 2>&1', $output, $return_var);
   ```

4. **Error Output**: The original code doesn't capture error output, making it difficult to diagnose issues.

   Suggestion: Capture both standard output and error output using `2>&1` as shown in the updated code.

5. **Error Handling**: The original code doesn't check if the command was successful.

   Suggestion: Check the return value and log any errors, as demonstrated in the updated code.

6. **Environment Variables**: The PHP environment might be missing necessary environment variables.

   Suggestion: Set required environment variables before running the command:
   ```php
   putenv("PATH=/usr/local/bin:/usr/bin:/bin");
   exec('npm run build 2>&1', $output, $return_var);
   ```

7. **Node.js and npm Installation**: Ensure that Node.js and npm are properly installed on the server.

8. **Project Dependencies**: Make sure all necessary dependencies are installed (`package.json` and `node_modules`).

To help the user troubleshoot, you could suggest they implement these changes and check the ProcessWire logs for any error messages. Additionally, they should verify their Node.js and npm installation, as well as the presence and correctness of their project's `package.json` file.

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.

40 minutes ago, uliverse said:

I have changed the livereload.php, but the result is the same.
In Tracy I get

array (0)

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

2 hours ago, uliverse said:

The fronend is reloading after a file change, but the tailwind.css is not being recreated. If I manually execute "npm run build" it works. Is it possible, that the exec command is run in the site subfolder and therefore not working correctly?

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