jcb for joomla4 #964

Closed
opened 2022-12-05 16:45:32 +00:00 by saman2 · 47 comments
Member

hi.
Thank you for your continuous efforts
May I know at what stage is the upgrade of jcb for use in Joomla 4? when do you think it will be ready for use?
thank you

hi. Thank you for your continuous efforts May I know at what stage is the upgrade of jcb for use in Joomla 4? when do you think it will be ready for use? thank you

hi Saman i was told today the aim is to have it ready around januari 2023.

hi Saman i was told today the aim is to have it ready around januari 2023.
Owner

This was the exact words that was told to Tom and everyone else on the JCB Telegram group:

image

Llewellyn is traveling, and out of reach at times. So can someone just respond to Saman2. Our current aim is end January 2023. Seems like Llewellyn will get to spend much time on this in the following few days.

I am back and have been working on this very hard, I am not pushing code up because I don't like pushing things half done.

But I should push somethings soon... I am still aiming for END of January 2023 as this is the only window I have to finish this work.

Those who want to help will have to join me for code sprints in Namibia. Let me know!

This was the exact words that was told to Tom and everyone else on the [JCB Telegram group](https://t.me/jcb_group/637): ![image](/attachments/1cd725f3-d79c-49e0-88e4-52f7e9595795) > Llewellyn is traveling, and out of reach at times. So can someone just respond to Saman2. Our current aim is **end January 2023**. Seems like Llewellyn will get to spend much time on this in the following few days. I am back and have been working on this very hard, I am not pushing code up because I don't like pushing things half done. But I should push somethings soon... I am still aiming for **END of January 2023** as this is the only window I have to finish this work. Those who want to help will have to join me for code sprints **in Namibia**. Let me know!
168 KiB

Hmm flying to namibia sounds very tempting.

Hmm flying to namibia sounds very tempting.
Member

If you've seen our weather here in MN ... spending some time in Namibia would be a welcome change if I could (and if I really could help).

I'll just be sure to help with documentation/tutorials in any way I can when things are ready.

Keep up the great work and hope all is going well in 2023!

If you've seen our weather here in MN ... spending some time in Namibia would be a welcome change if I could (and if I really could help). I'll just be sure to help with documentation/tutorials in any way I can when things are ready. Keep up the great work and hope all is going well in 2023!

Hi!
Any news on the release? :)

Hi! Any news on the release? :)
Owner

Despite facing some challenges, we've made great strides in the JCB refactoring process. Manually transferring over 10,000 lines of code is a significant achievement and has resulted in a more organized and efficient design, with 100+ classes now in place.

But there's still work to be done. We've got 30,000 lines of code left to transfer and another 5,000 to add to make JCB fully compatible with Joomla 4. It may seem daunting, but I'm confident in my abilities to tackle these obstacles and reach our goal.

In the coming releases, JCB will also be able to incorporate composer packages with powers in a way that doesn't clash with Joomla. This is a big step forward and will greatly expand the possibilities of JCB in the long run.

To streamline our workflow, I've brought in the help of Rector and OpenAI. Rector will automate tedious tasks and make JCB PHP 8 compliant with ease, while OpenAI will provide valuable support and insights for more complex issues. Do note that Rector and OpenAI in JCB are not yet available to everyone, but will eventually become available. But it's important to note that OpenAI integration will only be available to those who opt for it as it will be a payed service.

Now, moving 10,000 lines of code took us two months, so we can expect that transferring the remaining lines and making the necessary updates will take several more months. But I'm dedicated to this project and will continue pressing forward.

In conclusion, we're making steady progress towards our goal of making JCB fully compatible with Joomla 4. With the support of tools like Rector and OpenAI, I'll be able to overcome the challenges ahead and deliver the best possible results for our clients and stakeholders.

Despite facing some challenges, we've made great strides in the JCB refactoring process. Manually transferring over 10,000 lines of code is a significant achievement and has resulted in a more organized and efficient design, with 100+ classes now in place. But there's still work to be done. We've got 30,000 lines of code left to transfer and another 5,000 to add to make JCB fully compatible with Joomla 4. It may seem daunting, but I'm confident in my abilities to tackle these obstacles and reach our goal. In the coming releases, JCB will also be able to incorporate composer packages with powers in a way that doesn't clash with Joomla. This is a big step forward and will greatly expand the possibilities of JCB in the long run. To streamline our workflow, I've brought in the help of Rector and OpenAI. Rector will automate tedious tasks and make JCB PHP 8 compliant with ease, while OpenAI will provide valuable support and insights for more complex issues. Do note that Rector and OpenAI in JCB are not yet available to everyone, but will eventually become available. But it's important to note that OpenAI integration will only be available to those who opt for it as it will be a payed service. Now, moving 10,000 lines of code took us two months, so we can expect that transferring the remaining lines and making the necessary updates will take several more months. But I'm dedicated to this project and will continue pressing forward. In conclusion, we're making steady progress towards our goal of making JCB fully compatible with Joomla 4. With the support of tools like Rector and OpenAI, I'll be able to overcome the challenges ahead and deliver the best possible results for our clients and stakeholders.
Owner

Please test the current release in which we move 30k+ lines of code:
https://git.vdm.dev/joomla/pkg-component-builder/archive/v3.1.15.zip

Please test the current release in which we move 30k+ lines of code: https://git.vdm.dev/joomla/pkg-component-builder/archive/v3.1.15.zip
Owner

@stutteringp0et with the new design we are able to use one switch (method) to target either Joomla 3 or Joomla 4, not only as the version being build for, but also the version being build on (or in)

This means JCB should be able to build for Joomla 4 while on Joomla 3 and once on Joomla 4 it should still be able to build for Joomle 3.

This switch will give us a few basic conventions, and are all implemented in the services of the container bootstrapping.

Here is an example... in the register function of this service provider we have two classes being registered, but its actually only one at this time. But this design allows us to only call for history, and the container gives us the class for the correct version because of this switching behavior. So when we add the Jooml4 way of dealing with history and drop that class in here the container will automatically load that new class instead, and because of the interface we will have continuity.

We are also doing this in the events service, but in the deference as you will see is that this time its based on what version JCB is running on. Here is a service that does not depend on the version your on, but the version your targeting.

Then more importantly all of the new code is generated via the powers area inside JCB. This means once we are ready to move towards Joomla 4 those who will help will need to setup JCB inside JCB with the import of the JCB package and use the powers area to extend JCB... this whole process is still under construction as I am planning to setup a JCB framework repository where all of the compiler code will be loaded and more... the idea is that JCB should be able to push code to this repository (which opens a pull request) and pull from this repository updates (which can either be fore testing or release ready). This architecture is critical to insure easy collaborative nature of the compiler in JCB. I know what I am working towards is ambitious, but I also know that is the only way this will work going forward without becoming impossible to maintain. You see our challenge is that we are moving from a file system to a database system. That decision to do this is long past... when we rolled out powers.

Look at this possible linker behavior that can be added to each power class. This will allow the easy linking with all dependencies and other relationships between all classes. This part of the new JCB is still being worked on, and most will not yet understand why this is needed. But in short most of the features that JCB had will endup on some class, and can be manually changed in the powers area of your own JCB, and to give a way to update your version of that feature, and or to share the changes you made to that feature JCB will have a direct link with this new "framework/compiler" repository and be able to push and pull based on your account access in GITEA.

@stutteringp0et with the new design we are able to use one switch (method) to target either Joomla 3 or Joomla 4, not only as the version being build for, but also the version being build on (or in) This means JCB should be able to build for Joomla 4 while on Joomla 3 and once on Joomla 4 it should still be able to build for Joomle 3. This switch will give us a few basic conventions, and are all implemented in the services of the container bootstrapping. Here is an example... in the [register](https://git.vdm.dev/joomla/Component-Builder/src/branch/staging/libraries/jcb_powers/VDM.Joomla/src/Componentbuilder/Compiler/Service/History.php#L45) function of this [service provider](https://git.vdm.dev/joomla/Component-Builder/src/branch/staging/libraries/jcb_powers/VDM.Joomla/src/Componentbuilder/Compiler/Service/History.php#L27) we have two classes being registered, but its actually only one at this time. But this design allows us to only call for history, and the container gives us the class for the correct version because of [this switching](https://git.vdm.dev/joomla/Component-Builder/src/branch/staging/libraries/jcb_powers/VDM.Joomla/src/Componentbuilder/Compiler/Service/History.php#L69) behavior. So when we add the Jooml4 way of dealing with history and drop that class in here the container will automatically load that new class instead, and because of the [interface](https://git.vdm.dev/joomla/Component-Builder/src/branch/staging/libraries/jcb_powers/VDM.Joomla/src/Componentbuilder/Compiler/Interfaces/HistoryInterface.php) we will have continuity. We are also doing this in the [events service](https://git.vdm.dev/joomla/Component-Builder/src/branch/staging/libraries/jcb_powers/VDM.Joomla/src/Componentbuilder/Compiler/Service/Event.php#L69), but in the [deference](https://git.vdm.dev/joomla/Component-Builder/src/branch/staging/libraries/jcb_powers/VDM.Joomla/src/Componentbuilder/Compiler/Service/Event.php#L66) as you will see is that this time its based on what version JCB is running on. Here is a [service](https://git.vdm.dev/joomla/Component-Builder/src/branch/staging/libraries/jcb_powers/VDM.Joomla/src/Componentbuilder/Compiler/Service/Field.php#L168) that does not depend on the version your on, but the version your targeting. Then more importantly all of the new code is generated via the powers area inside JCB. This means once we are ready to move towards Joomla 4 those who will help will need to setup JCB inside JCB with the import of the JCB package and use the powers area to extend JCB... this whole process is still under construction as I am planning to setup a JCB framework repository where all of the compiler code will be loaded and more... the idea is that JCB should be able to push code to this repository (which opens a pull request) and pull from this repository updates (which can either be fore testing or release ready). This architecture is critical to insure easy collaborative nature of the compiler in JCB. I know what I am working towards is ambitious, but I also know that is the only way this will work going forward without becoming impossible to maintain. You see our challenge is that we are moving from a file system to a database system. That decision to do this is long past... when we rolled out powers. Look at this possible [linker behavior](https://git.vdm.dev/joomla/Component-Builder/src/branch/staging/libraries/jcb_powers/VDM.Joomla/src/Componentbuilder/Compiler/Power/Infusion.php#L219) that can be added to each power class. This will allow the easy linking with all dependencies and other relationships between all classes. This part of the new JCB is still being worked on, and most will not yet understand why this is needed. But in short most of the features that JCB had will endup on some class, and can be manually changed in the powers area of your own JCB, and to give a way to update your version of that feature, and or to share the changes you made to that feature JCB will have a direct link with this new "framework/compiler" repository and be able to push and pull based on your account access in GITEA.
Member

This is a bit of a 'tangent', but you mentioned ...

"we are moving from a file system to a database system."

Will JCB still have the functional ability for us to do our custom coding with our own IDE like we presently have with the

"/***[JCBGUI."

etc code blocks. Where we code in our IDE and upon compile in JCB, it imports any changes?

Or will be required to code within the ID?

Not a critical issue, but helpful for us to know that are creating lots of custom code blocks - to know if there will be any workflow changes.

This is a bit of a 'tangent', but you mentioned ... "we are moving from a file system to a database system." Will JCB still have the functional ability for us to do our custom coding with our own IDE like we presently have with the "/***[JCBGUI." etc code blocks. Where we code in our IDE and upon compile in JCB, it imports any changes? Or will be required to code within the ID? Not a critical issue, but helpful for us to know that are creating lots of custom code blocks - to know if there will be any workflow changes.
Owner

We have no plans to remove features, only to add more that will enable our transition to Joomla 4 and beyond.

We have no plans to remove features, only to add more that will enable our transition to Joomla 4 and beyond.
Member

Not to add work onto your plate, but it's pretty clear that you have a vision for how this should be done, and I'm not inside your head.

Would it be possible for you to step into a project manager role from time-to-time, and perhaps create a list of specific tasks to be completed?

Until I'm versed in your vision - I hesitate to choose an item to work on. We all have our own ways of doing things, and although I have a pretty firm grasp on the code that JCB generates, the way it generates it has always been a monolith that I didn't spend too much time looking at.

TLDR; point me at a defined task so I may complete it

Not to add work onto your plate, but it's pretty clear that you have a vision for how this should be done, and I'm not inside your head. Would it be possible for you to step into a project manager role from time-to-time, and perhaps create a list of specific tasks to be completed? Until I'm versed in your vision - I hesitate to choose an item to work on. We all have our own ways of doing things, and although I have a pretty firm grasp on the code that JCB generates, the way it generates it has always been a monolith that I didn't spend too much time looking at. TLDR; point me at a defined task so I may complete it
Owner

I hear you, and fully understand. This is as you know why I am doing most of the work alone at this point.

There are some tedious tasks. like each time I move a function I need to know its dependencies. So I wrote this little script to help with that:

<?php

define('_JEXEC', 1);

if (file_exists('/media/llewellyn/Bucket/OCTOJOOM/Projects/jcb/joomla/defines.php'))
{
	include_once '/media/llewellyn/Bucket/OCTOJOOM/Projects/jcb/joomla/defines.php';
}

if (!defined('_JDEFINES'))
{
	define('JPATH_BASE', '/media/llewellyn/Bucket/OCTOJOOM/Projects/jcb/joomla');
	require_once JPATH_BASE . '/includes/defines.php';
}

require_once JPATH_BASE . '/includes/framework.php';

// register this component namespace
spl_autoload_register(function ($class) {
	// project-specific base directories and namespace prefix
	$search = [
		'libraries/jcb_powers/VDM.Joomla' => 'VDM\\Joomla',
		'libraries/jcb_powers/VDM.Minify' => 'VDM\\Minify',
		'libraries/jcb_powers/VDM.Gitea' => 'VDM\\Gitea',
		'libraries/jcb_powers/VDM.Psr' => 'VDM\\Psr'
	];
	// Start the search and load if found
	$found = false;
	$found_base_dir = "";
	$found_len = 0;
	foreach ($search as $base_dir => $prefix)
	{
		// does the class use the namespace prefix?
		$len = strlen($prefix);
		if (strncmp($prefix, $class, $len) === 0)
		{
			// we have a match so load the values
			$found = true;
			$found_base_dir = $base_dir;
			$found_len = $len;
			// done here
			break;
		}
	}
	// check if we found a match
	if (!$found)
	{
		// not found so move to the next registered autoloader
		return;
	}
	// get the relative class name
	$relative_class = substr($class, $found_len);
	// replace the namespace prefix with the base directory, replace namespace
	// separators with directory separators in the relative class name, append
	// with .php
	$file = JPATH_ROOT . '/' . $found_base_dir . '/src' . str_replace('\\', '/', $relative_class) . '.php';
	// if the file exists, require it
	if (file_exists($file))
	{
		require $file;
	}
});

use VDM\Joomla\Utilities\StringHelper;
use VDM\Joomla\Utilities\JsonHelper;
use VDM\Joomla\Utilities\ArrayHelper;
use VDM\Joomla\Utilities\ObjectHelper;
use VDM\Joomla\Utilities\GetHelper;
use VDM\Joomla\Utilities\FileHelper;

/**
 * get a string between two other strings
 *
 * @param  string       $content    The content to search
 * @param  string       $start      The starting value
 * @param  string       $end        The ending value
 * @param  string       $default    The default value if none found
 *
 * @return  array          On success / empty string on failure
 * @since  3.0.9
 */
function between(string $content, string $start, string $end, string $default = ''): string
{

	$match = [];

	$regex_value = '/' . $start.
		'([a-zA-Z0-9_\.]*)' . $end . '/';

	preg_match($regex_value, $content, $match);

	return $match[0] ?? $default;
}

/**
 * get all strings between two other strings
 *
 * @param  string       $content    The content to search
 * @param  string       $start      The starting value
 * @param  string       $end        The ending value
 *
 * @return  array|null          On success
 * @since  3.0.9
 */
function allBetween(string $content, string $start, string $end, array $quote): ?array
{
	// reset bucket
	$bucket = [];
	for ($i = 0; ; $i++)
	{
		// search for string
		$found = between($content,
			($quote['start']) ? preg_quote($start, '/') : $start,
			($quote['end']) ? preg_quote($end, '/') : $end
		);

		if (StringHelper::check($found))
		{
			// add to bucket
			$bucket[] = $found;

			// remove from content
			$content = str_replace($found, '', $content);
		}
		else
		{
			break;
		}

		// safety catch
		if ($i == 500)
		{
			break;
		}
	}

	// only return unique array of values
	if (ArrayHelper::check($bucket))
	{
		return  array_unique($bucket);
	}

	return null;
}

// get the file  preg_quote(, '/')
if (($content = FileHelper::getContent('extractor.txt', false)) !== false && StringHelper::check($content)) {
	$find = [
		[
			'name' => '$this->...[',
			'start' => '$this->',
			'end' => '[',
			'quote' => ['start' => true, 'end' => true]
		],
		[
			'name' => '$this->...->',
			'start' => '$this->',
			'end' => '->',
			'quote' => ['start' => true, 'end' => true]
		],
		[
			'name' => '$this->...(',
			'start' => '$this->',
			'end' => '(',
			'quote' => ['start' => true, 'end' => true]
		],
		[
			'name' => '$this->...',
			'start' => '$this->',
			'end' => '',
			'quote' => ['start' => true, 'end' => false]
		],
		[
			'name' => 'CFactory::_(...)->',
			'start' => 'CFactory::_(\'',
			'end' => '\')->',
			'quote' => ['start' => true, 'end' => true]
		],
		[
			'name' => 'Helpers::_()',
			'start' => '([a-zA-Z_]*)::',
			'end' => '([_a-zA-Z]*)\(',
			'quote' => ['start' => false, 'end' => false]
		]
	];
	foreach ($find as $get) {
		if (($this_arrays = allBetween($content, $get['start'], $get['end'], $get['quote'])) !== null &&
			ArrayHelper::check($this_arrays)) {
			echo "--------------------------\n";
			echo $get['name']. "\n";
			echo "--------------------------\n";
			foreach ($this_arrays as $remove) {
				$content = str_replace($remove, '', $content);
				echo $remove . "\n";
			}
		}
	}
}

This then gives me list of function calls, container calls and property calls that I know I should move. Once I have only container calls... the function is ready to move. This is kinda tedious, as it starts with the copying the functions into the same to_class.txt file to again see how many extra dependencies do we have. Once I have all the dependencies the thinking about the new architecture starts. Making choices about how much refactoring will I do, like here I hardly refactored the code, but here I broke it down to many smaller classes.

This has been what I have to do over and over and over and over... with each time I move stuff and refactor it I need to think about SOLID principles and how much I will be able at this time to implement them. To be honest I am not going all the way just yet... and for good reason, mostly time. But I am trying to get us as close to a place where the future steps towards full SOLID is easy and much more doable without the nightmare of causing more bugs when fixing things.

Then there is testing... and here it gets very tricky since I have many projects that use parts of JCB that other projects does not use... and so compiling all those project and looking at what changed takes time. Not to mention the fact that all this is happening in the original first JCB instance I ever build. Yes I am still working in that original instance, and I am changing it on the fly... there is not turning back once I install a change... without a major rest at least. So the very environment is moving as I am moving the code... and it has at times dropped me into a chicken and egg dilemma, where I can't compiler the change before I have not installed the last changes, and will only know if it worked once all has been installed... so in truth unless your in my office working on the same instance it will be hard to be part of the refactoring, simple because conversation and long explanation is often needed to understand why things where coded the way they where.

Here is the deep issue, JCB can do 100 times more than I have ever been able to document... simple because I do not have the time. The demo components was suppose to help show people what is possible, and yet I meet developers using JCB for a long time, who still are not even using it to 20% of its capacity.

So that translate into may thing in the code does not make sense unless you know the trick/secret of the compilers abilities.

In short, only way I can see developers helping me is being in the same office... and even then I know that will first slow the project down before speeding it up.

Then on top of this I am most certainly not the best of programmers, I still have so much to learn, and very often make the most elementary kind of mistakes that I feel like I have not even started to understand the simplicity of good design. But these mistakes do become binding at the time and should not be pushed up against as it kinda fill in the gaps so I can get this done.

Heads UP!

While having said all that, you mentioned the changes needed for the mysql stuff going forward. This I am also keenly aware of and will indeed be grateful for help in this area.

So my current idea is, once I have moved that area... which will still be a week or more before I get to that part. I will give you a heads-up and give you more explanation at that point of how it works. I will add the empty classes for Joomla 4 and you can simply fill them looking at Joomla 3 as the baseline.

Having said that there are already classes like that... not around the SQL stuff. But in relation to different behavior needed between the versions. Let me give some examples here.

When you open a folder like this one Compiler you see a folder called JoomlaThree Now there should also be a folder called JoomlaFour and in it should be the same files and therefore classes that will now follow the interface and return the same array or object or feature as we now have in Joomla 3, just now targeting Joomla 4.

So looking at Event.php you will see we have an interface... with trigger as the contract function. So you could look at all these JoomlaThree classes and try to write the JoomlaFour equivalent classes. Since the way we interact with plugins in Joomla 3 is different in Joomla 4. This also goes for History... and and... you get the point.

Another place where this is also needed is here in Field folder. The JoomlaThree has one class at the moment which I know going to Joomla 4 we have different paths... so we need an equivalent class.

As I continue this will come out all over the place, since my prime focus is moving the compiler out out into this new architecture, and basically dropping classes all over the place in these JoomlaThree type folders, someone like you can start writing the new code for Joomla 4. What you can do is monitor the repository for these folders and as you get time, drop int the Joomla 4 versions.

Now the way this should be done for now is that you can't really test it with absolute certainty that it will work, but you can sort of aim knowing the new conventions in Joomla 4 and the new classes, paths and expectations. Then I will take the code add it into powers, and it will wait to be tested once we step over... this time of transition will be shaky and we may need to sit in live calls and talk over things... but that is the only way I can see forward at this time.

So where ever you see JoomlaThree there should eventually be a JoomlaFour folder with the same classes.

So in short I am trying to split things as I go, decoupling it and preparing the way for all future versions of Joomla. Since there are what can be seen as the blue-print of the extension, and then there is the building based on this blue-print. Decoupling this is what I am doing, and at the same time setting us on a stable foundation where we can grow more naturally.

Hope this helps you to get your foot in the door.

I hear you, and fully understand. This is as you know why I am doing most of the work alone at this point. There are some tedious tasks. like each time I move a function I need to know its dependencies. So I wrote this little script to help with that: ``` <?php define('_JEXEC', 1); if (file_exists('/media/llewellyn/Bucket/OCTOJOOM/Projects/jcb/joomla/defines.php')) { include_once '/media/llewellyn/Bucket/OCTOJOOM/Projects/jcb/joomla/defines.php'; } if (!defined('_JDEFINES')) { define('JPATH_BASE', '/media/llewellyn/Bucket/OCTOJOOM/Projects/jcb/joomla'); require_once JPATH_BASE . '/includes/defines.php'; } require_once JPATH_BASE . '/includes/framework.php'; // register this component namespace spl_autoload_register(function ($class) { // project-specific base directories and namespace prefix $search = [ 'libraries/jcb_powers/VDM.Joomla' => 'VDM\\Joomla', 'libraries/jcb_powers/VDM.Minify' => 'VDM\\Minify', 'libraries/jcb_powers/VDM.Gitea' => 'VDM\\Gitea', 'libraries/jcb_powers/VDM.Psr' => 'VDM\\Psr' ]; // Start the search and load if found $found = false; $found_base_dir = ""; $found_len = 0; foreach ($search as $base_dir => $prefix) { // does the class use the namespace prefix? $len = strlen($prefix); if (strncmp($prefix, $class, $len) === 0) { // we have a match so load the values $found = true; $found_base_dir = $base_dir; $found_len = $len; // done here break; } } // check if we found a match if (!$found) { // not found so move to the next registered autoloader return; } // get the relative class name $relative_class = substr($class, $found_len); // replace the namespace prefix with the base directory, replace namespace // separators with directory separators in the relative class name, append // with .php $file = JPATH_ROOT . '/' . $found_base_dir . '/src' . str_replace('\\', '/', $relative_class) . '.php'; // if the file exists, require it if (file_exists($file)) { require $file; } }); use VDM\Joomla\Utilities\StringHelper; use VDM\Joomla\Utilities\JsonHelper; use VDM\Joomla\Utilities\ArrayHelper; use VDM\Joomla\Utilities\ObjectHelper; use VDM\Joomla\Utilities\GetHelper; use VDM\Joomla\Utilities\FileHelper; /** * get a string between two other strings * * @param string $content The content to search * @param string $start The starting value * @param string $end The ending value * @param string $default The default value if none found * * @return array On success / empty string on failure * @since 3.0.9 */ function between(string $content, string $start, string $end, string $default = ''): string { $match = []; $regex_value = '/' . $start. '([a-zA-Z0-9_\.]*)' . $end . '/'; preg_match($regex_value, $content, $match); return $match[0] ?? $default; } /** * get all strings between two other strings * * @param string $content The content to search * @param string $start The starting value * @param string $end The ending value * * @return array|null On success * @since 3.0.9 */ function allBetween(string $content, string $start, string $end, array $quote): ?array { // reset bucket $bucket = []; for ($i = 0; ; $i++) { // search for string $found = between($content, ($quote['start']) ? preg_quote($start, '/') : $start, ($quote['end']) ? preg_quote($end, '/') : $end ); if (StringHelper::check($found)) { // add to bucket $bucket[] = $found; // remove from content $content = str_replace($found, '', $content); } else { break; } // safety catch if ($i == 500) { break; } } // only return unique array of values if (ArrayHelper::check($bucket)) { return array_unique($bucket); } return null; } // get the file preg_quote(, '/') if (($content = FileHelper::getContent('extractor.txt', false)) !== false && StringHelper::check($content)) { $find = [ [ 'name' => '$this->...[', 'start' => '$this->', 'end' => '[', 'quote' => ['start' => true, 'end' => true] ], [ 'name' => '$this->...->', 'start' => '$this->', 'end' => '->', 'quote' => ['start' => true, 'end' => true] ], [ 'name' => '$this->...(', 'start' => '$this->', 'end' => '(', 'quote' => ['start' => true, 'end' => true] ], [ 'name' => '$this->...', 'start' => '$this->', 'end' => '', 'quote' => ['start' => true, 'end' => false] ], [ 'name' => 'CFactory::_(...)->', 'start' => 'CFactory::_(\'', 'end' => '\')->', 'quote' => ['start' => true, 'end' => true] ], [ 'name' => 'Helpers::_()', 'start' => '([a-zA-Z_]*)::', 'end' => '([_a-zA-Z]*)\(', 'quote' => ['start' => false, 'end' => false] ] ]; foreach ($find as $get) { if (($this_arrays = allBetween($content, $get['start'], $get['end'], $get['quote'])) !== null && ArrayHelper::check($this_arrays)) { echo "--------------------------\n"; echo $get['name']. "\n"; echo "--------------------------\n"; foreach ($this_arrays as $remove) { $content = str_replace($remove, '', $content); echo $remove . "\n"; } } } } ``` This then gives me list of function calls, container calls and property calls that I know I should move. Once I have only container calls... the function is ready to move. This is kinda tedious, as it starts with the copying the functions into the same `to_class.txt` file to again see how many extra dependencies do we have. Once I have all the dependencies the thinking about the new architecture starts. Making choices about how much refactoring will I do, like [here I hardly refactored](https://git.vdm.dev/joomla/Component-Builder/src/branch/staging/libraries/jcb_powers/VDM.Joomla/src/Componentbuilder/Compiler/Joomlamodule/Data.php#L226) the code, [but here](https://git.vdm.dev/joomla/Component-Builder/src/branch/staging/libraries/jcb_powers/VDM.Joomla/src/Componentbuilder/Compiler/Adminview/Data.php#L315) I broke it down to many smaller classes. This has been what I have to do over and over and over and over... with each time I move stuff and refactor it I need to think about [SOLID](https://www.digitalocean.com/community/conceptual-articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design) principles and how much I will be able at this time to implement them. To be honest I am not going all the way just yet... and for good reason, mostly time. But I am trying to get us as close to a place where the future steps towards full [SOLID](https://github.com/wataridori/solid-php-example) is easy and much more doable without the nightmare of causing more bugs when fixing things. Then there is testing... and here it gets very tricky since I have many projects that use parts of JCB that other projects does not use... and so compiling all those project and looking at what changed takes time. Not to mention the fact that all this is happening in the original first JCB instance I ever build. Yes I am still working in that original instance, and I am changing it on the fly... there is not turning back once I install a change... without a major rest at least. So the very environment is moving as I am moving the code... and it has at times dropped me into a chicken and egg dilemma, where I can't compiler the change before I have not installed the last changes, and will only know if it worked once all has been installed... so in truth unless your in my office working on the same instance it will be hard to be part of the refactoring, simple because conversation and long explanation is often needed to understand why things where coded the way they where. Here is the deep issue, JCB can do 100 times more than I have ever been able to document... simple because I do not have the time. The demo components was suppose to help show people what is possible, and yet I meet developers using JCB for a long time, who still are not even using it to 20% of its capacity. So that translate into may thing in the code does not make sense unless you know the trick/secret of the compilers abilities. In short, only way I can see developers helping me is being in the same office... and even then I know that will first slow the project down before speeding it up. Then on top of this I am most certainly not the best of programmers, I still have so much to learn, and very often make the most elementary kind of mistakes that I feel like I have not even started to understand the simplicity of good design. But these mistakes do become binding at the time and should not be pushed up against as it kinda fill in the gaps so I can get this done. ## Heads UP! While having said all that, you mentioned the changes needed for the mysql stuff going forward. This I am also keenly aware of and will indeed be grateful for help in this area. So my current idea is, once I have moved that area... which will still be a week or more before I get to that part. I will give you a heads-up and give you more explanation at that point of how it works. I will add the empty classes for Joomla 4 and you can simply fill them looking at Joomla 3 as the baseline. Having said that there are already classes like that... not around the SQL stuff. But in relation to different behavior needed between the versions. Let me give some examples here. When you open a folder like this one [Compiler](https://git.vdm.dev/joomla/Component-Builder/src/branch/staging/libraries/jcb_powers/VDM.Joomla/src/Componentbuilder/Compiler) you see a folder called [JoomlaThree](https://git.vdm.dev/joomla/Component-Builder/src/branch/staging/libraries/jcb_powers/VDM.Joomla/src/Componentbuilder/Compiler/JoomlaThree) Now there should also be a folder called JoomlaFour and in it should be the same files and therefore classes that will now follow the interface and return the same array or object or feature as we now have in Joomla 3, just now targeting Joomla 4. So looking at [Event.php](https://git.vdm.dev/joomla/Component-Builder/src/branch/staging/libraries/jcb_powers/VDM.Joomla/src/Componentbuilder/Compiler/JoomlaThree/Event.php) you will see we have an interface... with trigger as the contract function. So you could look at all these JoomlaThree classes and try to write the JoomlaFour equivalent classes. Since the way we interact with plugins in Joomla 3 is different in Joomla 4. This also goes for History... and and... you get the point. Another place where this is also needed is here in [Field](https://git.vdm.dev/joomla/Component-Builder/src/branch/staging/libraries/jcb_powers/VDM.Joomla/src/Componentbuilder/Compiler/Field) folder. The [JoomlaThree](https://git.vdm.dev/joomla/Component-Builder/src/branch/staging/libraries/jcb_powers/VDM.Joomla/src/Componentbuilder/Compiler/Field/JoomlaThree) has one class at the moment which I know going to Joomla 4 we have different paths... so we need an equivalent class. As I continue this will come out all over the place, since my prime focus is moving the compiler out out into this new architecture, and basically dropping classes all over the place in these JoomlaThree type folders, someone like you can start writing the new code for Joomla 4. What you can do is monitor the repository for these folders and as you get time, drop int the Joomla 4 versions. Now the way this should be done for now is that you can't really test it with absolute certainty that it will work, but you can sort of aim knowing the new conventions in Joomla 4 and the new classes, paths and expectations. Then I will take the code add it into powers, and it will wait to be tested once we step over... this time of transition will be shaky and we may need to sit in live calls and talk over things... but that is the only way I can see forward at this time. So where ever you see [JoomlaThree](https://git.vdm.dev/joomla/Component-Builder/src/branch/staging/libraries/jcb_powers/VDM.Joomla/src/Componentbuilder/Compiler/Extension/JoomlaThree) there should eventually be a JoomlaFour folder with the same classes. So in short I am trying to split things as I go, decoupling it and preparing the way for all future versions of Joomla. Since there are what can be seen as the blue-print of the extension, and then there is the building based on this blue-print. Decoupling this is what I am doing, and at the same time setting us on a stable foundation where we can grow more naturally. Hope this helps you to get your foot in the door.
Member

Greetings, @Llewellyn! I've had a chance to read your latest post, and after spending a few days reviewing the new jcb_powers area, I must say it looks stunning. It's amazing how every ten lines that were taken out of the old compiler resulted in thirty new lines being added. This overhaul has transformed JCB from an amzing tool into a revolution, and I'm thrilled to see this, as it will now clearly reflects the true genius of the compiler. Well done, Llewellyn!

However, there is still a lot of work to be done, and I'm curious to know how you plan to manage the new namespacing requirements of the new replacing helper classes, such as [[[Component]]]Helper::checkArray() => ArrayHelper::check(). If I'm to assist you with the new powers classes, we'll need to share a JCB instance as the Master. Do you have something like that set up?

I must admit that the interpretation class is a massive mountain of tremendous many classes waiting to be refactored. Many of which will be JoomlaThree classes, so it's unclear how many JoomlaFour classes will be needed. With that in mind, I don't want to put any more pressure on you, so I'm thinking about working on something that doesn't need to wait for you.

Please let me know what you think about this and whether it's a feasible plan. For now, I'm available to work on JCB during my weekends.

Greetings, @Llewellyn! I've had a chance to read your latest post, and after spending a few days reviewing the new jcb_powers area, I must say it looks stunning. It's amazing how every ten lines that were taken out of the old compiler resulted in thirty new lines being added. This overhaul has transformed JCB from an amzing tool into a revolution, and I'm thrilled to see this, as it will now clearly reflects the true genius of the compiler. Well done, Llewellyn! However, there is still a lot of work to be done, and I'm curious to know how you plan to manage the new namespacing requirements of the new replacing helper classes, such as `[[[Component]]]Helper::checkArray()` => `ArrayHelper::check()`. If I'm to assist you with the new powers classes, we'll need to share a JCB instance as the Master. Do you have something like that set up? I must admit that the interpretation class is a massive mountain of tremendous many classes waiting to be refactored. Many of which will be JoomlaThree classes, so it's unclear how many JoomlaFour classes will be needed. With that in mind, I don't want to put any more pressure on you, so I'm thinking about working on something that doesn't need to wait for you. Please let me know what you think about this and whether it's a feasible plan. For now, I'm available to work on JCB during my weekends.
Owner

The big next step is the home of all shared powers since JCB will start using powers as distribution of features and shared code, like a little GUI type composer running internally and dynamically alongside the powers area. I have given this much thought, and I have some ideas, but I am still a little stuck between two sometimes three fires. So I am thinking, we can start a new thread... and then I can share my ideas, and any input that will help me make some choices will be much appreciated.

The big next step is the [home of all shared powers](https://git.vdm.dev/power) since JCB will start using powers as distribution of features and shared code, like a little GUI type composer running internally and dynamically alongside the powers area. I have given this much thought, and I have some ideas, but I am still a little stuck between two sometimes three fires. So I am thinking, we can start a new thread... and then I can share my ideas, and any input that will help me make some choices will be much appreciated.

Any news on the progress towards being able to make my component compatible with j4?

I’m trying to plan out my development time.

Any news on the progress towards being able to make my component compatible with j4? I’m trying to plan out my development time.
Owner

I am still working diligently towards the same objective as before. There are many changes on the horizon that will further steer us down the path towards Joomla 4, as was our initial plan. I can't share more details at this moment...

Please note that JCB is being rigorously tested and is performing well on PHP 8.0. Consequently, it should now also be able to build extensions for PHP 8.0. It's worth mentioning the possibility that the End of Life (EOL) for Joomla 3 could be extended. This is mainly because a significant portion of Joomla is still running on J3.

However, our overall objective remains unchanged. As always, the only way to bolster our progress is through financial contributions. We experienced a surge in contributions earlier this year, but it's still not enough to achieve the momentum we're all eagerly awaiting.

I am still working diligently towards the same objective as before. There are many changes on the horizon that will further steer us down the path towards Joomla 4, as was our initial plan. I can't share more details at this moment... Please note that JCB is being rigorously tested and is performing well on PHP 8.0. Consequently, it should now also be able to build extensions for PHP 8.0. It's worth mentioning the possibility that the End of Life (EOL) for Joomla 3 could be extended. This is mainly because a significant portion of Joomla is still running on J3. However, our overall objective remains unchanged. As always, the only way to bolster our progress is through financial contributions. We experienced a surge in contributions earlier this year, but it's still not enough to achieve the momentum we're all eagerly awaiting.
Member

With Joomla 5 knocking on our doors soon, is there any chance, Joomla 4 compatibility will be there until then, or will you completely skip J!4 and work directly towards J!5?

With Joomla 5 knocking on our doors soon, is there any chance, Joomla 4 compatibility will be there until then, or will you completely skip J!4 and work directly towards J!5?
Owner

The newly refactored compiler will introduce a more refined design, adding three new areas to the JCB GUI soon:

  • Foundation
  • Architecture
  • Version

Initially, by design and proof of concept, these areas will be configured to build Joomla 3 extensions, as was the case previously. This will showcase the new sections, and like the "powers" area, they will be connected to global repositories. This integration will facilitate actions such as 'init', 're-sync', and more, in relation to our foundations, architectures, and versions. Furthermore, it will provide the capability to create custom architectures.

This signifies a complete shift away from the current hard-coded compiler components that solely target Joomla 3. In my view, it's not about skipping anything. I want JCB to support Joomla versions 3, 4, 5, 6, 7, 8, 9... and onwards. Additionally, I envision it to be independent of my personal preferences to the extent that the defaults represent what is stable. These defaults will serve as demonstrations of functionality, yet they can be easily and permanently altered without affecting the core.

I recognize that while explaining all of this, many might find it redundant as most simply desire a tool that satisfies their immediate needs. However, my goal is a tool that can consistently build highly complex extensions, indefinitely into the future.

We've recently updated the beta branch with another 1k of refactored lines. While constructing Joomla 4 extensions might not be particularly challenging, building an extension like JCB introduces several layers of complexity that demand careful planning and extensive research.

The newly refactored compiler will introduce a more refined design, adding three new areas to the JCB GUI soon: - Foundation - Architecture - Version Initially, by design and proof of concept, these areas will be configured to build Joomla 3 extensions, as was the case previously. This will showcase the new sections, and like the "powers" area, they will be connected to global repositories. This integration will facilitate actions such as 'init', 're-sync', and more, in relation to our foundations, architectures, and versions. Furthermore, it will provide the capability to create custom architectures. This signifies a complete shift away from the current hard-coded compiler components that solely target Joomla 3. In my view, it's not about skipping anything. I want JCB to support Joomla versions 3, 4, 5, 6, 7, 8, 9... and onwards. Additionally, I envision it to be independent of my personal preferences to the extent that the defaults represent what is stable. These defaults will serve as demonstrations of functionality, yet they can be easily and permanently altered without affecting the core. I recognize that while explaining all of this, many might find it redundant as most simply desire a tool that satisfies their immediate needs. However, my goal is a tool that can consistently build highly complex extensions, indefinitely into the future. We've recently updated the beta branch with [another 1k of refactored lines](https://git.vdm.dev/joomla-beta/com-componentbuilder/commit/69b84bbd302fb5b6972e96be34bc374a3e25db02). While constructing Joomla 4 extensions might not be particularly challenging, building an extension like JCB introduces several layers of complexity that demand careful planning and extensive research.
Member

Is there a way to build J!4 components with the current version?

Is there a way to build J!4 components with the current version?
Owner

Technically yes, but to achieve this would require a very comprehensive knowledge of the JCB current compiler and how it works.

We have a file currently that manages the file/folder structures called settings.json this file links template files to the compiler and each of these template files have placeholder in them that have matching function calls all over the compiler. So some JCB experts are already building for J4 with the current JCB... but I am not, and I am not planning to do so, nor going to help explain how it can be done.

My time is focused at getting the compiler refactored and then to move the settings.json config file into the GUI with the above explanation. Since while JCB as always had the capabilities to target any new versions and architecture, I hardly ever heard of any mastering this approach and those who did had to hack the core of JCB. Therefore it's for this reason that I am changing this to a much simpler and more dynamic solution.

Technically yes, but to achieve this would require a very comprehensive knowledge of the JCB current compiler and how it works. We have a file currently that manages the file/folder structures called [settings.json](https://git.vdm.dev/joomla/Component-Builder/src/branch/master/admin/compiler/joomla_3/settings.json) this file links template files to the compiler and each of these template files have placeholder in them that have matching function calls all over the compiler. So some JCB experts are already building for J4 with the current JCB... but I am not, and I am not planning to do so, nor going to help explain how it can be done. My time is focused at getting the compiler refactored and then to move the `settings.json` config file into the GUI with the [above explanation](https://git.vdm.dev/joomla/Component-Builder/issues/964#issuecomment-23581). Since while JCB as always had the capabilities to target any new versions and architecture, I hardly ever heard of any mastering this approach and those who did had to hack the core of JCB. Therefore it's for this reason that I am changing this to a much simpler and more dynamic solution.
Member

OK, is there a chance, JCB will be able to compile J!4 components soon (like within the next 3 months)? Don't get me wrong, I know there is a lot to do and you probably still have to work on other stuff for your living, but I did rely on the roadmap about a year ago, where it said, it was planned to be J!4 ready by the beginning of this year. Thing is, I really need to upgrade my site to J!4 and due to this component, I can't.
How is anyone else dealing with this problem? Do you all stay at J!3 till JCB catches up?

OK, is there a chance, JCB will be able to compile J!4 components soon (like within the next 3 months)? Don't get me wrong, I know there is a lot to do and you probably still have to work on other stuff for your living, but I did rely on the roadmap about a year ago, where it said, it was planned to be J!4 ready by the beginning of this year. Thing is, I really need to upgrade my site to J!4 and due to this component, I can't. How is anyone else dealing with this problem? Do you all stay at J!3 till JCB catches up?

@kommid for now, I stay with J3...

@kommid for now, I stay with J3...

@kommid Unfortunately, I've had to begin migrating my development process away from JCB. My clients were 'requesting' J4 compatibility, but now they are demanding it (esp. as other key extension developers are dropping J3 support). I was becoming the 'weak link' in my client's Joomla provider list and I've almost lost several projects due to not having J4 compatibility.
JCB was a great tool for helping me really increase my Joomla coding knowledge, but replying on it was starting to cost me money.
I might come back sometime when it is all done, but I think it's going in a different direction than I need it for just easily creating Joomla components for the active Joomla version.

@kommid Unfortunately, I've had to begin migrating my development process away from JCB. My clients were 'requesting' J4 compatibility, but now they are demanding it (esp. as other key extension developers are dropping J3 support). I was becoming the 'weak link' in my client's Joomla provider list and I've almost lost several projects due to not having J4 compatibility. JCB was a great tool for helping me really increase my Joomla coding knowledge, but replying on it was starting to cost me money. I might come back sometime when it is all done, but I think it's going in a different direction than I need it for just easily creating Joomla components for the active Joomla version.
Owner

JCB was a great tool for helping me really increase my Joomla coding knowledge, but relying on it was starting to cost me money.

This is a discouraging sentiment... was a great tool. I'd argue it's still a fantastic tool, unparalleled in the Joomla sphere.

As for this... but relying on it was starting to cost me money, let me articulate this with as much restraint as I can: Relying on JCB hasn't cost you money! It has earned you money. Now when it needs your support, you're considering walking away, suggesting:

I might come back sometime when it's all done.

There's plenty of justification for me to take this project private. Not only would my clients be thrilled as they'd be the first to leverage Joomla 4 extensions built with JCB, but I'd also have the funds I need to expedite its completion. Should I just abandon you, as it feels you're doing to me?

Let's talk numbers:

  • Total donations: $10,530.04
  • Initial development cost: $150,200.00 (just six months for one developer)

Excluding ongoing maintenance post-2016 and further development, I'm at a deficit of $139,669.96 because I banked on the JCB community. Yet, you're the one losing money?

When I gather my thoughts:

  • Firstly, I've come to terms with my investment in this project.
  • JCB will remain an unmatched free tool in Joomla for the foreseeable future.
  • If you can't speak positively about the project, for the sake of those still deeply committed, I'd ask you to refrain from negative remarks.

JCB will be Joomla 4-ready when I can make it so, given my resources and budget. No amount of negativity or guilt-tripping will expedite the process – only financial and code support will.

> JCB was a great tool for helping me really increase my Joomla coding knowledge, but relying on it was starting to cost me money. This is a discouraging sentiment... `was a great tool`. I'd argue it's still a fantastic tool, unparalleled in the Joomla sphere. As for this... `but relying on it was starting to cost me money`, let me articulate this with as much restraint as I can: **Relying on JCB hasn't cost you money!** It has earned you money. Now when it needs your support, you're considering walking away, suggesting: > I might come back sometime when it's all done. There's plenty of justification for me to take this project private. Not only would my clients be thrilled as they'd be the first to leverage Joomla 4 extensions built with JCB, but I'd also have the funds I need to expedite its completion. Should I just abandon you, as it feels you're doing to me? Let's talk numbers: - Total donations: **$10,530.04** - Initial development cost: **$150,200.00** (just six months for one developer) Excluding ongoing maintenance post-2016 and further development, I'm at a deficit of **$139,669.96** because I banked on the JCB community. Yet, *you're the one losing money*? When I gather my thoughts: - Firstly, I've come to terms with my investment in this project. - JCB will remain an unmatched free tool in Joomla for the foreseeable future. - If you can't speak positively about the project, for the sake of those still deeply committed, I'd ask you to refrain from negative remarks. JCB will be Joomla 4-ready when I can make it so, given my resources and budget. No amount of negativity or guilt-tripping will expedite the process – only **financial and code support** will.

@Llewellyn continue this way!

@cpaschen maybe change of client...ok it is not always easy, but I have always bad experience with client driving technic...this is not their cup of tea! I often say: "when you buy a car, do you care if this is V1, V2 or V3 of the motor...".

@Llewellyn continue this way! @cpaschen maybe change of client...ok it is not always easy, but I have always bad experience with client driving technic...this is not their cup of tea! I often say: "when you buy a car, do you care if this is V1, V2 or V3 of the motor...".

@Llewellyn continue this way!

I agree! Perseverance always pays off!!

Sometimes we have to: "not watch the clock; but instead, do what it does. Keep going!"

>@Llewellyn continue this way! I agree! Perseverance **always** pays off!! Sometimes we have to: "not watch the clock; but instead, do what it does. **Keep going!**"
Member

@fred-the-coder you can't just go out there and get yourself new clients. Many of us have built their client base over years, so did we and as @cpsachen said, develpers of other extensions that we use, start to drop J!3 support, which kind of forces us to migrate to J!4. That is excactly, why I wanted to have a more detailed statement about when JCB will be J!4 ready, as I really need to know in order to determine how to move on.

@fred-the-coder you can't just go out there and get yourself new clients. Many of us have built their client base over years, so did we and as @cpsachen said, develpers of other extensions that we use, start to drop J!3 support, which kind of forces us to migrate to J!4. That is excactly, why I wanted to have a more detailed statement about when JCB will be J!4 ready, as I really need to know in order to determine how to move on.
Owner

@kommid, you're missing the point. I am not willing to give you a date. It's simple: without significant financial contribution to JCB, I will only work on it during my free time. I don't want any deadline looming over my head. I've been saying this for months – unless the donation stream increases, I can't commit to any deadlines.

We all have clients we aim to please, and of course, we don't want to lose them. The fact is that Joomla 3 is the most stable Joomla version in the history of Joomla, having been under development for nearly four years. Add to that, most of Joomla's own infrastructure still runs on Joomla 3. They've even extended security support for another year: https://elts.joomla.org/.

I'd estimate that nearly 60% of all Joomla websites still run on older versions. And remember, Joomla 3 itself took a long time to mature.

Joomla 3 is compatible with PHP 8.0, and there are discussions about making it work with PHP 8.1. These aren't excuses for not moving on but are reasons why Joomla 3 remains a solid CMS option for at least another year.

Our clients trust our expertise. They know we wouldn't jeopardize their systems. Thus, they're willing to wait. Especially since I can't offer the same stability and continuity outside of JCB. My commitment to this project is unwavering. I won't let any client pull me away from JCB, and you shouldn't either.

We can assure our clients that JCB will be ready soon, and their patience will be rewarded.

For those clients who can't wait, direct them to the JCB donations page. It's simple: the more donations the project receives, the faster the progress.

So shift the pressure onto the client, not the developer who's been generously contributing. Instead, support this developer so he can dedicate himself more to the JCB project.

@kommid, you're missing the point. **I am not willing to give you a date**. It's simple: **without significant financial contribution** to JCB, I will only work on it during my free time. I don't want any deadline looming over my head. I've been saying this for months – unless the donation stream increases, I can't commit to any deadlines. We all have clients we aim to please, and of course, we don't want to lose them. The fact is that Joomla 3 is the **most stable Joomla version in the history of Joomla**, having been under development for nearly four years. Add to that, most of Joomla's *own infrastructure* still runs on Joomla 3. They've even extended security support for another year: [https://elts.joomla.org/](https://elts.joomla.org/). I'd estimate that nearly 60% of all Joomla websites still run on older versions. And remember, Joomla 3 itself took a long time to mature. Joomla 3 is compatible with PHP 8.0, and there are discussions about making it work with PHP 8.1. These aren't excuses for not moving on but are reasons why Joomla 3 remains a solid CMS option for at least another year. Our clients trust our expertise. They know we wouldn't jeopardize their systems. Thus, they're willing to wait. Especially since I can't offer the same stability and continuity outside of JCB. My commitment to this project is unwavering. I won't let any client pull me away from JCB, and you shouldn't either. We can assure our clients that JCB will be ready soon, and their patience will be rewarded. For those clients who can't wait, direct them to the [JCB donations page](https://opencollective.com/Joomla-Component-Builder). It's simple: **the more donations the project receives**, the *faster the progress*. So shift the *pressure onto the client*, not the developer who's been generously contributing. Instead, support this developer so he can dedicate himself more to the JCB project.

Just donated another 100 USD because i finished my 3rd JCB project. I'm the biggest contributor on there. and i've only created 3 paid projects with JCB so far. For every project i donate a fixed amount and i've also contributed to JCB 4 and a long time pro membership. But it seems i've been alone in this regard. Would be nice if more people start contributing financially. I'm probably one of the smaller ones out there in regards to how much money JCB made me. So i think it's time for others to step up to. Especially the ones complaining..

That way Llewellyn can get it done faster and we can all enjoy a nicer back-end and very nice J4 features we're missing out on now. Let the money roll 💰

Just donated another 100 USD because i finished my 3rd JCB project. I'm the biggest contributor on there. and i've only created 3 paid projects with JCB so far. For every project i donate a fixed amount and i've also contributed to JCB 4 and a long time pro membership. But it seems i've been alone in this regard. Would be nice if more people start contributing financially. I'm probably one of the smaller ones out there in regards to how much money JCB made me. So i think it's time for others to step up to. Especially the ones complaining.. That way Llewellyn can get it done faster and we can all enjoy a nicer back-end and very nice J4 features we're missing out on now. Let the money roll 💰
Member

Thank you @Llewellyn, for this wonderful tool.

I am not a full time programmer, JCB has made life a lot easier for me when I need to develop anything for my in house projects, I cannot say I am making money from it (yet) but it certaingly has helped me a lot in improving my processes via the apps I develop in it for my own use. I also have been a contributor for the pro membership for some time now,

I understand why a lot of us are eaguer to get JCB working on J!4, but I agree there is no rush. such a tool like this one is not available anywhre, and the easyness to create complex components, without all the repetitive work related to them is really time saving, I can wait for a propper implementation of JCB for J4!, but also I can try to help more.

for now I may not be able to increase my yearly contribution, but I would like to help where I can, if you guide me through it I can help, not a senior programmer here, neiither a newbee, so please let me help and I certainly will do gladly.

Thank you @Llewellyn, for this wonderful tool. I am not a full time programmer, JCB has made life a lot easier for me when I need to develop anything for my in house projects, I cannot say I am making money from it (yet) but it certaingly has helped me a lot in improving my processes via the apps I develop in it for my own use. I also have been a contributor for the pro membership for some time now, I understand why a lot of us are eaguer to get JCB working on J!4, but I agree there is no rush. such a tool like this one is not available anywhre, and the easyness to create complex components, without all the repetitive work related to them is really time saving, I can wait for a propper implementation of JCB for J4!, but also I can try to help more. for now I may not be able to increase my yearly contribution, but I would like to help where I can, if you guide me through it I can help, not a senior programmer here, neiither a newbee, so please let me help and I certainly will do gladly.
Author
Member

Thank you @Llewellyn, for this wonderful tool and we have to be thankful to you for this great and selfless effort
Is there any new good news about jcb compatibility with Joomla 4?

Thank you @Llewellyn, for this wonderful tool and we have to be thankful to you for this great and selfless effort Is there any new good news about jcb compatibility with Joomla 4?
Owner

@saman2, there has been significant progress over the last three weeks. We have essentially finished with the fields class. Since the last stable release of JCB v3.1.24, we've made changes to 533 files with 25,479 insertions(+) and 15,282 deletions(-) of lines of code.

Concerns:

  • Too few beta testers.
  • Too few beta testers.
  • Too few beta testers.

Due to the insufficient testing, our progress has been slow. If you'd like to assist, please test the beta-version and report any issues.

I am on the brink of starting the transition of the Interpretation & Infusion class. This signifies the beginning of the end of the refactoring for the Compiler. During this phase, we'll introduce new areas to JCB, which I explained here.

A lot of planning is taking place without tangible code to ensure we meet the objective of decoupling the targeted Joomla versions from hard-coded PHP files.

Our aspiration is to transform the Interpretation & Infusion into a database-driven feature, allowing users to expand JCB's functionality individually, without affecting the core.

This will pave the way for multiple build "outcomes" geared towards any Joomla version. We plan to transition the file templates, file structures, and the placeholder matching function calls to the GUI of JCB. While JCB's default will provide options for Joomla 3, 4, and eventually 5, developers won't need to wait on my updates. This means they might be able to target Joomla 4 even before JCB officially supports Joomla 4 or 5.

As ambitious as this may seem, we are genuinely nearing this goal, given all the adjustments made in recent weeks.

We anticipate releasing the prototype shortly, but as always I can't give you any dates.

@saman2, there has been significant progress over the last three weeks. We have essentially finished with the fields class. Since the last stable release of JCB v3.1.24, we've made changes to 533 files with 25,479 insertions(+) and 15,282 deletions(-) of lines of code. **Concerns:** - Too few beta testers. - Too few beta testers. - Too few beta testers. Due to the insufficient testing, our progress has been slow. If you'd like to assist, please test the [beta-version](https://git.vdm.dev/joomla-beta/pkg-component-builder/archive/master.zip) and report any issues. I am on the brink of starting the transition of the Interpretation & Infusion class. This signifies the beginning of the end of the refactoring for the Compiler. During this phase, we'll introduce new areas to JCB, which I [explained here](https://git.vdm.dev/joomla/Component-Builder/issues/964#issuecomment-23581). A lot of planning is taking place without tangible code to ensure we meet the objective of decoupling the targeted Joomla versions from hard-coded PHP files. Our aspiration is to transform the Interpretation & Infusion into a database-driven feature, allowing users to expand JCB's functionality individually, without affecting the core. This will pave the way for multiple build "outcomes" geared towards any Joomla version. We plan to transition the file templates, file structures, and the placeholder matching function calls to the GUI of JCB. While JCB's default will provide options for Joomla 3, 4, and eventually 5, developers won't need to wait on my updates. This means they might be able to target Joomla 4 even before JCB officially supports Joomla 4 or 5. As ambitious as this may seem, we are genuinely nearing this goal, given all the adjustments made in recent weeks. We anticipate releasing the prototype shortly, but as always I can't give you any dates.
Owner

Few remarks regarding:

this great

Yes, this is an immense undertaking, larger than I had initially perceived. While it's not inherently challenging to create Joomla 4 components, the breadth of JCB's compiler required a thorough refactoring to ensure its scalability for the future.

and selfless effort

This endeavor isn't entirely altruistic. JCB holds the potential to revolutionize the Joomla landscape, ushering in an era of unparalleled growth and empowering us all to shape the future of Joomla in profound ways.

Few remarks regarding: > this great Yes, this is an immense undertaking, larger than I had initially perceived. While it's not inherently challenging to create Joomla 4 components, the breadth of JCB's compiler required a thorough refactoring to ensure its scalability for the future. > and selfless effort This endeavor isn't entirely altruistic. JCB holds the potential to revolutionize the Joomla landscape, ushering in an era of unparalleled growth and empowering us all to shape the future of Joomla in profound ways.

Thanks! That's some encouraging news! :D I've been developing on Beta version but haven't had any mayor issues yet.

Thanks! That's some encouraging news! :D I've been developing on Beta version but haven't had any mayor issues yet.
Llewellyn pinned this 2023-10-13 17:27:33 +00:00

If you let me know what you need I'll happily help with the testing of any beta

If you let me know what you need I'll happily help with the testing of any beta
Owner

If you let me know what you need I'll happily help with the testing of any beta

How I let every one know.

I am pushing beta (still Joomla 3 in prep to Joomla 4) version out in this organization: https://git.vdm.dev/joomla-beta

To get notified of new beta/nightly builds:

Installing this beta version and running your normal tasks, and where you see issues, report them in the issue tracker. Always check if it has been reported already.

Read this wiki for more details: https://git.vdm.dev/joomla/Component-Builder/wiki/Beta-Testing

> If you let me know what you need I'll happily help with the testing of any beta **How I let every one know.** I am pushing beta (still Joomla 3 in prep to Joomla 4) version out in this organization: https://git.vdm.dev/joomla-beta To get notified of new beta/nightly builds: - https://git.vdm.dev/joomla-beta/pkg-component-builder (watch) this repository (so you get emails) - https://t.me/s/jcb_updates (join) this channel for updates (not only on the beta track, but all JCB updates) Installing this beta version and running your normal tasks, and where you see issues, report them in the [issue tracker](https://git.vdm.dev/joomla/Component-Builder/issues). Always check if it has been reported already. Read this wiki for more details: https://git.vdm.dev/joomla/Component-Builder/wiki/Beta-Testing
Author
Member

Hello. I understand that you are probably trying extra hard and I sincerely thank you for this great JCB. Is there significant progress or new good news?
(Please accept my apologies for not being able to beta test the JCB. In my opinion, Joomla Global Community Moderators should create a special program to support this extension. This is for the benefit of the entire Joomla community.)

Hello. I understand that you are probably trying extra hard and I sincerely thank you for this great JCB. Is there significant progress or new good news? (Please accept my apologies for not being able to beta test the JCB. In my opinion, Joomla Global Community Moderators should create a special program to support this extension. This is for the benefit of the entire Joomla community.)
Owner

Yes, there is huge progress, and I am looking forward to pushing out the next major changes. The last two weeks, I couldn't get to JCB as I had to focus on some paid work. But I hope to get back... and find myself very excited, as I realize the next few weeks are going to be tremendous.

Yes, there is huge progress, and I am looking forward to pushing out the next major changes. The last two weeks, I couldn't get to JCB as I had to focus on some paid work. But I hope to get back... and find myself very excited, as I realize the next few weeks are going to be tremendous.

Those are encouraging words :D Keep up the brilliant work 😍

Those are encouraging words :D Keep up the brilliant work 😍
Author
Member

hi again. is there any news about JCB for Joomla 4?
thank you

hi again. is there any news about JCB for Joomla 4? thank you
Author
Member

Hello, Joomla master.
We are eagerly waiting for jcb version of Joomla 4. Could there be a new surprise? Good news comes from Telegram channel.

Hello, Joomla master. We are eagerly waiting for jcb version of Joomla 4. Could there be a new surprise? Good news comes from Telegram channel.
Owner

Update on JCB Development

image

Progress Overview

For over a week now, my development environment has been actively engaged in the progression of JCB v3.1.31, particularly gearing it towards compatibility with Joomla versions 4 and 5.

image
image

Current Focus

  • Extensive Testing: I'm meticulously reviewing various components, including the demo, testing environments, and client extensions. This rigorous examination is crucial to validate the recent modifications I've implemented.
  • Backend Stability: My primary objective is to establish a robust and reliable backend for these extensions. It's a challenging but necessary foundation for future releases.

Challenges and Approach

  • Bug Fixing: The debugging process has been a mix of complexity, with some issues being straightforward to resolve, while others are more intricate, demanding several days of focused effort.
  • Beta Release Goals: I aim to release the first beta version shortly, contingent on achieving backend stability. This milestone is anticipated to occur this week.

Forward Planning

  • Frontend Development: Post the beta release, my attention will shift towards the frontend. Although JCB successfully generates all necessary files, I haven't started testing this aspect yet.
  • Feedback-Driven Iteration: As you begin testing the backend, your feedback will be invaluable and will directly influence the frontend development process.
  • Methodical Bug Resolution: My strategy is one of methodical precision, tackling each bug individually, ensuring complete resolution before moving on to the next. It's a slow, painstaking process but essential for thoroughness.

Current Achievements and Anticipations

  • Joomla 4 and 5 Compatibility: We've already been operating within the realms of Joomla versions 4 and 5 for over a week. This includes witnessing functional dashboards, list views, and edit views post-installation in both Joomla versions.
  • Upcoming Sharing: I'm looking forward to sharing these developments with you all soon, showcasing the strides we've made in this version of JCB.

Stay tuned for further updates as we continue to refine and enhance JCB, making significant strides in Joomla 4 and 5 compatibility.

## Update on JCB Development ![image](https://git.vdm.dev/attachments/32675739-96f1-4b72-950b-4805a31a81ab) ### Progress Overview For over a week now, my development environment has been actively engaged in the progression of JCB **v3.1.31**, particularly gearing it towards compatibility with Joomla versions 4 and 5. ![image](https://git.vdm.dev/attachments/c3785f49-2e65-40e8-af1e-55c1651fcd99) ![image](https://git.vdm.dev/attachments/cda90c67-672d-440e-9927-731ddc1948cb) ### Current Focus - **Extensive Testing**: I'm meticulously reviewing various components, including the demo, testing environments, and client extensions. This rigorous examination is crucial to validate the recent modifications I've implemented. - **Backend Stability**: My primary objective is to establish a robust and reliable backend for these extensions. It's a challenging but necessary foundation for future releases. ### Challenges and Approach - **Bug Fixing**: The debugging process has been a mix of complexity, with some issues being straightforward to resolve, while others are more intricate, demanding several days of focused effort. - **Beta Release Goals**: I aim to release the first beta version shortly, contingent on achieving backend stability. This milestone is anticipated to occur this week. ### Forward Planning - **Frontend Development**: Post the beta release, my attention will shift towards the frontend. Although JCB successfully generates all necessary files, I haven't started testing this aspect yet. - **Feedback-Driven Iteration**: As you begin testing the backend, your feedback will be invaluable and will directly influence the frontend development process. - **Methodical Bug Resolution**: My strategy is one of methodical precision, tackling each bug individually, ensuring complete resolution before moving on to the next. It's a slow, painstaking process but essential for thoroughness. ### Current Achievements and Anticipations - **Joomla 4 and 5 Compatibility**: We've already been operating within the realms of Joomla versions 4 and 5 for over a week. This includes witnessing functional dashboards, list views, and edit views post-installation in both Joomla versions. - **Upcoming Sharing**: I'm looking forward to sharing these developments with you all soon, showcasing the strides we've made in this version of JCB. *Stay tuned for further updates as we continue to refine and enhance JCB, making significant strides in Joomla 4 and 5 compatibility.*
320 KiB
150 KiB

In order to help testing (even if my workload is quite high for 2024Q1), is there a way to migrate (J3->J4 or J3->J5) an existing component made with JCB component and to compile it for J4/J5?

To compile a JCB component for J4/J5 do we need to be on a J4/J5 installation or it can work with a J3?

Thanks

And a BIG THANK YOU and CONGRATULATIONS @Llewellyn

In order to help testing (even if my workload is quite high for 2024Q1), is there a way to migrate (J3->J4 or J3->J5) an existing component made with JCB component and to compile it for J4/J5? To compile a JCB component for J4/J5 do we need to be on a J4/J5 installation or it can work with a J3? Thanks And a BIG THANK YOU and CONGRATULATIONS @Llewellyn
Owner

The plan is to release JCB 3.2 (soon), which will be compatible exclusively with Joomla 3. This version is designed to compile your existing components into a unified package that supports both Joomla 4 and 5.

There are two primary tasks that JCB 3.2 won't automate:

  1. Update of Custom Code: You'll need to modify all custom code to incorporate namespace implementation. This update is essential to align your code with the modern Joomla architecture.
  2. Manual Code Relocation: Custom code, particularly those modifications tailored for your Joomla 3 version, must be manually relocated to the appropriate file positions in the Joomla 4&5 version of your extension. We've introduced a new field in the custom code area for specifying the Joomla version targeted by your code. This will necessitate refactoring your code to adapt to namespace implementation and comply with Joomla 4+ and PHP 8.1+ standards.

Looking ahead, we plan to launch JCB 4.0 later this year. This version will operate on Joomla 4&5, enabling seamless development progression from these versions towards Joomla 3, 4, 5, and eventually Joomla 6.

JCB is undergoing significant transformation, streamlining the process of adapting to new Joomla versions. In the future, transitioning to newer Joomla versions should be a more efficient process.

While there's considerable work remaining, especially in refining the compiler, it's currently stable enough to support Joomla 4 and 5 simultaneously.

The plan is to release JCB 3.2 (soon), which will be compatible exclusively with **Joomla 3**. This version is designed to compile your existing components into a unified package that supports both **Joomla 4 and 5**. There are two primary tasks that JCB 3.2 won't automate: 1. **Update of Custom Code**: You'll need to modify all custom code to incorporate namespace implementation. This update is essential to align your code with the modern Joomla architecture. 2. **Manual Code Relocation**: Custom code, particularly those modifications tailored for your Joomla 3 version, must be manually relocated to the appropriate file positions in the Joomla 4&5 version of your extension. We've introduced a new field in the custom code area for specifying the Joomla version targeted by your code. This will necessitate refactoring your code to adapt to namespace implementation and comply with Joomla 4+ and PHP 8.1+ standards. Looking ahead, we plan to launch JCB 4.0 later this year. This version will operate on Joomla 4&5, enabling seamless development progression from these versions towards Joomla 3, 4, 5, and eventually Joomla 6. JCB is undergoing significant transformation, streamlining the process of adapting to new Joomla versions. In the future, transitioning to newer Joomla versions should be a more efficient process. While there's considerable work remaining, especially in refining the compiler, it's currently stable enough to support Joomla 4 and 5 simultaneously.
Member

Does Custom Code include all the functions in the helper php file?

Does Custom Code include all the functions in the helper php file?
Owner

The restructuring of our project aligns with Joomla's native approach, leading to the namespacing of the helper class as it transitions to a new location. This helper class will retain its abstract nature, along with its existing static methods, inclusive of those recently added. A key aspect of this transition is the introduction of a namespace for the helper class. Consequently, any method within this class that makes a call must adapt to the new structure by implementing the use Joomla\xxx\xxx; syntax.

Given the ongoing shift away from the traditional JXxxx class-mapping system, it's prudent to transition to the new format sooner rather than later. This proactive move is not just a mere adjustment; it's a strategic alignment with evolving Joomla standards.

I've taken the initiative to migrate all the JCB-generated code to this new format.

The restructuring of our project aligns with Joomla's native approach, leading to the namespacing of the helper class as it transitions to a new location. This helper class will retain its abstract nature, along with its existing static methods, inclusive of those recently added. A key aspect of this transition is the introduction of a namespace for the helper class. Consequently, any method within this class that makes a call must adapt to the new structure by implementing the `use Joomla\xxx\xxx;` syntax. Given the ongoing shift away from the traditional JXxxx class-mapping system, it's prudent to transition to the new format sooner rather than later. This proactive move is not just a mere adjustment; it's a strategic alignment with evolving Joomla standards. I've taken the initiative to migrate all the JCB-generated code to this new format.
Owner

Continue here #1025

Continue here https://git.vdm.dev/joomla/Component-Builder/issues/1025
Llewellyn locked as Resolved and limited conversation to collaborators 2024-01-19 08:00:33 +00:00
Llewellyn unpinned this 2024-01-19 08:00:38 +00:00
Sign in to join this conversation.
No Milestone
No project
No Assignees
14 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Reference: joomla/Component-Builder#964
No description provided.