The egw_LAB.wait(function() doesn’t seem to work, all egw_js files are still loaded after my custom js file.
I still get the same errors in the console.
I tried the other possibility you mentioned as per the standard, created an app.js file and placed the following code inside.
app.classes.myapp = AppJS.extend(
{
appname: 'myapp',
/**
* Initialize javascript for this application
*
* @memberOf myapp
*/
init: function() {
console.log("app test my cutom app");
egw.calendar(jQuery('#input-datepicker'), false, function(v){});
},
});
But I couldn’t see the app.js loaded in the network tab, is there any any other code that needs to be added in the app.js file for it to be picked up ?
I modified our example app branch step1
as an example for you:
cd /path/to/egroupware
git clone -b step1
patch -p1 -d example <<EOF
diff --git a/js/app.js b/js/app.js
new file mode 100644
index 0000000..ad7835a
--- /dev/null
+++ b/js/app.js
@@ -0,0 +1,9 @@
+/*egw:uses
+ /vendor/bower-asset/jquery/dist/jquery.js;
+ /vendor/bower-asset/jquery-ui/jquery-ui.js;
+*/
+egw_LAB.wait(function() {
+ jQuery(function () {
+ egw.calendar(jQuery('#input-datepicker'), false, function(v){});
+ });
+});
diff --git a/src/Ui.php b/src/Ui.php
index 92087e7..560a81e 100644
--- a/src/Ui.php
+++ b/src/Ui.php
@@ -12,6 +12,8 @@
namespace EGroupware\Example;
+use EGroupware\Api\Framework;
+
class Ui
{
/**
@@ -30,6 +32,9 @@ class Ui
*/
public function index(array $content=null)
{
+ Framework::includeJS('/example/js/app.js');
+ echo $GLOBALS['egw']->framework->header();
echo "Hello World :)";
+ echo "<p><input type='text' id='input-datepicker' value=''/></p>\n";
}
}
EOF
The loading works, but jQuery still throws that TypeError.
As far as I can tell that’s a problem/bug in jQuery
Ralf
Thanks for the insight Ralf
This worked for me, just using simple datepicker, no wait function and egw calendar. So there is something up with egw calendar initialization
// egw_LAB.wait(function() {
jQuery(function () {
// egw.calendar(jQuery('#input-datepicker'), false, function(v){});
jQuery( "#input-datepicker" ).datepicker();
});
// });
Hi Ralf.
I finished removing the deprecated code for latest upgrade version 20.1 on my local server.
However after starting the upgrade on production server, I ran into the same access log errors.
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: # Instance=default, User=vish, Request=POST https://project.qa.com:8081/egroupware/json.php?menuaction=home.jdots_framework.ajax_exec.t>
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: PHP Warning: Creating default object from empty value in /home/www.project.com/public_html/egroupware/api/src/Db.php on line 510
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: #1 /home/www.project.com/public_html/egroupware/api/src/Db.php(344): EGroupware\Api\Db->_connect()
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: #2 /home/www.project.com/public_html/egroupware/api/src/Db.php(604): EGroupware\Api\Db->connect()
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: #3 [internal function]: EGroupware\Api\Db->__wakeup()
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: #4 /home/www.project.com/public_html/egroupware/api/src/loader.php(79): unserialize()
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: #5 /home/www.project.com/public_html/egroupware/header.inc.php(92): require_once('/home/www.temps...')
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: #6 /home/www.project.com/public_html/egroupware/json.php(110): include_once('/home/www.temps...')
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: #7 {main}
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: # Instance=default, User=vish, Request=GET https://project.qa.com:8081/egroupware/json.php?menuaction=EGroupware\Api\Framework::ajax_ge>
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: PHP Warning: Creating default object from empty value in /home/www.project.com/public_html/egroupware/api/src/Db.php on line 510
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: #1 /home/www.project.com/public_html/egroupware/api/src/Db.php(344): EGroupware\Api\Db->_connect()
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: #2 /home/www.project.com/public_html/egroupware/api/src/Db.php(604): EGroupware\Api\Db->connect()
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: #3 [internal function]: EGroupware\Api\Db->__wakeup()
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: #4 /home/www.project.com/public_html/egroupware/api/src/loader.php(79): unserialize()
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: #5 /home/www.project.com/public_html/egroupware/header.inc.php(92): require_once('/home/www.project...')
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: #6 /home/www.project.com/public_html/egroupware/json.php(110): include_once('/home/www.project...')
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: #7 {main}
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: # Instance=default, User=vish, Request=POST https://project.qa.com:8081/egroupware/json.php?menuaction=status.jdots_framework.ajax_exec>
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: Database error (EGroupware\Api\Db\Exception\InvalidSql): Invalid SQL: UPDATE egw_access_log SET WHERE
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'WHERE' at>
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: #0 /home/www.project.com/public_html/egroupware/api/src/Db/Deprecated.php(64): EGroupware\Api\Db->query()
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: #1 /home/www.project.com/public_html/egroupware/api/src/Db.php(1980): EGroupware\Api\Db\Deprecated->query()
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: #2 /home/www.project.com/public_html/egroupware/api/src/Session.php(1893): EGroupware\Api\Db->update()
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: #3 /home/www.project.com/public_html/egroupware/api/src/Session.php(1315): EGroupware\Api\Session->update_dla()
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: #4 /home/www.project.com/public_html/egroupware/api/src/Egw.php(304): EGroupware\Api\Session->verify()
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: #5 /home/www.project.com/public_html/egroupware/api/src/Egw.php(259): EGroupware\Api\Egw->verify_session()
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: #6 /home/www.project.com/public_html/egroupware/api/src/loader.php(83): EGroupware\Api\Egw->wakeup2()
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: #7 /home/www.project.com/public_html/egroupware/header.inc.php(92): require_once('/home/www.project...')
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: #8 /home/www.project.com/public_html/egroupware/json.php(110): include_once('/home/www.project...')
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: #9 {main}
2020-07-29 08:48:17: (mod_fastcgi.c.421) FastCGI-stderr: # Instance=default, User=vish, Request=POST https://project.qa.com:8081/egroupware/json.php?menuaction=status.jdots_framework.ajax_exec>
Production Server Details:
DB Server: MariaDB Server
Version: 10.1.34-MariaDB
PHP 7.4
Maria db is used
Lighttpd server is used
Local server details:
Mysql
PHP 7.2
Apache is used.
The upgrade was successful on the local server, I compared the schema setup file which is identical. Not sure what part of code is causing the values of the update access log query empty.
Please help
After doing some debugging, I found that not all update queries fail for the access log.It fails at some point when accessing the default app page. I set the default app page to filemanager and this is the sequence of logs
UPDATE egw_access_log SET session_dla=1596116842,session_action=’/api/categories.php’,lo=NULL WHERE sessionid=4289950
UPDATE egw_access_log SET session_dla=1596116842,session_action=’/api/config.php’,lo=NULL WHERE sessionid=4289950
UPDATE egw_access_log SET session_dla=1596116842,session_action=’/api/images.php’,lo=NULL WHERE sessionid=4289950
UPDATE egw_access_log SET session_dla=1596116842,session_action=’/api/user.php’,lo=NULL WHERE sessionid=4289950
Instance=default, User=vish, Request=POST https://project.com/egroupware/json.php?menuaction=filemanager.jdots_framework.ajax
When this request is issued, the query fails, the table definition array returns empty and thus no arguments in the query are passed
UPDATE egw_access_log SET WHERE
UPDATE egw_access_log SET session_dla=1596116843,session_action=’/api/lang.php’,lo=NULL WHERE sessionid=4289950
UPDATE egw_access_log SET session_dla=1596116877,session_action=’/index.php’,lo=NULL WHERE sessionid=4289950
An error happened! (EGroupware\Api\Exception\AssertionFailed): CreateObject() file /home/www.tempstop.com/public_html/egroupware/api/inc/class…in
Not sure what the error corresponds here
UPDATE egw_access_log SET session_dla=1596116877,session_action=’/index.php’,lo=NULL WHERE sessionid=4289950
Instance=default, User=vish, Request=POST https://project.com/egroupware/json.php?menuaction=filemanager.jdots_framework.ajax>
UPDATE egw_access_log SET WHERE.
Please advice. I cleared the cache from the Clear Cache and register hooks option in the setup and even restarted the server. Also I’m using an incognito window
I was removing the deprecated code in my custom application on my local server. After doing the upgrade on production I moved the modified class files of the application. I have also restarted the upgrade several times to get rid of the errors, but nothing changes.
I’m doing through composer with the following steps
- composer create-project --prefer-source --keep-vcs egroupware/egroupware
- Copy the custom application in egroupware folder
- Copy the header file in egroupware
- Run the db migrations to upgrade
I was using 17.1 version before and with the composer command I got upgraded to the latest version 20.1 which turned out well on my local server which was used for testing but not on production
I don’t understand the question.
Do you want to comment out the access log update?
The code is the following:
The top 2 arrays are the SET and the lower one is the WHERE. How they can be empty is a mystery of your installation, unless you call set_app() on the global DB object, that would produce something like that.
Ralf