[BUG]: Unable to save anything via Component Builder Configuration

tlark commented

2025-07-30 15:16:02 +00:00

What Happened?

I tried making config changes (via Options gear). The screen freezes for a bit, then a Chrome dialog about "taking too long" appears. The screen finally returns, but my changes aren't saved.

Looking at the logs (everything.php), the following stack trace occurs when I ENTER the Component Builder Configuration (i.e. without making any changes):

2025-07-30T14:55:11+00:00	CRITICAL 172.19.0.1	error	Uncaught Throwable of type Exception thrown with message "View not found [name, type, prefix]: ajax, json, Administrator". Stack trace: #0 [ROOT]/libraries/src/MVC/Controller/BaseController.php(655): Joomla\CMS\MVC\Controller\BaseController->getView('ajax', 'json', 'Administrator', Array)
#1 [ROOT]/libraries/src/MVC/Controller/BaseController.php(730): Joomla\CMS\MVC\Controller\BaseController->display()
#2 [ROOT]/libraries/src/Dispatcher/ComponentDispatcher.php(143): Joomla\CMS\MVC\Controller\BaseController->execute('getcronpath')
#3 [ROOT]/libraries/src/Component/ComponentHelper.php(361): Joomla\CMS\Dispatcher\ComponentDispatcher->dispatch()
#4 [ROOT]/libraries/src/Application/AdministratorApplication.php(150): Joomla\CMS\Component\ComponentHelper::renderComponent('com_componentbu...')
#5 [ROOT]/libraries/src/Application/AdministratorApplication.php(205): Joomla\CMS\Application\AdministratorApplication->dispatch()
#6 [ROOT]/libraries/src/Application/CMSApplication.php(304): Joomla\CMS\Application\AdministratorApplication->doExecute()
#7 [ROOT]/administrator/includes/app.php(58): Joomla\CMS\Application\CMSApplication->execute()
#8 [ROOT]/administrator/index.php(32): require_once('[ROOT]/a...')
#9 {main}

Steps to reproduce the Bug

Simple enter the configuration view (http://localhost:8180/administrator/index.php?option=com_config&view=component&component=com_componentbuilder)

Which Joomla version are you compiling in?

5.3.2

Which PHP version are you compiling in?

8.3

Which Joomla versions are you targeting?

5.x

Which PHP version are you targeting?

8.3

Which Web server is JCB running on?

Apache 2.4.62

Which Relational Database is JCB running on?

Mysql 8.0.42

Which OS is JCB running on?

GNU/Linux 6.10.14-linuxkit

Which JCB version are you using?

5.1.1

Where in JCB did this issue occur?

Other

On which browsers did you encounter the issue?

Chrome

Additional Comments

No response

### What Happened? I tried making config changes (via Options gear). The screen freezes for a bit, then a Chrome dialog about "taking too long" appears. The screen finally returns, but my changes aren't saved. Looking at the logs (everything.php), the following stack trace occurs when I ENTER the Component Builder Configuration (i.e. without making any changes): ``` 2025-07-30T14:55:11+00:00 CRITICAL 172.19.0.1 error Uncaught Throwable of type Exception thrown with message "View not found [name, type, prefix]: ajax, json, Administrator". Stack trace: #0 [ROOT]/libraries/src/MVC/Controller/BaseController.php(655): Joomla\CMS\MVC\Controller\BaseController->getView('ajax', 'json', 'Administrator', Array) #1 [ROOT]/libraries/src/MVC/Controller/BaseController.php(730): Joomla\CMS\MVC\Controller\BaseController->display() #2 [ROOT]/libraries/src/Dispatcher/ComponentDispatcher.php(143): Joomla\CMS\MVC\Controller\BaseController->execute('getcronpath') #3 [ROOT]/libraries/src/Component/ComponentHelper.php(361): Joomla\CMS\Dispatcher\ComponentDispatcher->dispatch() #4 [ROOT]/libraries/src/Application/AdministratorApplication.php(150): Joomla\CMS\Component\ComponentHelper::renderComponent('com_componentbu...') #5 [ROOT]/libraries/src/Application/AdministratorApplication.php(205): Joomla\CMS\Application\AdministratorApplication->dispatch() #6 [ROOT]/libraries/src/Application/CMSApplication.php(304): Joomla\CMS\Application\AdministratorApplication->doExecute() #7 [ROOT]/administrator/includes/app.php(58): Joomla\CMS\Application\CMSApplication->execute() #8 [ROOT]/administrator/index.php(32): require_once('[ROOT]/a...') #9 {main} ``` ### Steps to reproduce the Bug Simple enter the configuration view (http://localhost:8180/administrator/index.php?option=com_config&view=component&component=com_componentbuilder) ### Which Joomla version are you compiling in? 5.3.2 ### Which PHP version are you compiling in? 8.3 ### Which Joomla versions are you targeting? 5.x ### Which PHP version are you targeting? 8.3 ### Which Web server is JCB running on? Apache 2.4.62 ### Which Relational Database is JCB running on? Mysql 8.0.42 ### Which OS is JCB running on? GNU/Linux 6.10.14-linuxkit ### Which JCB version are you using? 5.1.1 ### Where in JCB did this issue occur? Other ### On which browsers did you encounter the issue? Chrome ### Additional Comments _No response_

tlark added the

Bug

label 2025-07-30 15:16:02 +00:00

Lemuel commented

2025-07-30 15:30:20 +00:00

Member

Hi @tlark,
Please take note of the following items for your attention:

Chrome Compatibility Warning
Kindly review the warning regarding the use of JCB in Chrome:
🔗 Issue #1231 – Comment #38301
While this may not be directly related to your current issue, it's important to be aware of potential complications when using JCB with Chrome.
Related Issue for Reference
Please also take a look at this issue, which may offer additional context or insights:
🔗 Issue #1204 – Comment #36264

We would appreciate it if you could let us know whether following the suggestions provided resolves your issue. If not, we’re more than happy to assist further.

Hi @tlark, Please take note of the following items for your attention: 1. **Chrome Compatibility Warning** Kindly review the warning regarding the use of JCB in Chrome: 🔗 [Issue #1231 – Comment #38301](https://git.vdm.dev/joomla/Component-Builder/issues/1231#issuecomment-38301) While this may not be directly related to your current issue, it's important to be aware of potential complications when using JCB with Chrome. 2. **Related Issue for Reference** Please also take a look at this issue, which may offer additional context or insights: 🔗 [Issue #1204 – Comment #36264](https://git.vdm.dev/joomla/Component-Builder/issues/1204#issuecomment-36264) We would appreciate it if you could let us know whether following the suggestions provided resolves your issue. If not, we’re more than happy to assist further.

tlark commented

2025-07-30 15:49:54 +00:00

Author

I actually looked over [#1204 (comment)] before submitting this bug.

I do realize I'm using PHP 8.3 instead of 8.2, but I need that version to match what our website uses. Based on the stack trace, I would be surprised if it was a PHP version issue.

Also, I just tried with Firefox 141.0 and got the same stack trace.

I actually looked over [https://git.vdm.dev/joomla/Component-Builder/issues/1204#issuecomment-36264] before submitting this bug. I do realize I'm using PHP 8.3 instead of 8.2, but I need that version to match what our website uses. Based on the stack trace, I would be surprised if it was a PHP version issue. Also, I just tried with Firefox 141.0 and got the same stack trace.

Llewellyn commented

2025-07-30 19:38:11 +00:00

Owner

does this help: https://git.vdm.dev/joomla/Component-Builder/wiki/PHP-Settings

tlark commented

2025-07-31 11:18:35 +00:00

Author

does this help: https://git.vdm.dev/joomla/Component-Builder/wiki/PHP-Settings

Unfortunately not. All my php.ini settings are at or above those. And all php modules are installed.

> does this help: https://git.vdm.dev/joomla/Component-Builder/wiki/PHP-Settings Unfortunately not. All my php.ini settings are at or above those. And all php modules are installed.

Llewellyn commented

2025-08-01 11:36:29 +00:00

Owner

Thanks for following up and for checking the related issues and recommendations; it's clear you've already done some investigation on your side, and we appreciate that.

The issue you're describing sounds like one of those frustrating edge cases we occasionally run into. From experience, when a screen partially loads or changes don't save, it's often related to PHP limits like max_input_vars. But since you've already verified your PHP settings are all above the thresholds we recommend, and that all required modules are installed, that helps rule out some of the more common culprits.

Still, the stack trace you shared (View not found [name, type, prefix]: ajax, json, Administrator) does suggest something isn't quite resolving the way it should; possibly due to a subtle change in Joomla core behavior, or something environmental we haven't yet encountered ourselves.

Because of how tightly coupled JCB is with both Joomla and PHP, it's unfortunately very difficult for us to reproduce and fix every issue without insight into the specific project or environment setup. In our daily usage across multiple projects (also on Joomla 5.3 and PHP 8.2/8.3), we haven't encountered this particular behavior. But that doesn't mean it's not real or serious; just that the trigger might be unique to your configuration or data.

To be honest, one of the ongoing challenges we face is maintaining JCB across a moving ecosystem. Joomla and PHP evolve quickly, and every change upstream can potentially impact how things work. That's exactly why we built JCB; so that we could focus on maintaining one tool and, through that, help keep all our projects consistent and up to date.

But we can't do this alone.

We'd love to get to the bottom of this with you. If you're up for it, even a few steps of debugging; like temporarily enabling full error reporting, checking which internal call requests that missing AJAX view, or seeing if any custom overrides might be interfering; can go a long way. Every time someone digs in and shares those findings, it makes the whole ecosystem stronger, and often leads to permanent improvements in JCB itself.

We truly value all the contributions; bug reports, fixes, suggestions; and hope you'll consider helping us trace this one further. It might be something small, but the insights gained could benefit many others.

Thanks again for your effort so far, and let us know how you'd like to proceed. We're here to support you however we can.

Thanks for following up and for checking the related issues and recommendations; it's clear you've already done some investigation on your side, and we appreciate that. The issue you're describing sounds like one of those frustrating edge cases we occasionally run into. From experience, when a screen partially loads or changes don't save, it's often related to PHP limits like `max_input_vars`. But since you've already verified your PHP settings are all above the thresholds we recommend, and that all required modules are installed, that helps rule out some of the more common culprits. Still, the stack trace you shared (View not found [name, type, prefix]: ajax, json, Administrator) does suggest something isn't quite resolving the way it should; possibly due to a subtle change in Joomla core behavior, or something environmental we haven't yet encountered ourselves. Because of how tightly coupled JCB is with both Joomla and PHP, it's unfortunately very difficult for us to reproduce and fix every issue without insight into the specific project or environment setup. In our daily usage across multiple projects (also on Joomla 5.3 and PHP 8.2/8.3), we haven't encountered this particular behavior. But that doesn't mean it's not real or serious; just that the trigger might be unique to your configuration or data. To be honest, one of the ongoing challenges we face is maintaining JCB across a moving ecosystem. Joomla and PHP evolve quickly, and every change upstream can potentially impact how things work. That's exactly why we built JCB; so that we could focus on maintaining one tool and, through that, help keep all our projects consistent and up to date. But we can't do this alone. We'd love to get to the bottom of this with you. If you're up for it, even a few steps of debugging; like temporarily enabling full error reporting, checking which internal call requests that missing AJAX view, or seeing if any custom overrides might be interfering; can go a long way. Every time someone digs in and shares those findings, it makes the whole ecosystem stronger, and often leads to permanent improvements in JCB itself. We truly value all the contributions; bug reports, fixes, suggestions; and hope you'll consider helping us trace this one further. It might be something small, but the insights gained could benefit many others. Thanks again for your effort so far, and let us know how you'd like to proceed. We're here to support you however we can.

tlark commented

2025-08-06 12:11:46 +00:00

Author

I'm definitely willing to help. I've got 30+ years of backend software design and implementation, so I think I can gather more debugging info for sure.

I already have Joomla full debug/error logging enabled, but nothing other than the stack trace is logged.

I also have Xdebug installed in the Docker image, so I can set breakpoints via PhpStorm.

I'm definitely willing to help. I've got 30+ years of backend software design and implementation, so I think I can gather more debugging info for sure. I already have Joomla full debug/error logging enabled, but nothing other than the stack trace is logged. I also have Xdebug installed in the Docker image, so I can set breakpoints via PhpStorm.

tlark commented

2025-08-06 17:51:52 +00:00

Author

Via Xdebug, I captured both the $_GET and $_REQUEST variables at the time of the exception:

$_GET = {string[6]} ["com_componentbu...", "ajax.getCronPat...", "json", "true", "4a98fb02f1e332e...", +1 more]
 option = "com_componentbuilder"
 task = "ajax.getCronPath"
 format = "json"
 raw = "true"
 token = "4a98fb02f1e332eb45b4866b85dfef2b"
 getType = "backup"
 
$_REQUEST = {string[11]} ["com_componentbu...", "ajax.getCronPat...", "json", "true", "4a98fb02f1e332e...", +6 more]
 option = "com_componentbuilder"
 task = "ajax.getCronPath"
 format = "json"
 raw = "true"
 token = "4a98fb02f1e332eb45b4866b85dfef2b"
 getType = "backup"
 osColorScheme = "light"
 nrid = "5669adcfdc723552"
 e295d41122e3b9107da5a2a5988fdf30 = "caccaf58fe6a1dcb824570a8983be3f9"
 770ffe4c24e04737cf5d863a82f17983 = "8d6e205736d0c27281dfc813912abd17"
 XDEBUG_SESSION = "YOUR-NAME"

Also, the URL that causes the 404:
http://localhost:8180/administrator/index.php?option=com_componentbuilder&task=ajax.getCronPath&format=json&raw=true&token=313210ef8a4b938227cc57b7fa4850c5&getType=backup

Maybe something to do with getCronPath?

Reviewing the source, I see other ajax tasks get registered in the AjaxController class via the registerTask method, but not getCronPath.

During a debug session, I manually invoked $this->registerTask('getCronPath', 'ajax'). This gave me a different error:

Further review shows there is no case 'getCronPath' in the switch statement of the ajax() method, which caused the above error.

Via Xdebug, I captured both the `$_GET` and `$_REQUEST` variables at the time of the exception: ``` $_GET = {string[6]} ["com_componentbu...", "ajax.getCronPat...", "json", "true", "4a98fb02f1e332e...", +1 more] option = "com_componentbuilder" task = "ajax.getCronPath" format = "json" raw = "true" token = "4a98fb02f1e332eb45b4866b85dfef2b" getType = "backup" $_REQUEST = {string[11]} ["com_componentbu...", "ajax.getCronPat...", "json", "true", "4a98fb02f1e332e...", +6 more] option = "com_componentbuilder" task = "ajax.getCronPath" format = "json" raw = "true" token = "4a98fb02f1e332eb45b4866b85dfef2b" getType = "backup" osColorScheme = "light" nrid = "5669adcfdc723552" e295d41122e3b9107da5a2a5988fdf30 = "caccaf58fe6a1dcb824570a8983be3f9" 770ffe4c24e04737cf5d863a82f17983 = "8d6e205736d0c27281dfc813912abd17" XDEBUG_SESSION = "YOUR-NAME" ``` Also, the URL that causes the 404: `http://localhost:8180/administrator/index.php?option=com_componentbuilder&task=ajax.getCronPath&format=json&raw=true&token=313210ef8a4b938227cc57b7fa4850c5&getType=backup` Maybe something to do with `getCronPath`? Reviewing the source, I see other ajax tasks get registered in the `AjaxController` class via the `registerTask` method, but not `getCronPath`. During a debug session, I manually invoked `$this->registerTask('getCronPath', 'ajax')`. This gave me a different error: <img width="733" alt="image.png" src="attachments/5bd71c2a-8c61-4187-82d3-d01f4200b141"> Further review shows there is no `case 'getCronPath'` in the `switch` statement of the `ajax()` method, which caused the above error.

image.png

89 KiB

Lemuel commented

2025-08-06 19:04:04 +00:00

Member

The getCronPath javascript was part of a feature originally available in JCB 3, allowing users to set up a cron job that would automatically trigger a build of their components at scheduled times. However, this feature was removed during the transition from Joomla 3 to Joomla 4. The main reason for its removal was the risk of conflicts—specifically, a cron-triggered build could occur while a user was actively editing fields or views within a component, potentially resulting in a broken or incomplete build.

The fact that the getCronPath AJAX request is still being triggered suggests that there may be some remnants of this old feature left in the global configuration of the component. It’s possible that a note reference or a hidden field still exists somewhere in the system. I plan to investigate this further in the near future to see what should be removed to fix this.

Thank you once again for your efforts in debugging this issue—we truly appreciate it. We will follow up with more information as we look into it. Additionally, we are planning to reintroduce a more powerful and robust solution to replace this functionality in the future.

After conducting further testing on my side, I was also able to reproduce the issue. However, I found that changes to the component configuration are still being saved successfully. If you’re able to pinpoint the exact location where this javascript is triggered and remove it, let us know if it fixed the issue. Your feedback would be greatly appreciated.

The `getCronPath` javascript was part of a feature originally available in JCB 3, allowing users to set up a cron job that would automatically trigger a build of their components at scheduled times. However, this feature was removed during the transition from Joomla 3 to Joomla 4. The main reason for its removal was the risk of conflicts—specifically, a cron-triggered build could occur while a user was actively editing fields or views within a component, potentially resulting in a broken or incomplete build. The fact that the `getCronPath` AJAX request is still being triggered suggests that there may be some remnants of this old feature left in the global configuration of the component. It’s possible that a note reference or a hidden field still exists somewhere in the system. I plan to investigate this further in the near future to see what should be removed to fix this. Thank you once again for your efforts in debugging this issue—we truly appreciate it. We will follow up with more information as we look into it. Additionally, we are planning to reintroduce a more powerful and robust solution to replace this functionality in the future. After conducting further testing on my side, I was also able to reproduce the issue. However, I found that changes to the component configuration are still being saved successfully. If you’re able to pinpoint the exact location where this javascript is triggered and remove it, let us know if it fixed the issue. Your feedback would be greatly appreciated.

Llewellyn commented

2025-08-06 20:05:32 +00:00

Owner

@Lemuel we need to remove the Auto Backup tab from the config area as this is obsolete at this point, and I see we did not remove it, while we already removed the PHP side of this legacy feature.

@Lemuel we need to remove the **Auto Backup** tab from the config area as this is obsolete at this point, and I see we did not remove it, while we already removed the PHP side of this legacy feature.

Llewellyn commented

2025-08-06 20:09:41 +00:00

Owner

@tlark removing these lines:

		admin/config.xml
		Lines 1016 to 1099 in 45453f7330
	
					<fieldset

						name="auto_backup_custom_config"

						label="COM_COMPONENTBUILDER_CONFIG_AUTO_BACKUP">

						<!-- Backupcronjob_note Field. Type: Note. A None Database Field. (joomla) -->

						<field type="note" name="backupcronjob_note" label="COM_COMPONENTBUILDER_CONFIG_BACKUPCRONJOB_NOTE_LABEL" description="COM_COMPONENTBUILDER_CONFIG_BACKUPCRONJOB_NOTE_DESCRIPTION" heading="h4" class="backupcronjob_note" />

						<!-- Cronjob_backup_type Field. Type: Radio. (joomla) -->

						<field

							type="radio"

							name="cronjob_backup_type"

							label="COM_COMPONENTBUILDER_CONFIG_CRONJOB_BACKUP_TYPE_LABEL"

							description="COM_COMPONENTBUILDER_CONFIG_CRONJOB_BACKUP_TYPE_DESCRIPTION"

							class="btn-group btn-group-yesno"

							default="1">

							<!-- Option Set. -->

							<option value="1">

								COM_COMPONENTBUILDER_CONFIG_LOCAL_FOLDER</option>

							<option value="2">

								COM_COMPONENTBUILDER_CONFIG_REMOTE_SERVER</option>

						</field>

						<!-- Cronjob_backup_server Field. Type: Cron_servers. (custom) -->

						<field

							type="cron_servers"

							name="cronjob_backup_server"

							label="COM_COMPONENTBUILDER_CONFIG_CRONJOB_BACKUP_SERVER_LABEL"

							description="COM_COMPONENTBUILDER_CONFIG_CRONJOB_BACKUP_SERVER_DESCRIPTION"

							class="list_class"

							layout="joomla.form.field.list-fancy-select"

							multiple="false"

							default="0"

							showon="cronjob_backup_type:2"

							button="true"

						/>

						<!-- Cronjob_backup_folder_path Field. Type: Text. (joomla) -->

						<field

							type="text"

							name="cronjob_backup_folder_path"

							label="COM_COMPONENTBUILDER_CONFIG_CRONJOB_BACKUP_FOLDER_PATH_LABEL"

							size="70"

							maxlength="150"

							description="COM_COMPONENTBUILDER_CONFIG_CRONJOB_BACKUP_FOLDER_PATH_DESCRIPTION"

							class="text_area"

							readonly="false"

							disabled="false"

							required="false"

							filter="PATH"

							message="COM_COMPONENTBUILDER_CONFIG_CRONJOB_BACKUP_FOLDER_PATH_MESSAGE"

							hint="COM_COMPONENTBUILDER_CONFIG_CRONJOB_BACKUP_FOLDER_PATH_HINT"

							autocomplete="on"

							showon="cronjob_backup_type:1"

						/>

						<!-- Backup_email Field. Type: Text. (joomla) -->

						<field

							type="text"

							name="backup_email"

							label="COM_COMPONENTBUILDER_CONFIG_BACKUP_EMAIL_LABEL"

							size="10"

							maxlength="50"

							description="COM_COMPONENTBUILDER_CONFIG_BACKUP_EMAIL_DESCRIPTION"

							class="text_area"

							filter="STRING"

							validate="email"

							message="COM_COMPONENTBUILDER_CONFIG_BACKUP_EMAIL_MESSAGE"

							hint="COM_COMPONENTBUILDER_CONFIG_BACKUP_EMAIL_HINT"

						/>

						<!-- Package_name_plaeholders Field. Type: Note. A None Database Field. (joomla) -->

						<field type="note" name="package_name_plaeholders" label="COM_COMPONENTBUILDER_CONFIG_PACKAGE_NAME_PLAEHOLDERS_LABEL" description="COM_COMPONENTBUILDER_CONFIG_PACKAGE_NAME_PLAEHOLDERS_DESCRIPTION" heading="h4" class="package_name_plaeholders" />

						<!-- Backup_package_name Field. Type: Text. (joomla) -->

						<field

							type="text"

							name="backup_package_name"

							label="COM_COMPONENTBUILDER_CONFIG_BACKUP_PACKAGE_NAME_LABEL"

							size="40"

							maxlength="150"

							default="JCB_Backup_[YEAR]_[MONTH]_[DAY]"

							description="COM_COMPONENTBUILDER_CONFIG_BACKUP_PACKAGE_NAME_DESCRIPTION"

							class="text_area"

							readonly="false"

							disabled="false"

							filter="STRING"

							message="COM_COMPONENTBUILDER_CONFIG_BACKUP_PACKAGE_NAME_MESSAGE"

							hint="COM_COMPONENTBUILDER_CONFIG_BACKUP_PACKAGE_NAME_HINT"

						/>

					</fieldset>

Should also remove this console error, but does this resolve the saving issue?

@tlark removing these lines: https://git.vdm.dev/joomla/Component-Builder/src/commit/45453f733054d606e78d7d2ec2c3f515fe359694/admin/config.xml#L1016-L1099 Should also remove this console error, but does this resolve the saving issue?

Llewellyn commented

2025-08-06 20:20:39 +00:00

Owner

@tlark you said:

also have Xdebug installed in the Docker image, so I can set breakpoints via PhpStorm.

Can you share some insight over here on how you set this up in Docker.
octoleo/octojoom#14 (comment)

I have not really spend must time on Xdebug, I am still an old-school var_dump debugger.

Which means adding the Xdebug feature to the official Joomla Docker images has not been my highest priority, but I am sure other would really appreciate it we can get that done. I will of course not make it part of the production ready images, but have a new set of extension developer images. Yet any insight you can share to confirm and improve the already suggested implementation will be helpful.

@tlark you said: > also have Xdebug installed in the Docker image, so I can set breakpoints via PhpStorm. Can you share some insight over here on how you set this up in Docker. https://git.vdm.dev/octoleo/octojoom/issues/14#issuecomment-36528 I have not really spend must time on Xdebug, I am still an old-school `var_dump` debugger. Which means adding the Xdebug feature to the official Joomla Docker images has not been my highest priority, but I am sure other would really appreciate it we can get that done. I will of course not make it part of the production ready images, but have a new set of extension developer images. Yet any insight you can share to confirm and improve the already suggested implementation will be helpful.

tlark commented

2025-08-07 12:07:13 +00:00

Author

Here are some links to help with using PhpStorm, Chrome with Xdebug:

And here's my Dockerfile I use to build Joomla w/Xdebug:

FROM joomla:5-php8.3-apache
RUN apt-get update && \
    apt-get install -y libtidy-dev &&  \
    docker-php-ext-install tidy
RUN pecl install xdebug && \
    echo "zend_extension=xdebug" > /usr/local/etc/php/conf.d/99-xdebug.ini && \
    echo "xdebug.mode=debug" >> /usr/local/etc/php/conf.d/99-xdebug.ini && \
    echo "xdebug.client_host=host.docker.internal" >> /usr/local/etc/php/conf.d/99-xdebug.ini
RUN chown -R www-data:www-data /var/www/html/ && \
    chmod -R 755 /var/www/html/

Here are some links to help with using PhpStorm, Chrome with Xdebug: - [Xdebug](https://xdebug.org/docs/) - [Xdebug Helper by JetBrains (Chrome extension)](https://chromewebstore.google.com/detail/xdebug-helper-by-jetbrain/aoelhdemabeimdhedkidlnbkfhnhgnhm?hl=en-US&utm_source=ext_sidebar) - [PhpStorm debugging](https://www.jetbrains.com/help/phpstorm/debugging-with-phpstorm-ultimate-guide.html) - [PhpStorm zero-config debugging](https://www.jetbrains.com/help/phpstorm/zero-configuration-debugging.html) And here's my Dockerfile I use to build Joomla w/Xdebug: ``` FROM joomla:5-php8.3-apache RUN apt-get update && \ apt-get install -y libtidy-dev && \ docker-php-ext-install tidy RUN pecl install xdebug && \ echo "zend_extension=xdebug" > /usr/local/etc/php/conf.d/99-xdebug.ini && \ echo "xdebug.mode=debug" >> /usr/local/etc/php/conf.d/99-xdebug.ini && \ echo "xdebug.client_host=host.docker.internal" >> /usr/local/etc/php/conf.d/99-xdebug.ini RUN chown -R www-data:www-data /var/www/html/ && \ chmod -R 755 /var/www/html/ ```

tlark commented

2025-08-07 12:24:37 +00:00

Author

@Llewellyn After removing those lines, no more stack trace. However, it still freezes for 30-60 seconds and does not appear to save.

I say "appear" since the UI view does not show my changes. Which DB table should contain my changes?

@Llewellyn After removing those lines, no more stack trace. However, it still freezes for 30-60 seconds and does not appear to save. I say "appear" since the UI view does not show my changes. Which DB table should contain my changes?