joomla/Component-Builder
40
26
Fork 12
Code Issues 80 Pull Requests 2 Projects 4 Wiki Activity

[BUG]: JCB Items "Checked Out" #1194

New Issue
Closed
opened 2024-12-04 00:57:31 +00:00 by mwweb · 15 comments
mwweb commented 2024-12-04 00:57:31 +00:00
Copy Link

What Happened?

I noticed with my dev site I've been working on, and installed a fresh install of Joomla 5.1.1, installed JCB 5.0.3, and JCB rows in tables are checked out according to System --> Global Checkin. Even components that I create using JCB, and install, show as records as checked out as well.

Steps to reproduce the Bug

Install Joomla 5.x, install JCB 5.0.3, navigate to System --> Global Checkin. At last count there we 673 JCB items checked out, and are unable to check back in.

Which Joomla version are you compiling in?

5.2.2

Which PHP version are you compiling in?

8.2.21

Which Joomla versions are you targeting?

5.x

Which PHP version are you targeting?

8.2+

Which Web server is JCB running on?

Apache/2.4.59 (Debian)

Which Relational Database is JCB running on?

11.4.2-MariaDB-ubu2404

Which OS is JCB running on?

Ubuntu 22.04.4 LTS

Which JCB version are you using?

v5.0.3

Where in JCB did this issue occur?

Installation of a component, Installation JCB pkg

On which browsers did you encounter the issue?

Firefox

Additional Comments

Looking at Joomla tables, checked_out is set to NULL, default NULL. When an item is checked out, it looks like the item is checked out with the Joomla user ID from the user table. When the user closes (checks in) the item, the checked_out field reverts to NULL.

In JCB the checked_out field correctly checks out by the Joomla user, but when the item is checked in, the checked_out field does not revert to NULL, but instead reverts to 0.

Manually changing checked_out from 0 to null in the DB clears the "issue" and no longer shows the item as checked out.

### What Happened? I noticed with my dev site I've been working on, and installed a fresh install of Joomla 5.1.1, installed JCB 5.0.3, and JCB rows in tables are checked out according to System --> Global Checkin. Even components that I create using JCB, and install, show as records as checked out as well. ### Steps to reproduce the Bug Install Joomla 5.x, install JCB 5.0.3, navigate to System --> Global Checkin. At last count there we 673 JCB items checked out, and are unable to check back in. ### Which Joomla version are you compiling in? 5.2.2 ### Which PHP version are you compiling in? 8.2.21 ### Which Joomla versions are you targeting? 5.x ### Which PHP version are you targeting? 8.2+ ### Which Web server is JCB running on? Apache/2.4.59 (Debian) ### Which Relational Database is JCB running on? 11.4.2-MariaDB-ubu2404 ### Which OS is JCB running on? Ubuntu 22.04.4 LTS ### Which JCB version are you using? v5.0.3 ### Where in JCB did this issue occur? Installation of a component, Installation JCB pkg ### On which browsers did you encounter the issue? Firefox ### Additional Comments Looking at Joomla tables, checked_out is set to NULL, default NULL. When an item is checked out, it looks like the item is checked out with the Joomla user ID from the user table. When the user closes (checks in) the item, the checked_out field reverts to NULL. In JCB the checked_out field correctly checks out by the Joomla user, but when the item is checked in, the checked_out field does not revert to NULL, but instead reverts to 0. Manually changing checked_out from 0 to null in the DB clears the "issue" and no longer shows the item as checked out.
mwweb added the
Bug
 label 2024-12-04 00:57:31 +00:00
mwweb changed title from [BUG]: JCB Fields "Checked Out" to [BUG]: JCB Items "Checked Out" 2024-12-04 00:57:49 +00:00
Llewellyn commented 2024-12-06 00:37:18 +00:00
Owner
Copy Link

Thanks for your detailed explanation of the issue—it’s very helpful in pinpointing the problem.

After reviewing the current JCB behavior and Joomla's conventions, I noticed that JCB sets the checked_out field to 0 as the default and reverts to 0 upon check-in. However, Joomla’s expected behavior is for the checked_out field to revert to NULL when an item is checked in as you pointed out.

I will add the fix to this in the next update, and then bump this issue again for testing 👍

Thanks for your detailed explanation of the issue—it’s very helpful in pinpointing the problem. After reviewing the current JCB behavior and Joomla's conventions, I noticed that JCB sets the `checked_out` field to `0` as the default and reverts to `0` upon check-in. However, Joomla’s expected behavior is for the `checked_out` field to revert to `NULL` when an item is checked in as you pointed out. I will add the fix to this in the next update, and then bump this issue again for testing 👍
Llewellyn commented 2024-12-18 10:41:09 +00:00
Owner
Copy Link

JCB v5.0.4-beta2 has now been updated to fix this issue.

JCB [v5.0.4-beta2](https://git.vdm.dev/joomla/pkg-component-builder/archive/v5.0.4-beta2.zip) has now been updated to fix this issue.
mwweb commented 2025-01-25 19:16:29 +00:00
Author
Copy Link

I tested on a fresh install and it works. However, it appears that if upgrading an existing install of JCB, example have JCB 5.0.3 installed, and install 5.0.4-beta2, you will have to go through each DB table, update the field default value to null, then run an sql query to update the value in each row.

If the tables were updated to default=NULL, then Joomla checkin could check everything in with the push of a button.

I tested on a fresh install and it works. However, it appears that if upgrading an existing install of JCB, example have JCB 5.0.3 installed, and install 5.0.4-beta2, you will have to go through each DB table, update the field default value to null, then run an sql query to update the value in each row. If the tables were updated to default=NULL, then Joomla checkin could check everything in with the push of a button.
Llewellyn commented 2025-01-26 19:29:03 +00:00
Owner
Copy Link

you will have to go through each DB table, update the field default value to null

If the tables were updated to default=NULL

I am not sure what you mean whit this statement, since this is exactly what we did in 5.0.4-beta2.

Look here is the code:

In the base table.
Here we act on this setting in the schema base checker.

This means it should happen during update of the JCB component automatically, if not I will need some help from your side... I will need more debugging information. Since we do not get the same issue, and would need to understand why it does not happen on your side.

> you will have to go through each DB table, update the field default value to null > If the tables were updated to default=NULL I am not sure what you mean whit this statement, since this **is exactly** what we did in 5.0.4-beta2. Look here is the code: In the [base table](https://git.vdm.dev/joomla/Component-Builder/src/commit/418624b63e2efe348eca9fd1860e6dd925c2670b/libraries/vendor_jcb/VDM.Joomla/src/Abstraction/BaseTable.php#L112). Here we act on this setting in the [schema base checker](https://git.vdm.dev/joomla/Component-Builder/src/commit/418624b63e2efe348eca9fd1860e6dd925c2670b/libraries/vendor_jcb/VDM.Joomla/src/Abstraction/Schema.php#L476). This means it should happen during update of the JCB component automatically, if not I will need some help from your side... I will need more debugging information. Since we do not get the same issue, and would need to understand why it does not happen on your side.
mwweb commented 2025-02-08 19:09:45 +00:00
Author
Copy Link

I just tested, by creating a new Joomla Container in Octojoom for J!5.2.3. I then installed JCB 5.0.3.

I checked the DB and checked_out in JCB fields was Null Yes, Default 0.

After that, I installed JCB 5.1.0-rc1, and after install those fields appear to be unchanged. I have checked several fields.

I just tested, by creating a new Joomla Container in Octojoom for J!5.2.3. I then installed JCB 5.0.3. I checked the DB and checked_out in JCB fields was Null Yes, Default 0. After that, I installed JCB 5.1.0-rc1, and after install those fields appear to be unchanged. I have checked several fields.
Llewellyn commented 2025-02-08 23:01:49 +00:00
Owner
Copy Link

Can you give me the generated mysql and BaseTable.php (for Joomla 5)? here is what I get.. see install zip.

`checked_out` int unsigned,

The more, if I check the table file that runs an update (checking the table schema) here is that file... see that basetable zip.

'checked_out' => [
	'name' => 'checked_out',
	'label' => NULL,
	'type' => NULL,
	'title' => false,
	'list' => NULL,
	'store' => NULL,
	'tab_name' => NULL,
	'db' => [
		'type' => 'INT unsigned',
		'null_switch' => 'NULL',
		'key' => true,
		'key_name' => 'checkout'
	]
]

These are the only two file I know that effect the database during the installation and both these do not set the field default to 0

Can you give me the generated mysql and BaseTable.php (for Joomla 5)? here is what I get.. see install zip. ``` `checked_out` int unsigned, ``` The more, if I check the table file that runs an update (checking the table schema) here is that file... see that basetable zip. ``` 'checked_out' => [ 'name' => 'checked_out', 'label' => NULL, 'type' => NULL, 'title' => false, 'list' => NULL, 'store' => NULL, 'tab_name' => NULL, 'db' => [ 'type' => 'INT unsigned', 'null_switch' => 'NULL', 'key' => true, 'key_name' => 'checkout' ] ] ``` These are the only two file I know that effect the database during the installation and both these do not set the field default to `0`
install.mysql.utf8.zip
1.4 KiB
BaseTable.zip
2.4 KiB
mwweb commented 2025-02-15 19:56:22 +00:00
Author
Copy Link

It appears that the SQL may be correct, but I do see a difference between the demo basetable.php file, and the basetable.php file for VDM.

These differences are apparent in all of the components that I have.

It appears that the SQL may be correct, but I do see a difference between the demo basetable.php file, and the basetable.php file for VDM. These differences are apparent in all of the components that I have.
BaseTable.zip
2.4 KiB
install.mysql.utf8.zip
1.4 KiB
mwweb commented 2025-02-23 22:12:32 +00:00
Author
Copy Link

I did some additional testing by creating a new Joomla install, and installing JCB 5.1.0.

From a FRESH install, JCB appears to create BaseTable.php correctly, but from an install where an extension is already installed, BaseTable.php is not getting updated (corrected).

The attached ZIP has 2 BaseTable.php files. The one titled BaseTable(existing).php is from my existing install, where BaseTable.php is from a fresh install of JCB.

I did some additional testing by creating a new Joomla install, and installing JCB 5.1.0. From a FRESH install, JCB appears to create BaseTable.php correctly, but from an install where an extension is already installed, BaseTable.php is not getting updated (corrected). The attached ZIP has 2 BaseTable.php files. The one titled BaseTable(existing).php is from my existing install, where BaseTable.php is from a fresh install of JCB.
BaseTable.zip
4.8 KiB
Llewellyn commented 2025-02-25 12:03:50 +00:00
Owner
Copy Link

Why Joomla Component Installation May Not Overwrite Existing Files & Possible Solutions

The issue where some files do not get updated during a Joomla component installation can arise due to several possible reasons. Since we do not experience this issue on our systems, it makes it difficult to debug directly, but based on experience and past reports in the Joomla and JCB communities, we can outline the most likely causes and solutions.

1. File System & Permission Issues

If Joomla successfully installs new files but fails to overwrite existing ones, it could be due to file system restrictions.

Possible Causes:

  • File Ownership Issues: If files are owned by a different user (e.g., root or another web user), Joomla (running under www-data or apache) may not have permission to overwrite them.
  • Permission Restrictions: Some files may have restrictive permissions (444 or 400) that prevent modification.
  • Locked Files: The operating system or another process (such as antivirus software or backup processes) may be locking the files, preventing them from being modified.

Solutions:

  1. Check File Ownership:

    ls -l /path/to/joomla/components/com_example/

    If files are not owned by the web server user, change ownership:

    sudo chown -R www-data:www-data /var/www/html/joomla

  2. Check File Permissions:

    ls -l /path/to/joomla/components/com_example/

    If files are set to 444 (read-only), update permissions:

    sudo chmod -R 644 /path/to/joomla/components/com_example/

  3. Ensure No File Locks Exist:

    lsof /path/to/problematic/file.php

    If a process is using the file, restart the web server:

    sudo systemctl restart apache2

2. Hosting Environment Restrictions (CloudLinux, cPanel, or Security Policies)

Many hosting providers use security layers like CloudLinux CageFS, Imunify360, or ModSecurity that can prevent Joomla from modifying certain files.

Possible Causes:

  • Hosting security policies may block PHP scripts from modifying system files.
  • cPanel file permissions may enforce immutable attributes on some files.

Solutions:

  1. Check for Immutable Files:

    lsattr /path/to/joomla/components/com_example/

    If a file has the i attribute, remove it:

    sudo chattr -i /path/to/file.php

  2. Temporarily Disable Hosting Security Features (If Allowed by Hosting Provider):

    cagefsctl --disable USERNAME

    If using cPanel, disable ModSecurity via the hosting control panel.

3. OPcache Not Refreshing Updated PHP Files

While OPcache does not affect the physical presence of files, it can cause outdated PHP code to be executed instead of the updated version.

Possible Causes:

  • OPcache may still serve old PHP bytecode, even though the files have been updated.

Solutions:

  • Manually Clear OPcache:

    <?php
if (function_exists('opcache_reset')) {
    opcache_reset();
    echo "OPcache successfully cleared.";
}
?>

    Access this file in the browser, then delete it.

  • Restart PHP-FPM (If Using Nginx/PHP-FPM):

    sudo systemctl restart php-fpm

  • Adjust OPcache Settings in php.ini:

    opcache.validate_timestamps=1
opcache.revalidate_freq=0

    Then restart Apache/Nginx:

    sudo systemctl restart apache2

4. Joomla Installer Process Not Completing Successfully

Joomla’s JInstaller process is responsible for copying files and updating the database. If an issue occurs during installation, some files may not be updated.

Possible Causes:

  • Joomla’s temporary folder (/tmp) is not writable.
  • JInstaller fails silently due to an incomplete or corrupted installation package.

Solutions:

  1. Check Joomla’s Temporary Directory Permissions:

    • Navigate to System → Global Configuration → Server → Path to Temp Folder.
    • Ensure the /tmp directory is writable: 
      sudo chmod -R 777 /var/www/html/joomla/tmp

  2. Use Joomla’s "Discover" Feature:

    • Go to Extensions → Manage → Discover.
    • Click Discover and then Install any missing extensions.

  3. Manually Replace Files (If Necessary):
    If Joomla does not overwrite files, manually extract the component’s .zip file and copy the files to the correct location.

5. Alternative Approach: Uninstalling and Reinstalling JCB (With Backup)

If all else fails, an alternative (but more complex) approach is to uninstall and reinstall JCB while preserving the database.

Steps to Safely Uninstall JCB:

  1. Backup JCB Database Tables:

    mysqldump -u username -p database_name --tables # list all JCB-related tables

    Ensure you save all JCB-related tables before proceeding.

  2. Uninstall JCB from Joomla Extensions Manager.

    • Go to Extensions → Manage → Manage and remove JCB.

  3. Restore the Old JCB Database Tables:

    mysql -u username -p database_name < jcb_backup.sql

  4. Reinstall JCB and Let It Auto-Update the Database.

    • Install JCB again, and the system will recognize the existing database structure and update it accordingly.

This method ensures that JCB’s database remains intact while resolving potential conflicts in the file system.

Conclusion

The fact that the files physically remain unchanged after installation suggests an issue at the file system level rather than Joomla itself. The most likely causes are:

  1. File permissions, ownership, or locked files.
  2. Hosting environment security restrictions (CloudLinux, CageFS, cPanel settings).
  3. OPcache serving outdated files, though not affecting file existence.
  4. Joomla installer failing silently.
  5. Uninstalling and reinstalling JCB (only as a last resort, with database backup).

Recommended Steps for the Client:

  1. Check and adjust file permissions (chown, chmod).
  2. Verify if files are locked (lsattr, lsof).
  3. Disable hosting security features if applicable.
  4. Manually clear OPcache and adjust its settings.
  5. Try using Joomla’s Discover Feature to detect missing files.
  6. Only as a last resort, back up the JCB database, uninstall JCB, and reinstall it.

This issue has not been observed on our systems, making it difficult to reproduce, but these solutions should help resolve it efficiently.

### **Why Joomla Component Installation May Not Overwrite Existing Files & Possible Solutions** The issue where some files do not get updated during a Joomla component installation can arise due to several possible reasons. Since we do not experience this issue on our systems, it makes it difficult to debug directly, but based on experience and past reports in the Joomla and JCB communities, we can outline the most likely causes and solutions. --- ## **1. File System & Permission Issues** If Joomla successfully installs new files but fails to overwrite existing ones, it could be due to file system restrictions. ### **Possible Causes:** - **File Ownership Issues**: If files are owned by a different user (e.g., `root` or another web user), Joomla (running under `www-data` or `apache`) may not have permission to overwrite them. - **Permission Restrictions**: Some files may have restrictive permissions (`444` or `400`) that prevent modification. - **Locked Files**: The operating system or another process (such as antivirus software or backup processes) may be locking the files, preventing them from being modified. ### **Solutions:** 1. **Check File Ownership:** ```bash ls -l /path/to/joomla/components/com_example/ ``` If files are not owned by the web server user, change ownership: ```bash sudo chown -R www-data:www-data /var/www/html/joomla ``` 2. **Check File Permissions:** ```bash ls -l /path/to/joomla/components/com_example/ ``` If files are set to `444` (read-only), update permissions: ```bash sudo chmod -R 644 /path/to/joomla/components/com_example/ ``` 3. **Ensure No File Locks Exist:** ```bash lsof /path/to/problematic/file.php ``` If a process is using the file, restart the web server: ```bash sudo systemctl restart apache2 ``` --- ## **2. Hosting Environment Restrictions (CloudLinux, cPanel, or Security Policies)** Many hosting providers use security layers like **CloudLinux CageFS**, **Imunify360**, or **ModSecurity** that can prevent Joomla from modifying certain files. ### **Possible Causes:** - Hosting security policies may block PHP scripts from modifying system files. - cPanel file permissions may enforce immutable attributes on some files. ### **Solutions:** 1. **Check for Immutable Files:** ```bash lsattr /path/to/joomla/components/com_example/ ``` If a file has the `i` attribute, remove it: ```bash sudo chattr -i /path/to/file.php ``` 2. **Temporarily Disable Hosting Security Features (If Allowed by Hosting Provider):** ```bash cagefsctl --disable USERNAME ``` If using cPanel, disable **ModSecurity** via the hosting control panel. --- ## **3. OPcache Not Refreshing Updated PHP Files** While OPcache does not affect the physical presence of files, it can cause outdated PHP code to be executed instead of the updated version. ### **Possible Causes:** - OPcache may still serve old PHP bytecode, even though the files have been updated. ### **Solutions:** - **Manually Clear OPcache:** ```php <?php if (function_exists('opcache_reset')) { opcache_reset(); echo "OPcache successfully cleared."; } ?> ``` Access this file in the browser, then delete it. - **Restart PHP-FPM (If Using Nginx/PHP-FPM):** ```bash sudo systemctl restart php-fpm ``` - **Adjust OPcache Settings in `php.ini`:** ```ini opcache.validate_timestamps=1 opcache.revalidate_freq=0 ``` Then restart Apache/Nginx: ```bash sudo systemctl restart apache2 ``` --- ## **4. Joomla Installer Process Not Completing Successfully** Joomla’s `JInstaller` process is responsible for copying files and updating the database. If an issue occurs during installation, some files may not be updated. ### **Possible Causes:** - Joomla’s temporary folder (`/tmp`) is not writable. - `JInstaller` fails silently due to an incomplete or corrupted installation package. ### **Solutions:** 1. **Check Joomla’s Temporary Directory Permissions:** - Navigate to **System → Global Configuration → Server → Path to Temp Folder**. - Ensure the `/tmp` directory is writable: ```bash sudo chmod -R 777 /var/www/html/joomla/tmp ``` 2. **Use Joomla’s "Discover" Feature:** - Go to **Extensions → Manage → Discover**. - Click **Discover** and then **Install** any missing extensions. 3. **Manually Replace Files (If Necessary):** If Joomla does not overwrite files, manually extract the component’s `.zip` file and copy the files to the correct location. --- ## **5. Alternative Approach: Uninstalling and Reinstalling JCB (With Backup)** If all else fails, an alternative (but more complex) approach is to **uninstall and reinstall JCB** while preserving the database. ### **Steps to Safely Uninstall JCB:** 1. **Backup JCB Database Tables:** ```bash mysqldump -u username -p database_name --tables # list all JCB-related tables ``` Ensure you save all JCB-related tables before proceeding. 2. **Uninstall JCB from Joomla Extensions Manager.** - Go to **Extensions → Manage → Manage** and remove JCB. 3. **Restore the Old JCB Database Tables:** ```bash mysql -u username -p database_name < jcb_backup.sql ``` 4. **Reinstall JCB and Let It Auto-Update the Database.** - Install JCB again, and the system will recognize the existing database structure and update it accordingly. This method ensures that JCB’s database remains intact while resolving potential conflicts in the file system. --- ## **Conclusion** The fact that the files **physically remain unchanged** after installation suggests an issue at the **file system level** rather than Joomla itself. The most likely causes are: 1. **File permissions, ownership, or locked files.** 2. **Hosting environment security restrictions (CloudLinux, CageFS, cPanel settings).** 3. **OPcache serving outdated files, though not affecting file existence.** 4. **Joomla installer failing silently.** 5. **Uninstalling and reinstalling JCB (only as a last resort, with database backup).** ### **Recommended Steps for the Client:** 1. **Check and adjust file permissions** (`chown`, `chmod`). 2. **Verify if files are locked** (`lsattr`, `lsof`). 3. **Disable hosting security features** if applicable. 4. **Manually clear OPcache** and adjust its settings. 5. **Try using Joomla’s Discover Feature** to detect missing files. 6. **Only as a last resort, back up the JCB database, uninstall JCB, and reinstall it.** This issue has not been observed on our systems, making it difficult to reproduce, but these solutions should help resolve it efficiently.
mwweb commented 2025-02-26 01:09:40 +00:00
Author
Copy Link

I guess I should update. There isn't any issue(s) with installing/updating the component. The issue is with the compiled component.

Steps:

  1. Go to Compiler, "Add to Repository Folder" = No
  2. Component Demo (Public)
  3. Compile
  4. Download the created component zip file.
  5. Extract the downloaded file com_demo_v5_0_0__J5.zip
  6. navigate to ../libraries/jcb_demo/Demo.Joomla/src/Abstraction/ and open BaseTable.php
  7. In that compiled file, for checked_out has 'default'=>'0'

I even tested by creating a new site, installed the SQL, then installed JCB 5.1.0, and same issue.

Attached is the JCB SQL

I guess I should update. There isn't any issue(s) with installing/updating the component. The issue is with the compiled component. Steps: 1. Go to Compiler, "Add to Repository Folder" = No 2. Component Demo (Public) 3. Compile 4. Download the created component zip file. 5. Extract the downloaded file com_demo_v5_0_0__J5.zip 6. navigate to ../libraries/jcb_demo/Demo.Joomla/src/Abstraction/ and open BaseTable.php 7. In that compiled file, for checked_out has 'default'=>'0' I even tested by creating a new site, installed the SQL, then installed JCB 5.1.0, and same issue. Attached is the JCB SQL
dev.zip
318 KiB
mwweb commented 2025-03-01 19:16:59 +00:00
Author
Copy Link

OK, I have done some ADDITIONAL debugging, and I can get my component to compile correctly. Here's what I did. I don't think this is a "good" upgrade path at this point.

Export the following fields:
componentbuilder_admin_fields
componentbuilder_admin_fields_conditions
componentbuilder_admin_view
componentbuilder_component_admin_views
componentbuilder_component_config
componentbuilder_component_files_folders
componentbuilder_component_site_views
componentbuilder_dynamic_get
componentbuilder_joomla_component
componentbuilder_layout
componentbuilder_site_view

Uninstall JCB, then import these field back into the DB
Next, you need to edit the install.mysql.utf8.sql file within joomla__Component-Builder__5.x.zip file in the JCB package. Remove any of the insert statements for the tables listed above. Re-package the files, then install JCB.

There "appears" to be something with a JCB table that was updated, but isn't being updated when exporting all JCB fields, uninstalling, re-importing, then installing JCB. Doing it this way required changing all of the INSERT INTO statements to REPLACE INTO, otherwise it resulted in duplicate errors.

Still debugging. Slowly narrowing down the issue.

Due to another job, I only have a limited number of hours per week to do anything with JCB, so it's been slow.

OK, I have done some ADDITIONAL debugging, and I can get my component to compile correctly. Here's what I did. I don't think this is a "good" upgrade path at this point. Export the following fields: componentbuilder_admin_fields componentbuilder_admin_fields_conditions componentbuilder_admin_view componentbuilder_component_admin_views componentbuilder_component_config componentbuilder_component_files_folders componentbuilder_component_site_views componentbuilder_dynamic_get componentbuilder_joomla_component componentbuilder_layout componentbuilder_site_view Uninstall JCB, then import these field back into the DB Next, you need to edit the install.mysql.utf8.sql file within joomla__Component-Builder__5.x.zip file in the JCB package. Remove any of the insert statements for the tables listed above. Re-package the files, then install JCB. There "appears" to be something with a JCB table that was updated, but isn't being updated when exporting all JCB fields, uninstalling, re-importing, then installing JCB. Doing it this way required changing all of the INSERT INTO statements to REPLACE INTO, otherwise it resulted in duplicate errors. Still debugging. Slowly narrowing down the issue. Due to another job, I only have a limited number of hours per week to do anything with JCB, so it's been slow.
mwweb commented 2025-03-24 00:33:09 +00:00
Author
Copy Link

OK, it doesn't actually appear to be related to DB tables. I thought it odd that it might have, since fields like checked_out are added by JCB in the code.

However, even after exporting DB, uninstalling JCB, import DB, then reinstall JCB (after removing all insert statements for the component, or it will error), components compiled are STILL compiling with BaseTable.php having default => 0 for checked out. I've looked at libraries/vendor_jcb/VDM.Joomla/src/Abstraction/BaseTable.php and it looks like it's correct there.

I know that the compiler is very complex. Is there somewhere that I could start looking where the compiler might be pulling that old outdate information for the BaseTable? Is it utilizing Joomla Powers, or Powers to do this? Something else?

OK, it doesn't actually appear to be related to DB tables. I thought it odd that it might have, since fields like checked_out are added by JCB in the code. However, even after exporting DB, uninstalling JCB, import DB, then reinstall JCB (after removing all insert statements for the component, or it will error), components compiled are STILL compiling with BaseTable.php having default => 0 for checked out. I've looked at libraries/vendor_jcb/VDM.Joomla/src/Abstraction/BaseTable.php and it looks like it's correct there. I know that the compiler is very complex. Is there somewhere that I could start looking where the compiler might be pulling that old outdate information for the BaseTable? Is it utilizing Joomla Powers, or Powers to do this? Something else?
mwweb commented 2025-05-31 19:05:55 +00:00
Author
Copy Link

I finally "gave up" trying to track down the issue, so I ended up installing a new instance of Joomla, fresh install of JCB, and completely rebuilt my component, and now it is working correctly. There would appear to be something in my old build that was causing the error, but what it is eludes me currently.

I finally "gave up" trying to track down the issue, so I ended up installing a new instance of Joomla, fresh install of JCB, and completely rebuilt my component, and now it is working correctly. There would appear to be something in my old build that was causing the error, but what it is eludes me currently.
Llewellyn commented 2025-06-01 07:24:31 +00:00
Owner
Copy Link

@mwweb the new version (5.1.1) of JCB comes with the new packager engine, and I would hope will allow more freedom to move around our extensions between JCB instances.

I will add you to the pre-test repo, so you can get early access to what we are working on (before we push it public)... it nearly ready for the next release, its a massive step forward.

This means we now have a new way to move snippets and all entities, I really think this way is far better than we had in J3, there is still much fin tuning to do. But we are nearly there...

@mwweb the new version (5.1.1) of JCB comes with the new packager engine, and I would hope will allow more freedom to move around our extensions between JCB instances. I will add you to the pre-test repo, so you can get early access to what we are working on (before we push it public)... it nearly ready for the next release, its a massive step forward. This means we now have a new way to move snippets and all entities, I really think this way is far better than we had in J3, there is still much fin tuning to do. But we are nearly there...
Lemuel commented 2025-06-24 09:14:36 +00:00
Member
Copy Link

@mwweb the new version (5.1.1) of JCB comes with the new packager engine, and I would hope will allow more freedom to move around our extensions between JCB instances.

The packaging engine is here: Official Announcement

> @mwweb the new version (5.1.1) of JCB comes with the new packager engine, and I would hope will allow more freedom to move around our extensions between JCB instances. The packaging engine is here: [Official Announcement](https://github.com/orgs/joomengine/discussions/992)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Beta
Issues related to the a beta release
Bug
Documentation
enhancement
help wanted
invalid
joomla
Joomla related changes
question
URGENT
wontfix
No Label
Bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
aamigo Lemuel Llewellyn Malachi Roline vistamedia Martin Martin Kopp aB0t Robot ro-ot root TLWebdesign Tom van der Laan
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: joomla/Component-Builder#1194
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?