We are preparing November release which will include improvements regarding UI config loading.
I think itâll be better to wait for the release packages. Thanks for your patience.
I have re-installed up with the latest package updates and the method to truncate and re-install as above.
My installation now just present the following errors in console and also lists no entries even though demo data is present in the backend UI. Similar I think to what tornmarketing describes.
Failed to load resource: the server responded with a status of 404 (Not Found)
Only thing of note is I have the backend in a subdirectory and SpiceUI in the index directory. Any reason this isnât the recommended method as it would seem the most logical for most users to access the SpiceUI Interface directly from the top level domain?
I donwloaded latest master packages.
My Architecture:
spicecrm/[frontend files]
spicecrm/backend/[backend file]
I installed backend. Did Repair/rebuild after installation.
I pulled UI Config (ONLY CORE !), UI Languages , SpiceBeanGuides and FTS defaults.
Then I called the frontend: install screen of UI came up, I populated the fields, saved and was redirected to login screen.
I logged in: no error messages in console in UI.
Still a problem:
I noticed that FTS Setup in Frontend doesnât work properly.
Only FTS Manager in backend works properly. I clicked put mapping for Accounts then index.
No listview in Frontend just like Jake
I could see in my index (spicecore is my prefix) http://localhost:9200/spicecoreaccounts/_search
total of 50 accounts are indexed.
Still they are not displayed in listview in frontend. elastic search throws following error: no mapping found for[name.raw] in order to sort on.
sort flag is set in FTS setup, I assume there is a problem in the mapping generation.
It will be analyzed and hopefully fixed for January release.
Unfortunately indexed search is necessary to use UI.
I just committed a hotfix for FTS in master branch. Wrong config was loaded.
Fix committed to file modules/Administration/FTSDefault.php
Download and overwrite.
Then Go to backend Administration FTS default and load current config.
Then index your records. Start with module Accounts using backend Administration FTS Manager. Select Accounts and click âindexâ. It will index accounts. If you loaded demo data during installation, you shall have 50 entries.
I followed the above but havenât seen any changes in either backend or UI.
I still get the error related to â/prism/KREST/territoriesâ 404. Have you seen this error maretval?
I also have â/prism/KREST/module/Dashboards/1â showing 404 in console
I am not certain FTS is working correctly with ElasticSearch. I have following the documentation, ElasticSearch is running. Can you clarify what should be set as the FTS prefix? I have the following details when I curl âlocalhost:9200â:
I am hoping to get both backend and UI working, although I have other solutions working well, spice with the UI frontend still seems to be the best⌠almost there, it seems a shame to have these small errors. Roughly when will the January release be?
Jake,
FTS works with elasticsearch (5.x -6.x supported, version 6 recommanded)
If you didnât fill in elastic search variables during backend installation then add following set to your config.php
Adapt the value for server and port if needed
âftsâ =>
array (
âserverâ => âlocalhostâ,
âportâ => â9200â,
âprefixâ => âspicecrmâ,
âloglevelâ => â0â,
âschedulerpackagesizeâ => 25000,
),
Make sure you downloaded the master branch packages
I have successfully got some data populating in UI, demo contact data seems to work mainly and account records setup in UI. I will do some digging with elastic and ensure itâs running reliably and spice is able to index correctly.
I still have the error related to /territories module.
Also, in order to get KREST working I still have to perform the code edit here when updating from master package:
No, this function is native in all our installations.
But thanks for reading community threads and for reminding me.
I thought we had this code already somewhere in KREST but apparently not. I will see that it gets integrated.
No problem. I am able to see records in UI now, I will tweak the server to make sure elasticsearch is running more efficiently (it fails periodically at the moment).
May be having a similar issue. I am seeing this in my apache error log when I try and load UI_config:
Wed Jan 2 23:44:03 2019 [31561][-none-][FATAL] json_decode error on REST response from reference server. Response: <html><head><title>Slim Application Error</title><style>body{margin:0;padding:30px;font:12px/1.5 Helvetica,Arial,Verdana,sans-serif;}h1{margin:0;font-size:48px;font-weight:normal;line-height:48px;}strong{display:inline-block;width:65px;}</style></head><body><h1>Slim Application Error</h1><p>The application could not run because of the following error:</p><h2>Details</h2><div><strong>Type:</strong> ErrorException</div><div><strong>Code:</strong> 8</div><div><strong>Message:</strong> Undefined index: package_type</div><div><strong>File:</strong> /var/www/spicecrm_package_proxy/PackageHandler/PackageHandler.php</div><div><strong>Line:</strong> 24</div><h2>Trace</h2><pre><div>#0 /var/www/spicecrm_package_proxy/PackageHandler/PackageHandler.php(24): Slim\Slim::handleErrors(8, âUndefined indexâŚâ, â/var/www/spicecâŚâ, 24, Array)</div><div>#1 /var/www/spicecrm_package_proxy/index.php(36): PackageHandler::getAvailable(true)</div><div>#2 [internal function]: {closure}()</div><div>#3 /var/www/spicecrm_package_proxy/Slim/Route.php(468): call_user_func_array(Object(Closure), Array)</div><div>#4 /var/www/spicecrm_package_proxy/Slim/Slim.php(1357): Slim\Route->dispatch()</div><div>#5 /var/www/spicecrm_package_proxy/Slim/Middleware/Flash.php(85): Slim\Slim->call()</div><div>#6 /var/www/spicecrm_package_proxy/Slim/Middleware/MethodOverride.php(92): Slim\Middleware\Flash->call()</div><div>#7 /var/www/spicecrm_package_proxy/Slim/CorsSlim.php(117): Slim\Middleware\MethodOverride->call()</div><div>#8 /var/www/spicecrm_package_proxy/Slim/Middleware/PrettyExceptions.php(67): CorsSlim\CorsSlim->call()</div><div>#9 /var/www/spicecrm_package_proxy/Slim/Slim.php(1302): Slim\Middleware\PrettyExceptions->call()</div><div>#10 /var/www/spicecrm_package_proxy/index.php(62): Slim\Slim->run()</div><div>#11 {main}</pre></body></html>. URL: https://packages.spicecrm.io/releaseconfig. Please check call parameters!
Wed Jan 2 23:44:03 2019 [31561][-none-][FATAL] Exception in Controller: REST Call error somewhere⌠Action aborted
I am also seeing lots of these in my apache error logs:
Wed Jan 2 23:45:02 2019 [31721][-none-][ERROR] Unable to load custom logic file: modules/SpiceACLTerritories/SpiceACLHooks.php
Wed Jan 2 23:45:02 2019 [31721][-none-][FATAL] Query Failed: SELECT id, deleted FROM WHERE (date_indexed IS NULL OR date_indexed = ââ OR date_indexed < date_modified) LIMIT 0,24993: MySQL error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near âWHERE (date_indexed IS NULL OR date_indexed = ââ OR date_indexed < date_modifiedâ at line 1
Wed Jan 2 23:45:02 2019 [31721][-none-][ERROR] Unable to load custom logic file: modules/SpiceACLTerritories/SpiceACLHooks.php
I got it working
There were three key issues resolved via the below but there are still issues with KREST not loading the tabular pages such as opportunities, reports etc. Able to get the list not the tabular layouts
Territories and Dashboards module is missing from KREST
There is still the contact Component PiplContainer Missing
The directory being read in this case,â./modules/Schedulers/ScheduledTasksâ, does not exist in the code base. On linux environment the code was getting stuck in the loop. Removal of this while allowed the indexing in elasticsearch to work due to which records are now visible on the list view.
The statement is checking is $GLOBALS[âinstallingâ] is true, when the code is not installing the CRM this value is not even set so we first need to check if the value is even set. This was causing error logs to fill in needlessly.
The same issue is repeated here.
The installation was simple, in order to get the indexing to work smoothly you needed to trigger Repair & Rebuild, configure FTS, configure UI language and configure UI settings. Even right now there are a couple of issues that are persisting on the UI
Dashboard not loading
territories are accessed in the UI but are not available in the KREST installed.
