Some reports of following error as a result of latest Joomla 4.4.11 update
Issue reported on Discord channel.
I have tested on vanilla installation on current version and do not see this error. But that could simply be environment related.
Have asked to OP to provider server logs to try and narrow issue down.
Below is capture of debug screen from OP's site...
400 error - Unable to store post
Issue reported on Discord channel.
I have tested on vanilla installation on current version and do not see this error. But that could simply be environment related.
Have asked to OP to provider server logs to try and narrow issue down.
Below is capture of debug screen from OP's site...
Attachments (1)
0
2 weeks ago
·
#38
Having the same issue after recent update? Any news on this?
Sadly the discord invite Link on your Homepage is not valid anymore
Sadly the discord invite Link on your Homepage is not valid anymore
Having the same issue after recent update? Any news on this?
Sadly the discord invite Link on your Homepage is not valid anymore
I will take a look at that. Someone must have changed the invite link on the server. At any rate it is much better to discuss this kind of stuff here.
There is a potentially related issue that has been posted over on Joomshaper that someone else has linked to - https://www.joomshaper.com/forum/question/37885
This leads me to think that this issue is definitely template related. Which is why this issue only appears on some sites. It does not appear on a vanilla installation, nor on at least two other instances reported by users. So there is a definite 50/50 split of those who have issues and those who do not.
A 400 error is a client side error. It generally means that the GET / POST data is malformed. I.e. the data sent to the server from the browser.
For those who are experiencing issues, I suggest to temporarily change to the default Joomla template and see if the issue persists.
Yes I don't think its related to the template and its reported if people revert back to Joomla 5.2.3 it works again. Don't know why this can be possible but thats the latest on Discord there under EasyBlog discussion solution..
The issue is definitely related to a change in the latest Joomla version (5.2.4), but the cause is unclear. I cannot replicate it on either a test server, or any of my live sites. I can post fine from both backend and front end.
For my installations on the test server it is vanilla installation of EasyBlog on PHP 8.3 / Joomla 5.2.4 / EB 6.0.15
Others also report the same (no issues).
Assuming that the Joomla update itself does not have a bug, the logical conclusion is that the issue is related to an incompatibility with either the template or a third party extension / module / plugin. Or even possibly server environment. i.e. something that differs between my test server and your server
The only way to isolate the cause is to go through the process of elimination. Disable ALL third party plugins and extensions and templates and see if it resolves the issue. If it does, re-enable them one at a time to identify which one is causing the issue. It's just basic fault finding procedure.
I could do that here, if I were able to replicate the issue, but I can't. If someone can pin point the cause so that I can replicate it on my test server, then I can start to look at a solution. But the first stage is to identify where the issue originates from, which requires input from someone with the issue. It's a PITA process to go through, and easier if you have a staging server so you are not impacting your live site.
Generally with SI support they will SSH into your server and take a look. Obviously we are not doing that here, so that investigative aspect is down to you guys.
Other places to look are server logs. This will tell us the URL of the call that is causing the issue, which may help. For example....
2025-02-25 09:16:07 [Mon Feb 24 22:46:07.929675 2025] [php:warn] [pid 102:tid 102] [client 192.168.65.1:37135] PHP Warning: Undefined property: EasyBlogPost::$introtext in /var/www/html/plugins/content/fields/src/Extension/Fields.php on line 66, referer: http://localhost:51005/index.php/blog/composer?tmpl=component&return=aHR0cDovL2xvY2FsaG9zdDo1MTAwNS9pbmRleC5waHAvYmxvZw%3D%3D
This will likely be different to the error report from the Joomla Debugging output as it is at a server level, but the two pieces of information together can help paint a better picture.
You can view the last few entries of your error log by using the following commands from the command line when you SSH into your server
tail /var/log/nginx/error.log
or
tail /var/log/apache2/error.log
depending on whether you are using apache or nginx
Also, some additional info / tests.
- Are you using a custom post template? Try posting using a blank post template
I did try to post using the included template types (News / Events / Videos) but could not replicate the error
- Could potentially be an easyblog plugin / module as well.
Again would need to disable each item to test to determine which one is causing issue.
- Are you using a custom post template? Try posting using a blank post template
I did try to post using the included template types (News / Events / Videos) but could not replicate the error
- Could potentially be an easyblog plugin / module as well.
Again would need to disable each item to test to determine which one is causing issue.
Joomshaper have released an update to their template that resolves the issue in their case...
But they don't divulge the cause. I suspect that they have fixed the malformed HTML in their templates...
Checkboxes are either checked
or unchecked
The default="1" attribute is not valid.
I did check through ALL of the code to see if I could spot any non-valid code, but only found one unrelated issue in the tab menu type which did not cause the issue.
We have solved the issue on our product. Install the latest Helix Ultimate template and the issue will be solved.
But they don't divulge the cause. I suspect that they have fixed the malformed HTML in their templates...
<input type="checkbox" default="1">
Checkboxes are either checked
<input type="checkbox" checked>
or unchecked
<input type="checkbox">
The default="1" attribute is not valid.
I did check through ALL of the code to see if I could spot any non-valid code, but only found one unrelated issue in the tab menu type which did not cause the issue.
In post.php just before the error is thrown, there is some debug code commented out...
If someone with the issue wants to try uncommenting the line and seeing what it spits out, it might give some insight
change
to
/var/www/html/administrator/components/com_easyblog/includes/post/post.php
// If failed to store post, throw exception.
if (!$state) {
// debug error.
// var_dump($this->post->getError());exit;
throw EB::exception('COM_EASYBLOG_COMPOSER_UNABLE_STORE_POST');
}
If someone with the issue wants to try uncommenting the line and seeing what it spits out, it might give some insight
change
// var_dump($this->post->getError());exit;
to
var_dump($this->post->getError());exit;
In SQL Database there is a table "`#__easyblog_post"
In this table there is a field "document" that doesn't have a default value for "Standard"
Got to edit this value in your database and choose "Null" from the value popup, then save.
Voila, after that you should be able to post again in backend and frontend.
Thanks to everyone posting and helping in this case
In this table there is a field "document" that doesn't have a default value for "Standard"
Got to edit this value in your database and choose "Null" from the value popup, then save.
Voila, after that you should be able to post again in backend and frontend.
Thanks to everyone posting and helping in this case

In SQL Database there is a table "`#__easyblog_post"
In this table there is a field "document" that doesn't have a default value for "Standard"
Got to edit this value in your database and choose "Null" from the value popup, then save.
Voila, after that you should be able to post again in backend and frontend.
Thanks to everyone posting and helping in this case![]()
This fix the problem there!!





Great work.
To clarify. This is the default value for the 'document' column in the #__easyblog_post table...
I note that in the sites that I have tested where posting is working, the default value is set to 'none'. So the issue is not as a result of any change to the database.
I would suggest that this is a workaround and that the root cause of the error itself is still as a result of something else. But. At least this gives us a starting point.
Did you manage to locate the post->store() method within the code? My code editor is not picking it up. Would be good to understand exactly why it is failing.
To clarify. This is the default value for the 'document' column in the #__easyblog_post table...
I note that in the sites that I have tested where posting is working, the default value is set to 'none'. So the issue is not as a result of any change to the database.
I would suggest that this is a workaround and that the root cause of the error itself is still as a result of something else. But. At least this gives us a starting point.
Did you manage to locate the post->store() method within the code? My code editor is not picking it up. Would be good to understand exactly why it is failing.
Attachments (1)
yes this is default value, but it in my case in database it was set to "kein(e)" don't know why. May be a matter of translation?
Til now I could not investigate further.
Unfortunately I can't access your image and/or screenshot: "The requested content cannot be loaded. Please try again later."
Til now I could not investigate further.
Unfortunately I can't access your image and/or screenshot: "The requested content cannot be loaded. Please try again later."
yes this is default value, but it in my case in database it was set to "kein(e)" don't know why. May be a matter of translation?
Yes, perhaps. Kein is 'none' in German.
I will look at the image permissions, it's just a screen grab of phpMyAdmin showing the settings.
Ok so think I've found the 'Store()' method.. On around line 94 of post.php
Again there is some commented out debug code..
Might give us some more info
public function store($updateNulls = false)
{
$state = false;
// updates the eb version.
$this->version = EB::getLocalVersion();
// echo '<pre>';
// var_dump(debug_backtrace(2));
// echo '</pre>';
// exit;
// Ensure that is not featured data because now trying to save into post table
if (isset($this->featured)) {
unset($this->featured);
}
// if created_by is empty, we do not want to save this record.
if ($this->created_by) {
$state = parent::store($updateNulls);
}
return $state;
}
Again there is some commented out debug code..
// echo '<pre>';
// var_dump(debug_backtrace(2));
// echo '</pre>';
// exit;
Might give us some more info
Ahh yes apologies, that's in tables/post.php
Just trying to get my head around the code flow. Been some years since I did any Joomla Dev work.
From what I can see, It instantiates a new instance using the table class...
Where it calls table/table.php getInstance()
This passes the data to the Joomla getInstance() method in libraries/src/Table/Table.php > getInstance()
This checks if a database object has been passed and uses this to create a new instance of the table class which it returns to the post object
The next thing it does is to get the post data.... (also in post/post.php)
The full toPostData() method...
Note that here it is initialising a bunch of properties under the guise of 'Joomla 4 compatibility'.
This seems like the opportune place to address this issue. IMHO.
If the status / value of the document column is the cause of the error, then we should be able to assign a default value here so that it then does not cause the failure of the later post->store method.
So I propose a small change as follows....
We can add the document column property to the list of J4 compatibility 'fixes'. Like this....
Of course, I have no way to test this, and I am unsure if assigning an empty value will resolve the issue instead of changing it to 'NULL'. So we may need to play with it a little to get it to work.
If someone wants to test this out for me, would be keen to see if it is a viable fix
Just trying to get my head around the code flow. Been some years since I did any Joomla Dev work.
From what I can see, It instantiates a new instance using the table class...
// If this a new post, instantiate a new post table.
if (!$this->post) {
$this->post = EB::table('Post');
}
Where it calls table/table.php getInstance()
This passes the data to the Joomla getInstance() method in libraries/src/Table/Table.php > getInstance()
This checks if a database object has been passed and uses this to create a new instance of the table class which it returns to the post object
The next thing it does is to get the post data.... (also in post/post.php)
// Get post data
$data = $this->toPostData();
The full toPostData() method...
public function toPostData()
{
$data = new stdClass();
foreach (self::$enumerations as $prop => $enum) {
// If this is a linked property, skip.
// Linked property are not part of post table.
if ($enum['linked']) {
continue;
}
// Joomla 4 compatibility:
// To Ensure id column type is integer
if ($prop == 'isnew') {
$this->$prop = (int) $this->$prop;
}
// Joomla 4 compatibility:
// To Ensure state column should have a default value
if ($prop == 'state' && empty($this->$prop)) {
$this->$prop = EASYBLOG_POST_NORMAL;
}
if ($prop == 'locked' && empty($this->$prop)) {
$this->$prop = 0;
}
if ($prop == 'content' && empty($this->$prop)) {
$this->$prop = '';
}
if ($prop == 'intro' && empty($this->$prop)) {
$this->$prop = '';
}
$data->$prop = $this->$prop;
}
return $data;
}
Note that here it is initialising a bunch of properties under the guise of 'Joomla 4 compatibility'.
This seems like the opportune place to address this issue. IMHO.
If the status / value of the document column is the cause of the error, then we should be able to assign a default value here so that it then does not cause the failure of the later post->store method.
So I propose a small change as follows....
// J5.2.4 Update fix (J!User)
if ($prop == 'document' && empty($this->$prop)){
$this->$prop = '';
}
We can add the document column property to the list of J4 compatibility 'fixes'. Like this....
public function toPostData()
{
$data = new stdClass();
foreach (self::$enumerations as $prop => $enum) {
// If this is a linked property, skip.
// Linked property are not part of post table.
if ($enum['linked']) {
continue;
}
// Joomla 4 compatibility:
// To Ensure id column type is integer
if ($prop == 'isnew') {
$this->$prop = (int) $this->$prop;
}
// Joomla 4 compatibility:
// To Ensure state column should have a default value
if ($prop == 'state' && empty($this->$prop)) {
$this->$prop = EASYBLOG_POST_NORMAL;
}
if ($prop == 'locked' && empty($this->$prop)) {
$this->$prop = 0;
}
if ($prop == 'content' && empty($this->$prop)) {
$this->$prop = '';
}
if ($prop == 'intro' && empty($this->$prop)) {
$this->$prop = '';
}
// J5.2.4 Update fix (J!User)
if ($prop == 'document' && empty($this->$prop)){
$this->$prop = '';
}
$data->$prop = $this->$prop;
}
return $data;
}
Of course, I have no way to test this, and I am unsure if assigning an empty value will resolve the issue instead of changing it to 'NULL'. So we may need to play with it a little to get it to work.
If someone wants to test this out for me, would be keen to see if it is a viable fix
Modified file attached
Replace the following file...
If anyone can let me know if this fixes the error, that'd be great
Replace the following file...
administrator/components/com_easyblog/includes/post/post.php
If anyone can let me know if this fixes the error, that'd be great
Attachments (1)
- Page :
- 1
- 2
There are no replies made for this post yet.