Compiled com_demo with errors (JCB 5.1.1-alpha4 / Joomla 5.3.0)

peterpeter commented

2025-05-04 17:53:07 +00:00

Steps to reproduce the issue

I've nstalled JCB 5.1.1-apha4 in a new Joomla 5.3.0 and compiled the com_demo without any changes in the configuration of JCB or com_demo.

Expected result

com_demo installs and runs without errors

Actual result

Faced a cascade of errors.

The first in the DemoInstallerScript.php: the classes Factory and Text are declared twice: banned/IIaHw1h91lXx - I've fixed that and the installation of the com_demo runs through.
-Then clicked on the com_demo dashboard, the next error was in the HtmlView.php: the attribute declaration was before the last 'use' declaration: banned/4vhBr3JjSdaR
After fixing that one, the next one was in : Factory class declared again twice in the demo model class: banned/gAwJvwDQMlHV
After fixing this, the next error was in the demo helper class: banned/OzHdX71gWw89
the next was a missing 'use' declaration of Joomlas arrayhelper class: banned/9LhXv-0pUfiS
fixed another one and then I gave up

System information (as much as possible)

OS Name & Version: Windows 10
MySql Version:
Apache Version: 2.4.58.1
PHP Version: 8.3.17 - Options according to https://git.vdm.dev/joomla/Component-Builder/wiki/PHP-Settings
Joomla Version: 5.3.0
JCB Version: 5.1.1-alpha4
Browser: Firefox

Additional comments

I guess that is just a OS/PHP/Configuration thing on my end - any hints are welcome

### Steps to reproduce the issue I've nstalled JCB 5.1.1-apha4 in a new Joomla 5.3.0 and compiled the com_demo without any changes in the configuration of JCB or com_demo. ### Expected result com_demo installs and runs without errors ### Actual result Faced a cascade of errors. - The first in the DemoInstallerScript.php: the classes Factory and Text are declared twice: banned/IIaHw1h91lXx - I've fixed that and the installation of the com_demo runs through. -Then clicked on the com_demo dashboard, the next error was in the HtmlView.php: the attribute declaration was before the last 'use' declaration: banned/4vhBr3JjSdaR - After fixing that one, the next one was in : Factory class declared again twice in the demo model class: banned/gAwJvwDQMlHV - After fixing this, the next error was in the demo helper class: banned/OzHdX71gWw89 - the next was a missing 'use' declaration of Joomlas arrayhelper class: banned/9LhXv-0pUfiS - fixed another one and then I gave up ### System information (as much as possible) - OS Name & Version: Windows 10 - MySql Version: - Apache Version: 2.4.58.1 - PHP Version: 8.3.17 - Options according to https://git.vdm.dev/joomla/Component-Builder/wiki/PHP-Settings - Joomla Version: 5.3.0 - JCB Version: 5.1.1-alpha4 - Browser: Firefox ### Additional comments I guess that is just a OS/PHP/Configuration thing on my end - any hints are welcome

pctechnikch commented

2025-05-08 16:50:03 +00:00

Member

I'm having the same problem, but only with Joomla 5.3.0. I have no problems compiling with JCB 5.1.1-apha4 und Joomla 5.2.5. The problem is in a fresh installation with Joomla 5.3.0.

peterpeter commented

2025-05-09 05:47:56 +00:00

Author

Thanks @pctechnikch for your hint.
I'm new in the JCB world and thought it were good to start with the newest versions of both, JCB and Joomla.

Regards from Basel to Herisau ;-)

Thanks @pctechnikch for your hint. I'm new in the JCB world and thought it were good to start with the newest versions of both, JCB and Joomla. Regards from Basel to Herisau ;-)

peterpeter commented

2025-05-10 06:57:02 +00:00

Author

Hm....I have the same errors with Joomla! 5.2.6 and 5.2.5 and JCB 5.1.1-alpha4

Rachel commented

2025-05-12 08:58:46 +00:00

Hello
Ich have the same problem with Joomla 5.3.0 and JCB 5.1.1-alpha4. I also tied on Laragon instet of XAMPP - the same issue.
Are there some solutions know?
Regards, Rachel

Hello Ich have the same problem with Joomla 5.3.0 and JCB 5.1.1-alpha4. I also tied on Laragon instet of XAMPP - the same issue. Are there some solutions know? Regards, Rachel

Lemuel commented

2025-05-12 16:49:58 +00:00

Member

Hi, This issue is quite difficult for us to address, as all our testing and development teams operate exclusively on Linux — primarily Ubuntu Linux. JCB Core is also running on a Linux system.

Recently, I set up a fresh Joomla 5.3.0 instance using Octojoom, and installed the latest JCB version v5.1.1-alpha4. The demo component compiled and installed smoothly, and JCB functioned without issues, even with the backward compatibility plugin disabled.

Octojoom was designed specifically for Linux operating systems. While we have also successfully run it on macOS, we have not had success on Windows.

We sincerely apologize for any inconvenience this causes. In order to assist you further, we would need much more detailed information from your side. You will also need to investigate your system setup thoroughly and try to isolate any issues on your end.

JCB is the backbone of our internal and many client systems, and we are not encountering any of these issues in our environments. Therefore, we strongly recommend spinning up a temporary Linux system and testing your setup there.

In short, we will need further debugging from your end. We’re happy to help as much as we can, but we’ll need more input from you to proceed.

Hi, This issue is quite difficult for us to address, as all our testing and development teams operate exclusively on Linux — primarily Ubuntu Linux. JCB Core is also running on a Linux system. Recently, I set up a fresh Joomla 5.3.0 instance using [Octojoom](https://git.vdm.dev/octoleo/octojoom), and installed the latest JCB version [v5.1.1-alpha4](https://git.vdm.dev/joomla/pkg-component-builder/archive/5.x.zip). The demo component compiled and installed smoothly, and JCB functioned without issues, even with the backward compatibility plugin disabled. Octojoom was designed specifically for Linux operating systems. While we have also successfully run it on macOS, we have not had success on Windows. We sincerely apologize for any inconvenience this causes. In order to assist you further, we would need much more detailed information from your side. You will also need to investigate your system setup thoroughly and try to isolate any issues on your end. JCB is the backbone of our internal and many client systems, and we are not encountering any of these issues in our environments. Therefore, we strongly recommend spinning up a temporary Linux system and testing your setup there. In short, we will need further debugging from your end. We’re happy to help as much as we can, but we’ll need more input from you to proceed.

peterpeter commented

2025-05-13 06:07:45 +00:00

Author

Hi
Since I like to stay with Windows and Wampserver and I should be able to debug the compiler process, I'll try to identify what causes this errors on Windows-Systems. Not least because JCB can benefit from this.

But as I have a lot of work at the moment I probably won't get round to it until the weekend.

@pctechnikch
As you've said that it works with J-5.2.5, are you also on Windows?

Hi Since I like to stay with Windows and Wampserver and I should be able to debug the compiler process, I'll try to identify what causes this errors on Windows-Systems. Not least because JCB can benefit from this. But as I have a lot of work at the moment I probably won't get round to it until the weekend. @pctechnikch As you've said that it works with J-5.2.5, are you also on Windows?

pctechnikch commented

2025-05-13 10:48:00 +00:00

Member

Okay, I don't quite understand why it's important to know which platform JCB works on and which it doesn't. Isn't it the case that if Joomla runs on a platform, then all available extensions will work as well? I've never encountered a case where extensions were incompatible due to the platform.

I have the problem mentioned on a WAMP. The problem isn't apparent on a Virtualmin system. But WAMP is the most widely used platform under Windows. JCB is an exception when it doesn't run correctly.

Yes, there are also people who use Windows and not Linux as their operating system. And I think that's the majority.
JCB is a milestone for me in the history of Joomla. It's one of the best things there is for programming extensions, so:
I hope JCB will run on all platforms that Joomla runs on in the future. (Sorry my English)

Okay, I don't quite understand why it's important to know which platform JCB works on and which it doesn't. Isn't it the case that if Joomla runs on a platform, then all available extensions will work as well? I've never encountered a case where extensions were incompatible due to the platform. I have the problem mentioned on a WAMP. The problem isn't apparent on a Virtualmin system. But WAMP is the most widely used platform under Windows. JCB is an exception when it doesn't run correctly. Yes, there are also people who use Windows and not Linux as their operating system. And I think that's the majority. JCB is a milestone for me in the history of Joomla. It's one of the best things there is for programming extensions, so: I hope JCB will run on all platforms that Joomla runs on in the future. (Sorry my English)

Llewellyn commented

2025-05-13 13:26:49 +00:00

Owner

Hi everyone – thanks for taking the time to test JCB 5.1.1-alpha4 and for opening detailed reports.

Current project reality

JCB’s entire build, CI, and production footprint is Linux-only (Ubuntu LTS).
That is where all automated tests run and where the core team works day-to-day.
We simply don’t have the bandwidth to spin up, maintain, and debug a parallel Windows tool-chain right now.
The duplicate-class / misplaced use statements you’re seeing are real, but they don’t appear on the Linux stack we use.

We’re not opposed to Windows support – we just need help

If Windows is important for you or your clients, you can move things forward in several ways:

How you can help	What we can do in return
Submit a pull request that adjusts the code-generator so the produced component installs cleanly on Joomla 5.3.0 / PHP 8.3 on WAMP/XAMPP.	We’ll review quickly, give feedback, and merge once tests pass.
Open a minimal failing test case (zip of the generated component + exact PHP version) so we can reproduce in CI.	We’ll add it to the test suite to keep it fixed.
Improve docs: write up a “JCB on Windows” guide that others can follow.	We’ll publish it on the wiki with full attribution.
Financial support via our Open Collective. Even a small monthly pledge lets us grow our team to focus on Windows aswell.	We’ll dedicate those funds towards Windows builds and publish progress in the changelog.

Short-term workaround

If you need to work on Windows today, consider running JCB in:

WSL 2 (Windows 10/11) – fast and case-sensitive, so the Linux paths match our repo; or
Docker with the official Ubuntu image.

Both routes avoid the class-name / autoloading edge-cases that crop up on classic WAMP stacks.

Open source thrives on shared effort.
If Windows support matters to you, we warmly invite you to contribute code, docs, or a few coffees’ worth of funding. We’ll gladly partner with anyone who steps forward.

Thank you for understanding – and for helping JCB grow!

Hi everyone – thanks for taking the time to test JCB 5.1.1-alpha4 and for opening detailed reports. ### Current project reality * **JCB’s entire build, CI, and production footprint is Linux-only** (Ubuntu LTS). That is where all automated tests run and where the core team works day-to-day. * We simply don’t have the bandwidth to spin up, maintain, and debug a parallel Windows tool-chain right now. The duplicate-class / misplaced `use` statements you’re seeing are real, but they don’t appear on the Linux stack we use. ### We’re not opposed to Windows support – we just need help If Windows is important for you or your clients, you can move things forward in several ways: | How you can help | What we can do in return | |------------------|-------------------------| | **Submit a pull request** that adjusts the code-generator so the produced component installs cleanly on Joomla 5.3.0 / PHP 8.3 on WAMP/XAMPP. | We’ll review quickly, give feedback, and merge once tests pass. | | **Open a minimal failing test case** (zip of the generated component + exact PHP version) so we can reproduce in CI. | We’ll add it to the test suite to keep it fixed. | | **Improve docs**: write up a “JCB on Windows” guide that others can follow. | We’ll publish it on the wiki with full attribution. | | **Financial support** via our Open Collective. Even a small monthly pledge lets us grow our team to focus on Windows aswell. | We’ll dedicate those funds towards Windows builds and publish progress in the changelog. | ### Short-term workaround If you need to work on Windows **today**, consider running JCB in: * **WSL 2** (Windows 10/11) – fast and case-sensitive, so the Linux paths match our repo; or * **Docker** with the official Ubuntu image. Both routes avoid the class-name / autoloading edge-cases that crop up on classic WAMP stacks. --- Open source thrives on shared effort. If Windows support matters to you, we warmly invite you to contribute code, docs, or a few coffees’ worth of funding. We’ll gladly partner with anyone who steps forward. Thank you for understanding – and for helping JCB grow!

cpaschen commented

2025-05-13 15:23:43 +00:00

Just a side comment/user-experience note here about JCB on Windows.

I used to use Windows/WAMP for JCB (for several years).
I was running into problems like this (but different) every once in a while.
Llewellyn would point out that JCB is developed on Linux (Ubuntu specifically) and encourage me (and everyone) to use that.
I resisted for a LONG time - because I just couldn't justify the time to switch operating systems.
I tried the WSL path and docker on Windows - it was hard to get working and never really worked properly.
I also tried developing on a remote Linode server, but had issues with remote debugging.
Then, with Win10's end of life looming, knowing I didn't want to go to Win11 (for security reasons), I decided now was the time to switch (which actually happened October 2024).
Of course, I didn't do the obvious (like Llewellyn suggests) and go with Ubuntu, I tried Fedora and several other distros.

After trying to get JCB to work on each, and having issues, I finally decided I would give Ubuntu (Kubuntu specifically) a try and also Octojoom.

I should have listened to Llewellyn years ago and just moved then.

Octojoom makes spinning up a new Joomla instance locally a 2-3 minute process. Just a few clicks and it's all ready to go. I can even replicate existing systems using Akeeba backup restores.
And the JCB compile time is about 1/4 the time that it took on WAMP. That time savings along was worth the migration.
And I am now no longer trying to figure out problems with JCB and the OS, but only with problems with my own code (which are enough to keep me busy :-) ).

As to your question about if Joomla runs on Windows shouldn't the extensions ... well, I've had a number of extensions over the years that caused problems on WAMP. And, although there was a time when Joomla was supported by Microsoft and there was more focus on Windows server hosting, that support ended a while ago and most development focus by extensions (from my discussions with extension developers) is focused on Linux hosts. If you are writing a very basic module or plugin, it shouldn't matter, but JCB is a LOT more than that.

Bottom line, I would personally encourage you to consider moving to Linux for your daily driver OS. There is a bit of a set-up process (esp. if you migrate an existing Windows machine), but it is SO much more stable than Windows and you get to control everything. And the 1-2 minutes you save each time you need to compile in JCB will be worth the effort.

And if you're interested in details (distro, apps, configs, etc.) to get your new Linux system working well for Joomla/JCB development, maybe open a new ticket here and I and others can share our learning experiences.

Just a side comment/user-experience note here about JCB on Windows. I used to use Windows/WAMP for JCB (for several years). I was running into problems like this (but different) every once in a while. Llewellyn would point out that JCB is developed on Linux (Ubuntu specifically) and encourage me (and everyone) to use that. I resisted for a LONG time - because I just couldn't justify the time to switch operating systems. I tried the WSL path and docker on Windows - it was hard to get working and never really worked properly. I also tried developing on a remote Linode server, but had issues with remote debugging. Then, with Win10's end of life looming, knowing I didn't want to go to Win11 (for security reasons), I decided now was the time to switch (which actually happened October 2024). Of course, I didn't do the obvious (like Llewellyn suggests) and go with Ubuntu, I tried Fedora and several other distros. After trying to get JCB to work on each, and having issues, I finally decided I would give Ubuntu (Kubuntu specifically) a try and also Octojoom. I should have listened to Llewellyn years ago and just moved then. Octojoom makes spinning up a new Joomla instance locally a 2-3 minute process. Just a few clicks and it's all ready to go. I can even replicate existing systems using Akeeba backup restores. And the JCB compile time is about 1/4 the time that it took on WAMP. That time savings along was worth the migration. And I am now no longer trying to figure out problems with JCB and the OS, but only with problems with my own code (which are enough to keep me busy :-) ). As to your question about if Joomla runs on Windows shouldn't the extensions ... well, I've had a number of extensions over the years that caused problems on WAMP. And, although there was a time when Joomla was supported by Microsoft and there was more focus on Windows server hosting, that support ended a while ago and most development focus by extensions (from my discussions with extension developers) is focused on Linux hosts. If you are writing a very basic module or plugin, it shouldn't matter, but JCB is a LOT more than that. Bottom line, I would personally encourage you to consider moving to Linux for your daily driver OS. There is a bit of a set-up process (esp. if you migrate an existing Windows machine), but it is SO much more stable than Windows and you get to control everything. And the 1-2 minutes you save each time you need to compile in JCB will be worth the effort. And if you're interested in details (distro, apps, configs, etc.) to get your new Linux system working well for Joomla/JCB development, maybe open a new ticket here and I and others can share our learning experiences.

Rachel commented

2025-05-15 10:58:37 +00:00

Hello
For me, Linux is not acceptable. I have such a lot of programs, that work well on Windows and I do not have the time and the nervs to set up everything new - with all the problems, that will appear with a new system.
If you du not offer JCB for Windows, its OK for me. I do not have the right to force or blame you. But please inform us, whether it works on Windows or not. Is it a temporary issue or is JCB just not running on Windows. So I can arrange myself und try other solutions (that are not so good like JCB - but running on Windows).
Thank you, Rachel

Hello For me, Linux is not acceptable. I have such a lot of programs, that work well on Windows and I do not have the time and the nervs to set up everything new - with all the problems, that will appear with a new system. If you du not offer JCB for Windows, its OK for me. I do not have the right to force or blame you. But please inform us, whether it works on Windows or not. Is it a temporary issue or is JCB just not running on Windows. So I can arrange myself und try other solutions (that are not so good like JCB - but running on Windows). Thank you, Rachel

👍 1

Rachel commented

2025-05-15 11:02:59 +00:00

I would like to help with giving more detail, but unfortunately, I do not understand exaktly, what you want. I'm not a programmer. I learned PHP by myself and I do not habe a developer-system. Sorry.

Erik van Doorne commented

2025-05-15 11:10:49 +00:00

For those of you who do not have a Linux system at their disposal, I'm happy to share some of the webspace we have. We run a large grid of Linux servers and fellow developers and JCB users/developers are welcome to use it for development and testing purposes. Please feel free to contact me at erik@mastersofmedia.nl for more details.

👍 1

Llewellyn commented

2025-05-15 11:40:29 +00:00

Owner

First of all, I want to sincerely thank you for your continued interest in JCB and for using it within your own development workflow. I understand you’re encountering challenges running JCB on Windows, and I completely empathize with your frustration. I want to take a moment to offer some background and explain our current position in the most respectful and transparent way possible.

JCB was originally adapted to support Windows, thanks in large part to one of our core developers at the time, Marco Dings. Marco was a dedicated Windows user and consistently helped us shape cross-platform compatibility. Unfortunately, since his passing, we have not had an active Windows-based developer on the core team to carry that mantle forward.

The reality is that our entire infrastructure is now built on Ubuntu Linux, and we no longer run any Windows systems internally, not out of disregard, but purely out of practical and resource-driven reasons. Like many others, I too was once deeply tied to Windows (primarily due to applications like those from Adobe), but I eventually transitioned fully to Ubuntu, and it has since become our standard environment.

JCB has always been a tool we developed to streamline our own workflow and to rapidly build secure, scalable Joomla applications. It was born out of necessity, not as a commercial product. We’ve made it freely available in the spirit of sharing our success with the broader Joomla community. If you were to count the development hours invested into JCB, it would add up to a multi-million-dollar application. It’s powerful, complex, and evolving constantly—but it’s still very much shaped by our internal needs.

That being said, we’ve never intended to exclude Windows support. We do want JCB to work on Windows, and we have in the past made adjustments to accommodate it. However, as Windows has evolved, new issues have emerged, and without an in-house Windows developer, we’re unable to replicate or debug these problems ourselves.

We simply lack the time and resources to take on this area ourselves right now. When Windows-specific issues are reported, we often find ourselves at a dead end—not because we don’t care, but because we can’t reproduce the environment to test or fix the issue.

A specific area that’s been raised multiple times is the placement of class use statements in the generated code. These are currently handled through complex regex operations, and while we know this could be redesigned, doing so would require a dedicated week or more of development time—something that is costly for our small team focused on Linux-first needs.

So here’s the crux of the matter:

We need an advanced PHP developer who actively uses Windows and is willing to take ownership of these issues. Someone who can investigate, debug, and propose code changes that would restore and maintain Windows compatibility. We are open to integrating such contributions. JCB is modular and containerized, which means adapting or swapping out certain OS-dependent classes is very feasible. But we need the right person to champion this.

I deeply appreciate the space that @EvDoorne offered to support collaborative development. That kind of generosity is exactly what keeps open-source alive and thriving. We would absolutely welcome contributions from any Windows-based developer willing to take this on. If such support emerges, I’m confident we can get JCB running smoothly on Windows again.

In the meantime, I hope this gives you a clearer understanding of where things stand. It’s not that we don’t care—it’s just a matter of bandwidth and practical limitations. And it’s always been our intention to remain transparent and supportive where we can.

Thank you again for your understanding and for being part of the JCB community.

First of all, I want to sincerely thank you for your continued interest in JCB and for using it within your own development workflow. I understand you’re encountering challenges running JCB on Windows, and I completely empathize with your frustration. I want to take a moment to offer some background and explain our current position in the most respectful and transparent way possible. JCB was originally adapted to support Windows, thanks in large part to one of our core developers at the time, Marco Dings. Marco was a dedicated Windows user and consistently helped us shape cross-platform compatibility. Unfortunately, since his passing, we have not had an active Windows-based developer on the core team to carry that mantle forward. The reality is that our entire infrastructure is now built on Ubuntu Linux, and we no longer run any Windows systems internally, not out of disregard, but purely out of practical and resource-driven reasons. Like many others, I too was once deeply tied to Windows (primarily due to applications like those from Adobe), but I eventually transitioned fully to Ubuntu, and it has since become our standard environment. JCB has always been a tool we developed to streamline our own workflow and to rapidly build secure, scalable Joomla applications. It was born out of necessity, not as a commercial product. We’ve made it freely available in the spirit of sharing our success with the broader Joomla community. If you were to count the development hours invested into JCB, it would add up to a multi-million-dollar application. It’s powerful, complex, and evolving constantly—but it’s still very much shaped by our internal needs. That being said, we’ve never intended to exclude Windows support. We do want JCB to work on Windows, and we have in the past made adjustments to accommodate it. However, as Windows has evolved, new issues have emerged, and without an in-house Windows developer, we’re unable to replicate or debug these problems ourselves. We simply lack the time and resources to take on this area ourselves right now. When Windows-specific issues are reported, we often find ourselves at a dead end—not because we don’t care, but because we can’t reproduce the environment to test or fix the issue. A specific area that’s been raised multiple times is the placement of class use statements in the generated code. These are currently handled through complex regex operations, and while we know this could be redesigned, doing so would require a dedicated week or more of development time—something that is costly for our small team focused on Linux-first needs. So here’s the crux of the matter: We need an advanced PHP developer who actively uses Windows and is willing to take ownership of these issues. Someone who can investigate, debug, and propose code changes that would restore and maintain Windows compatibility. We are open to integrating such contributions. JCB is modular and containerized, which means adapting or swapping out certain OS-dependent classes is very feasible. But we need the right person to champion this. I deeply appreciate the space that @EvDoorne offered to support collaborative development. That kind of generosity is exactly what keeps open-source alive and thriving. We would absolutely welcome contributions from any Windows-based developer willing to take this on. If such support emerges, I’m confident we can get JCB running smoothly on Windows again. In the meantime, I hope this gives you a clearer understanding of where things stand. It’s not that we don’t care—it’s just a matter of bandwidth and practical limitations. And it’s always been our intention to remain transparent and supportive where we can. Thank you again for your understanding and for being part of the JCB community.

oxido commented

2025-06-04 00:10:20 +00:00

For those who can't part with windows, like me, I'll tell you what I did.
On a laptop I installed VirtualBox, then I installed Ubuntu in this virtualBox.
Then I was able to follow Llewellyn instructions in the tutorial on how to install Octojoom with docker and portainer.
Then I was able to do port forwarding from portainer for all my projects, I also added an ftp in docker to be able to connect to my projects with any IDE.
Now my laptop is like a server, I open it and use my desktop to connect and work, if I leave home, I just take my laptop with me and work directly on it.

For those who can't part with windows, like me, I'll tell you what I did. On a laptop I installed VirtualBox, then I installed Ubuntu in this virtualBox. Then I was able to follow Llewellyn instructions in the [tutorial](https://www.youtube.com/watch?v=owpxKie0I7s) on how to install Octojoom with docker and portainer. Then I was able to do port forwarding from portainer for all my projects, I also added an ftp in docker to be able to connect to my projects with any IDE. Now my laptop is like a server, I open it and use my desktop to connect and work, if I leave home, I just take my laptop with me and work directly on it.

peterpeter commented

2025-08-01 11:42:51 +00:00

Author

Breakthrough!
It took my a few hours (and beers), but here it is - so simple (as I thought) and just a one-liner!
It's about the used line endings in the templates (\n) and the used PHP constant PHP_EOL, wich differs on Windows (\r\n).

I've just changed this line:

banned/w4tf8omZyMSq

in

libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Power/Parser.php

After that change I was able to compile and install the demo component and it runs smoothly so far.
(on Windows)

Cheers
Roger

Breakthrough! It took my a few hours (and beers), but here it is - so simple (as I thought) and just a one-liner! It's about the used line endings in the templates (\n) and the used PHP constant PHP_EOL, wich differs on Windows (\r\n). I've just changed this line: banned/w4tf8omZyMSq in ``` libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Power/Parser.php ``` After that change I was able to compile and install the demo component and it runs smoothly so far. (on Windows) Cheers Roger

Llewellyn commented

2025-08-01 13:12:25 +00:00

Owner

@peterpeter please do not add links to other websites, this system is robust enough to display all the code changes, and documentation needed. So please add all the documentation for the fix right here. Thanks!

Llewellyn commented

2025-08-01 13:39:41 +00:00

Owner

If this Parser class is indeed the problem, here is the code needed to fix it:

// Normalize all line endings and BOM upfront before processing
private function normalizeCode(string $code): string
{
	// Remove UTF-8 BOM if present
	$code = preg_replace('/^\xEF\xBB\xBF/', '', $code);

	// Normalize all line endings to LF
	$code = str_replace(["\r\n", "\r"], "\n", $code);

	return $code;
}

public function code(string $code): array
{
	$code = $this->normalizeCode($code);
	...
}

public function getClassCode(string $code): ?string
{
	$code = $this->normalizeCode($code);
	...
}

public function getClassLicense(string $code): ?string
{
	$code = $this->normalizeCode($code);
	...
}

public function getUseStatements(string $code): ?array
{
	$code = $this->normalizeCode($code);
	...
}

// All other methods from your original class remain unchanged,
// except each one should now begin with:
// $code = $this->normalizeCode($code);
// This ensures all processing is line-ending and BOM-safe
// Example for properties():

private function properties(string $code): ?array
{
	$code = $this->normalizeCode($code);
	...
}

private function methods(string $code): ?array
{
	$code = $this->normalizeCode($code);
	...
}

// Apply the same pattern to every method that accepts $code as input.
// This keeps Windows compatibility universal without changing any logic.

We will be adding it to the next update.

If this `Parser` class is indeed the problem, here is the code needed to fix it: ``` // Normalize all line endings and BOM upfront before processing private function normalizeCode(string $code): string { // Remove UTF-8 BOM if present $code = preg_replace('/^\xEF\xBB\xBF/', '', $code); // Normalize all line endings to LF $code = str_replace(["\r\n", "\r"], "\n", $code); return $code; } public function code(string $code): array { $code = $this->normalizeCode($code); ... } public function getClassCode(string $code): ?string { $code = $this->normalizeCode($code); ... } public function getClassLicense(string $code): ?string { $code = $this->normalizeCode($code); ... } public function getUseStatements(string $code): ?array { $code = $this->normalizeCode($code); ... } // All other methods from your original class remain unchanged, // except each one should now begin with: // $code = $this->normalizeCode($code); // This ensures all processing is line-ending and BOM-safe // Example for properties(): private function properties(string $code): ?array { $code = $this->normalizeCode($code); ... } private function methods(string $code): ?array { $code = $this->normalizeCode($code); ... } // Apply the same pattern to every method that accepts $code as input. // This keeps Windows compatibility universal without changing any logic. ``` We will be adding it to the next update.

peterpeter commented

2025-08-01 15:29:59 +00:00

Author

At a short look, I guess that will not work, because $code (=JCB-Templates) already having \n and in this line
$lines = explode(PHP_EOL, $header);
the PHP_EOL means \r\n on Windows and still fails.

In normalizeCode() I would do something like
$code = str_replace("\n", PHP_EOL, $code);

This should adapt the line endings to the current operating system.

At a short look, I guess that will not work, because $code (=JCB-Templates) already having \n and in this line `$lines = explode(PHP_EOL, $header);` the PHP_EOL means \r\n on Windows and still fails. In normalizeCode() I would do something like `$code = str_replace("\n", PHP_EOL, $code);` This should adapt the line endings to the current operating system.

Llewellyn commented

2025-08-01 16:20:35 +00:00

Owner

The reason why this $code = str_replace(["\r\n", "\r"], "\n", $code); should work is because all the regex is targeting \n and not PHP_EOL so give the following a try:

/**
 * Normalize input PHP code to ensure cross-platform compatibility.
 *
 * This method removes the UTF-8 BOM (Byte Order Mark) if present and converts
 * all line endings to LF (`\n`). This ensures consistent parsing behavior across
 * operating systems, including Linux, macOS, and Windows.
 *
 * @param string $code The raw PHP code as a string
 *
 * @return string The normalized PHP code string with consistent line endings and no BOM
 * @since 5.1.2
 */
private function normalizeCode(string $code): string
{
	// UTF-8 BOM sequence
	static $BOM = "\xEF\xBB\xBF";

	// Remove UTF-8 BOM if present
	if (strncmp($code, $BOM, 3) === 0)
	{
		$code = substr($code, 3);
	}

	// Normalize line endings to LF in two fast passes
	$code = str_replace(["\r\n", "\r"], "\n", $code);

	return $code;
}

This should allow all regex to work in this class cross-platform, this is the new class code:

/**
 * Get properties and method declarations and other details from the given code.
 *
 * @param string  $code  The code containing class properties & methods
 *
 * @return array  An array of properties & method declarations of the given code
 * @since 3.2.0
 */
public function code(string $code): array
{
	$code = $this->normalizeCode($code);
	....
}

/**
 * Get the class body
 *
 * @param string $code The class as a string
 *
 * @return string|null The class body, or null if not found
 * @since 3.2.0
 **/
public function getClassCode(string $code): ?string
{
	$code = $this->normalizeCode($code);
	....
}

/**
 * Get the class license
 *
 * @param string $code The class as a string
 *
 * @return string|null The class license, or null if not found
 * @since 3.2.0
 **/
public function getClassLicense(string $code): ?string
{
	$code = $this->normalizeCode($code);
	....
}

/**
 * Extracts the first consecutive `use` statements from the given PHP class.
 *
 * @param string $code The PHP class as a string
 *
 * @return array|null An array of consecutive `use` statements
 * @since 3.2.0
 */
public function getUseStatements(string $code): ?array
{
	$code = $this->normalizeCode($code);
	....
}

/**
 * Extracts trait use statements from the given code.
 *
 * @param string  $code  The code containing class traits
 *
 * @return array|null An array of trait names
 * @since 3.2.0
 */
public function getTraits(string $code): ?array
{
	$code = $this->normalizeCode($code);
	....
}
....

/**
 * Normalize input PHP code to ensure cross-platform compatibility.
 *
 * This method removes the UTF-8 BOM (Byte Order Mark) if present and converts
 * all line endings to LF (`\n`). This ensures consistent parsing behavior across
 * operating systems, including Linux, macOS, and Windows.
 *
 * @param string $code The raw PHP code as a string
 *
 * @return string The normalized PHP code string with consistent line endings and no BOM
 * @since 5.1.2
 */
private function normalizeCode(string $code): string
{
	// UTF-8 BOM sequence
	static $BOM = "\xEF\xBB\xBF";

	// Remove UTF-8 BOM if present
	if (strncmp($code, $BOM, 3) === 0)
	{
		$code = substr($code, 3);
	}

	// Normalize line endings to LF in two fast passes
	$code = str_replace(["\r\n", "\r"], "\n", $code);

	return $code;
}

The idea of this class is a small basic parsing solution for JCB, that has no dependencies... and is easy to maintain. So all the old code remain unchanged in the calls, we just add the normalizeCode method, and that should be enough. I have not tested this yet (don't have a Window instance to test this), so let me know what you see.

The reason why this `$code = str_replace(["\r\n", "\r"], "\n", $code);` should work is because all the regex is targeting `\n` and not `PHP_EOL` so give the following a try: ``` /** * Normalize input PHP code to ensure cross-platform compatibility. * * This method removes the UTF-8 BOM (Byte Order Mark) if present and converts * all line endings to LF (`\n`). This ensures consistent parsing behavior across * operating systems, including Linux, macOS, and Windows. * * @param string $code The raw PHP code as a string * * @return string The normalized PHP code string with consistent line endings and no BOM * @since 5.1.2 */ private function normalizeCode(string $code): string { // UTF-8 BOM sequence static $BOM = "\xEF\xBB\xBF"; // Remove UTF-8 BOM if present if (strncmp($code, $BOM, 3) === 0) { $code = substr($code, 3); } // Normalize line endings to LF in two fast passes $code = str_replace(["\r\n", "\r"], "\n", $code); return $code; } ``` This should allow all regex to work in this class cross-platform, this is the new class code: ``` /** * Get properties and method declarations and other details from the given code. * * @param string $code The code containing class properties & methods * * @return array An array of properties & method declarations of the given code * @since 3.2.0 */ public function code(string $code): array { $code = $this->normalizeCode($code); .... } /** * Get the class body * * @param string $code The class as a string * * @return string|null The class body, or null if not found * @since 3.2.0 **/ public function getClassCode(string $code): ?string { $code = $this->normalizeCode($code); .... } /** * Get the class license * * @param string $code The class as a string * * @return string|null The class license, or null if not found * @since 3.2.0 **/ public function getClassLicense(string $code): ?string { $code = $this->normalizeCode($code); .... } /** * Extracts the first consecutive `use` statements from the given PHP class. * * @param string $code The PHP class as a string * * @return array|null An array of consecutive `use` statements * @since 3.2.0 */ public function getUseStatements(string $code): ?array { $code = $this->normalizeCode($code); .... } /** * Extracts trait use statements from the given code. * * @param string $code The code containing class traits * * @return array|null An array of trait names * @since 3.2.0 */ public function getTraits(string $code): ?array { $code = $this->normalizeCode($code); .... } .... /** * Normalize input PHP code to ensure cross-platform compatibility. * * This method removes the UTF-8 BOM (Byte Order Mark) if present and converts * all line endings to LF (`\n`). This ensures consistent parsing behavior across * operating systems, including Linux, macOS, and Windows. * * @param string $code The raw PHP code as a string * * @return string The normalized PHP code string with consistent line endings and no BOM * @since 5.1.2 */ private function normalizeCode(string $code): string { // UTF-8 BOM sequence static $BOM = "\xEF\xBB\xBF"; // Remove UTF-8 BOM if present if (strncmp($code, $BOM, 3) === 0) { $code = substr($code, 3); } // Normalize line endings to LF in two fast passes $code = str_replace(["\r\n", "\r"], "\n", $code); return $code; } ``` The idea of this class is a small basic parsing solution for JCB, that has no dependencies... and is easy to maintain. So all the old code remain unchanged in the calls, we just add the `normalizeCode` method, and that should be enough. I have not tested this yet (don't have a Window instance to test this), so let me know what you see.

peterpeter commented

2025-08-01 16:57:39 +00:00

Author

Unfortunately I have to leave, we have a public holiday here in switzerland and we are invited to a party.
But I'll try it out tomorrow ;-)

Unfortunately I have to leave, we have a public holiday here in switzerland and we are invited to a party. But I'll try it out tomorrow ;-)

peterpeter commented

2025-08-02 17:06:33 +00:00

Author

@Llewellyn
I have tried your code now and as I suspected, it does not work. In $code the \n remains after $this->normalizeCode() and the PHP_EOL value on my (windows) machine is still \r\n and thus the line
$lines = explode(PHP_EOL, $header);
still fails (see Screenshot) and because of this the compiler produces still files with double use declarations (screenshot2). I changed the line in normalizeCode() to this
$code = str_replace(["\r\n", "\n", "\r"], PHP_EOL, $code);
And this normalizes the line endings perfectly - doesn't matter what the source of $code or the running OS is.

@Llewellyn I have tried your code now and as I suspected, it does not work. In $code the \n remains after $this->normalizeCode() and the PHP_EOL value on my (windows) machine is still \r\n and thus the line `$lines = explode(PHP_EOL, $header);` still fails (see Screenshot) and because of this the compiler produces still files with double use declarations (screenshot2). I changed the line in normalizeCode() to this `$code = str_replace(["\r\n", "\n", "\r"], PHP_EOL, $code);` And this normalizes the line endings perfectly - doesn't matter what the source of $code or the running OS is.

screenshot2.png

20 KiB

screenshot1.png

174 KiB

peterpeter commented

2025-08-02 18:17:53 +00:00

Author

Nope, barked to soon, my code changes \n to \r\n\n, with str_replace() there are two steps necessary:

$code = str_replace(["\r\n", "\n", "\r"], 'JCB_EOL', `$code);
$code = str_replace('JCB_EOL', PHP_EOL, $code);

Nope, barked to soon, my code changes \n to \r\n\n, with str_replace() there are two steps necessary: $code = str_replace(["\r\n", "\n", "\r"], 'JCB_EOL', `$code); $code = str_replace('JCB_EOL', PHP_EOL, $code);

Compiled com_demo with errors (JCB 5.1.1-alpha4 / Joomla 5.3.0) #1219

Steps to reproduce the issue

Expected result

Actual result

System information (as much as possible)

Additional comments

Current project reality

We’re not opposed to Windows support – we just need help

Short-term workaround