Magento Page Builder - 500 Internal Server error - magento2

I just wanted to add a Slider block in my Magento 2.4.4 build in Pagebuilder and I'm getting an 500 Internal Server error when I click on Edit. I have this problem also with the Image block.
I have this in my browser console:
https://example.com/admin/mui/index/render_handle/buttons/1/key/3d12a8a6a2372ed459fc9684018ea6fbb954bd41478fe44d9f2e969ed409a639/?namespace=pagebuilder_slide_form&handle=pagebuilder_slide_form&isAjax=true
[HTTP/1.1 500 Internal Server Error 887ms]
Do you know where I can start to search where this is comming from?
The debug.log and system.log says:
magento main.ERROR: The requested store cannot be found.

I found the solution folowing the steps from Silas Palmer found here: https://magento.stackexchange.com/questions/156176/magento-2-requested-store-is-not-found?newreg=9ac715264c1949e69c8b1a78c0100133
That makes the error code more clear.
In my case it says:
main.ERROR: The store ID (3) that was requested wasn't found. Verify the store and try again.
So I crated a new store view and it works now.
Here is what I did:
This generally happens whenever config.php and the database get out of sync. For example, whenever I import a database back to my local development environment.
Here were the steps I used to troubleshoot and fix this.
Make the error messages more helpful:
Change vendor/magento/module-store/Model/StoreRepository.php to this (on your local, temporarily)
// Around line 74
if ($store->getId() === null) {
// Add this to see a backtrace
// debug_print_backtrace();
// Add this to see the store code causing the issue: (code:{$code})
throw new NoSuchEntityException(
__("The store (code:{$code}) that was requested wasn't found. Verify the store and try again.")
);
}
// .......
// Around line 114, same kind of thing...
if ($store->getId() === null) {
// debug_print_backtrace();
throw new NoSuchEntityException(
__("The store ID ({$id}) that was requested wasn't found. Verify the store and try again.")
);
}
Run php bin/magento s:up and make a note of the store id and/or store codes that are causing the issues. If you have added the backtrace, that will spool variables forever and you might need to do something like this instead: php bin/magento s:up > output.txt (wait 3 minutes, press ctrl-d to kill it) less output.txt
Go through app/etc/config.php and make sure all the stores line up with whatever is in the store table in the database. Note the store id from step 1, that will give you clues where to look. If there are differences, change config.php and not the database.
Run this against the database:
Change scope_id value (99) to whatever store_id you got in step #1
DELETE FROM core_config_data WHERE scope_id = 99
Change like value ('%xx_en%') to whatever store code you got in step #1
DELETE from flag where flag_data like '%xx_en%'
Run php bin/magento s:up again, hopefully there are no errors this time. Otherwise you may have to repeat some steps.

Related

mysqli_query($conn, $sql) On adding this, giving an error of 500 INTERNAL SERVER ERROR, No detailed error shown [duplicate]

In my local/development environment, the MySQLi query is performing OK. However, when I upload it on my web host environment, I get this error:
Fatal error: Call to a member function bind_param() on a non-object in...
Here is the code:
global $mysqli;
$stmt = $mysqli->prepare("SELECT id, description FROM tbl_page_answer_category WHERE cur_own_id = ?");
$stmt->bind_param('i', $cur_id);
$stmt->execute();
$stmt->bind_result($uid, $desc);
To check my query, I tried to execute the query via control panel phpMyAdmin and the result is OK.
TL;DR
Always have mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT); in your mysqli connection code and always check the PHP errors.
Always replace every PHP variable in the SQL query with a question mark, and execute the query using prepared statement. It will help to avoid syntax errors of all sorts.
Explanation
Sometimes your MySQLi code produces an error like mysqli_fetch_assoc() expects parameter 1 to be mysqli_result, boolean given..., Call to a member function bind_param()... or similar. Or even without any error, but the query doesn't work all the same. It means that your query failed to execute.
Every time a query fails, MySQL has an error message that explains the reason. In the older PHP versions such errors weren't transferred to PHP, and all you'd get is a cryptic error message mentioned above. Hence it is very important to configure PHP and MySQLi to report MySQL errors to you. And once you get the error message, fixing it will be a piece of cake.
How to get the error message in MySQLi
First of all, always have this line before MySQLi connect in all your environments:
mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
After that, all MySQL errors will be transferred into PHP exceptions. An uncaught exception, in turn, makes a PHP fatal error. Thus, in case of a MySQL error, you'll get a conventional PHP error. That will instantly make you aware of the error cause. And the stack trace will lead you to the exact spot where the error occurred.
How to get the error message from PHP
Here is a gist of my article on PHP error reporting:
Reporting errors on a development and live servers must be different. On the development server it is convenient to have errors shown on-screen, but on a live server error messages must be logged instead, so you could find them in the error log later.
Therefore, you must set corresponding configuration options to the following values:
On a development server
error_reporting should be set to E_ALL value;
log_errors should be set to 1 (it is convenient to have logs on a development PC too)
display_errors should be set to 1
On a production server
error_reporting should be set to E_ALL value;
log_errors should be set to 1
display_errors should be set to 0
After that, when MySQL query fails, you will get a PHP error that explains the reason. On a live server, in order to get the error message, you'll have to check the error log.
In case of AJAX call, on a dev server open DevTools (F12), then Network tab. Then initiate the request which result you want to see, and it will appear in the Network tab. Click on it and then the Response tab. There you will see the exact output. On a live server check the error log.
How to actually use it
Just remove any code that checks for the error manually, all those or die(), if ($result), try..catch and such. Simply write your database interaction code right away:
$stmt = $this->con->prepare("INSERT INTO table(name, quantity) VALUES (?,?)");
$stmt->bind_param("si", $name, $quantity);
$stmt->execute();
Again, without any conditions around. If an error occurs, it will be treated like any other error in your code. For example, on a development PC it will just appear on-screen, while on a live site it will be logged for the programmer, whereas for the user's convenience you could use an error handler (but that's a different story which is off topic for MySQLi, but you may read about it in the article linked above).
What to do with the error message you get
First of all you have to locate the problem query. The error message contains the file name and the line number of the exact spot where the error occurred. For the simple code that's enough, but if your code is using functions or classes you may need to follow the stack trace to locate the problem query.
After getting the error message, you have to read and comprehend it. It sounds too obvious if not condescending, but learners often overlook the fact that the error message is not just an alarm signal, but it actually contains a detailed explanation of the problem. And all you need is to read the error message and fix the issue.
Say, if it says that a particular table doesn't exist, you have to check spelling, typos, and letter case. Also you have to make sure that your PHP script connects to a correct database
Or, if it says there is an error in the SQL syntax, then you have to examine your SQL. And the problem spot is right before the query part cited in the error message.
If you don't understand the error message, try to google it. And when browsing the results, stick to answers that explain the error rather than bluntly give the solution. A solution may not work in your particular case, but the explanation will help you to understand the problem and make you able to fix the issue by yourself.
You have to also trust the error message. If it says that number of tokens doesn't match the number of bound variables then it is so. The same goes for the absent tables or columns. Given the choice, whether it's your own mistake or the error message is wrong, always stick to the former. Again it sounds condescending, but hundreds of questions on this very site prove this advise extremely useful.
A list of things you should never ever do in regard of error reporting
Never use an error suppression operator (#)! It makes a programmer unable read the error message and therefore unable to fix the error
Do not use die() or echo or any other function to print the error message on the screen unconditionally. PHP can report errors by itself and do it the right way depends on the environment - so just leave it for PHP.
Do not add a condition to test the query result manually (like if($result)). With error exceptions enabled such condition will just be useless.
Do not use the try..catch operator for echoing the error message. This operator should be used to perform some error handling, like a transaction rollback. But never use it just to report errors - as we learned above, PHP can already do it, the right way.
P.S.
Sometimes there is no error, but no results either. Then it means, there is no data in the database to match your criteria. In this case you have to admit this fact, even if you can swear the data and the criteria are all right. They are not. You have to check them again.
I've got an article that can help in this matter, How to debug database interactions. Although it is written for PDO, the principle is the same. Just follow those instructions step by step and either have your problem solved or have an answerable question for Stack Overflow.

Not a valid identifier 'index,index.html' AEM 6.2

I get that error after deploying my project. Does anyone know how to fix it?
This appears in http://localhost:4502/ so, the damadmin, crx/de, system/console/* works good.
Complete error:
Not a valid identifier 'index,index.html'
Cannot serve request to / in org.apache.sling.servlets.get.DefaultGetServlet
Exception:
java.lang.IllegalArgumentException: Not a valid identifier 'index,index.html'
This is a typical issue where people have misconfigured the Index Resources section of the Apache Sling GET Servlet.
Visit /system/console/configMgr/org.apache.sling.servlets.get.DefaultGetServlet
Look at the Index Resources field.
If you have it like [ "index","index.html" ] then you've set it up wrong and will get this error in your error log
Instead they should be separate entries one above the other.
So make the first entry "index"
Then hit the plus sign on the right and add "index.html" as the next entry and hit save at the bottom.
People read the text below the configuration element too literally. It says "The default value is [ "index", "index.html" ]". So instead of reading that as a multi-value field with index and index.html as two values. They simply copy and paste it into the field and save. This creates that issue you've described.
Please please please do not do what e-israel suggests and delete your AEM installation by deleting the crx-quickstart folder. This is like formatting your drive or the linux equivalent of an rm -rf on your application directory. Terrifying suggestion and wanted to mention it for any poor person who dared follow it.

Jboss server hangs when it try to obtain a connection from HypersonicDB data source

I know cleaning cache will work because tables are cached. But a certain line in my script causing problems here is the content. Please help me understand the line highlighted in bold.
// create table
CREATE CACHED TABLE JMS_MESSAGES(MESSAGEID INTEGER NOT NULL,DESTINATION VARCHAR(255) NOT NULL,TXID INTEGER,TXOP CHAR(1),MESSAGEBLOB OBJECT,PRIMARY KEY(MESSAGEID,DESTINATION))
// create indexes
CREATE INDEX JMS_MESSAGES_TXOP_TXID ON JMS_MESSAGES(TXOP,TXID)
CREATE INDEX JMS_MESSAGES_DESTINATION ON JMS_MESSAGES(DESTINATION)
// what is it doing? because this line makes it hang
SET TABLE JMS_MESSAGES INDEX'3883576 3883576 3883576 0'
Please let me know what this line does so I can debug this script. On production we are using Jboss 4.0.4 and don't often clear tmp/work often and reboot system every Sunday.
Simply delete the line reported in bold and save the .script file with no other change.
The purpose of the line is to link to the data in the .data file. As this is a message cache that is no longer valid, there should be no data there.

What do I do when MorphX won't let me check in?

When I go to check something into MorphX VCS right now, I get the following message:
Cannot create a record in SysVersionControlMorphXRevisionTable (SysVersionControlMorphXRevisionTable).
The record already exists.
With things that have already been checked out once, I've been able to resolve this with a get latest and then a new checkout/check in. However, when it comes to doing an Add, I'm completely stuck. Is there a resolution to this or have we completely borked our VCS?
Note: this error is only given when we try to check in from a development project. Checking in directly on the AOT does not give this issue.
Just look at the table SysVersionControlMorphXRevisionTable (in SQL if you can't access) and see what the duplicate record could be. The unique index is ItemPath and Version. I doubt you'll see anything here though.
It's most likely an issue with the call in this method \Data Dictionary\Tables\SysVersionControlMorphXRevisionTable\Methods\latestVersionNumber where it's trying to get the current highest revision and is being called by \Data Dictionary\Tables\SysVersionControlMorphXRevisionTable\Methods\create.
Put a breakpoint in the create method line #48 and see what revision.Version is, and before the insert, check in SQL if the ItemPath/Version already exists in SQL.
I'd guess it's probably a server/client-caching issue. To resolve, refresh all of your client caches under Tools>Caches. If this doesn't resolve, and it's a good idea to do anyway, copy these menu items:
\Menu Items\Action\SysFlushAOD
\Menu Items\Action\SysFlushData
\Menu Items\Action\SysFlushDictionary
\Menu Items\Action\SysFlushReportServer
To a new menu item and change the property RunOn = Server. Then run these and it'll flush your server caches. If this still doesn't work, try restarting the AOS.
If this doesn't work, your users application user cache files might be corrupt. Close your client and delete the *.auc and *.kti files in %LocalAppData% folder (Typically C:\Users\[user]\AppData\Local) and reopen your client.
In the environment you are using, have you restored a copy of another database somewhat recently?
Edit: Now knowing that you did a DB restore, there is a good chance your GLOBALGUID was reused and/or is causing caching issues. See here for more info about how/why this happens.
You should probably stop your AOS and run these SQL commands:
UPDATE SYSSQMSETTINGS SET GLOBALGUID = '00000000-0000-0000-0000-000000000000'
DELETE FROM SYSCLIENTSESSIONS
DELETE FROM SYSSERVERSESSIONS
Are/were you also having issues with batches running? (Somewhat related, but I'm mainly just curious on this question)

Joomla template parameters and params.ini - file becomes unwritable after save

I am using wamp on Win XP SP3 and creating a Joomla template with changeable parameters.
initially the message is
The parameter file \templates\ssc_2010\params.ini is
writable!
once I make changes everything works as expected, except now i get the message:
The parameter file \templates\ssc_2010\params.ini is
unwritable!
One solution is to brows to the directory, right click the file, select properties, and uncheck read-only. Again the file is writable but once I modify the parameters again it becomes read only again. I'm quite lazy and would like to prevent this from happening again, I've notice this happening in past projects, but now I have to work a lot with parameters so it becomes quite boring doing manual labor like that :P
There is a bug in Joomla 1.5 that causes the message to be displayed.
A security feature was added that makes the template files unwritable until just before save, where they are made writable, saved, then made unwritable again.
Try to make a change, then go back and check the preview. You will see that the change was actually made.
If you want to fix the annoying unwritable message, add the following code to
administrator/components/controller.php around line 179, just after setting the FTP credentials:
$file = $client->path.DS.'templates'.DS.$template.DS.'params.ini';
// Try to make the params file writeable
if (!$ftp['enabled'] && JPath::isOwner($file) && !JPath::setPermissions($file, '0755')) {
JError::raiseNotice('SOME_ERROR_CODE', JText::_('Could not make the template parameter file writable'));
}
This will make the file writable during the edit load process, and before the file's status is posted in the template.
Then for security, in case the edit screen is closed without saving, search for the following lines:
require_once (JPATH_COMPONENT.DS.'admin.templates.html.php');
TemplatesView::editTemplate($row, $lists, $params, $option, $client, $ftp, $template);
and paste the following code just AFTER these lines but before the closing brace:
// Try to make the params file unwriteable
if (!$ftp['enabled'] && JPath::isOwner($file) && !JPath::setPermissions($file, '0555')) {
JError::raiseNotice('SOME_ERROR_CODE', JText::_('Could not make the template parameter file unwritable'));
}
That will make the file unwritable again.
This is the same code that is used in the saveTemplate() function. We are just doing it again before we display the status of the file on the edit screen. If the process fails because of your web server's configuration, you will get warning messages, BEFORE you've made a bunch of changes to your template. :)
P.S. Remember to save a copy of this file separately, so that you can redo the changes when you upgrade Joomla! (if they haven't fixed this themselves yet.)
This sounds like a user rights problem within Windows - have a look a the security permissions for the directory in which the file you are editing is located, and check that the user "IUSR_xxx" (where xxx is the name of your computer) has full control.
If this doesn't work, then can you tell us what version of Windows you are running as this may help...
Matt