vmo
Members-
Posts
37 -
Joined
-
Last visited
Recent Profile Visitors
1,568 profile views
vmo's Achievements
Jr. Member (3/6)
14
Reputation
-
#1214 - The used table type doesn't support FULLTEXT indexes
vmo replied to vmo's topic in General Support
Thank you for your replies you are right @dragan I do not have enough rights to manipulate the DB so nothing better do take a peek into the core and see what I could do and this is what I did to temporary fix the issue: /** * Get all fulltext stopwords for database engine * * @param string $engine Specify DB engine of "myisam" or "innodb" or omit for current DB engine * @param bool $flip Return flipped array where stopwords are array keys rather than values? for isset() use (default=false) * @return array * */ public function getStopwords($engine = '', $flip = false) { $engine = $engine === '' ? $this->engine : strtolower($engine); // ORIGINAL // if($engine === 'myisam') return DatabaseStopwords::getAll(); // TEMP FIX 20201015: FOR MySQL 5.5 without INNODB_FT_DEFAULT_STOPWORD /* SQL query: ALTER TABLE `fieldtype_options` ADD FULLTEXT KEY `title_value` (`title`,`value`) MySQL said: Documentation #1214 - The used table type doesn't support FULLTEXT indexes AFTER RUNNING THE FOLLOWING COMMAND FOR EACH TABLE ALTER TABLE <table name> ENGINE = MYISAM */ // Will always return the DatabaseStopwords::getAll(); return DatabaseStopwords::getAll(); if($this->stopwordCache === null) { // && $engine === 'innodb') { $cache = $this->wire()->cache; $stopwords = null; if($cache) { $stopwords = $cache->get('InnoDB.stopwords'); if($stopwords) $stopwords = explode(',', $stopwords); } if(!$stopwords) { $query = $this->prepare('SELECT value FROM INFORMATION_SCHEMA.INNODB_FT_DEFAULT_STOPWORD'); $query->execute(); $stopwords = $query->fetchAll(\PDO::FETCH_COLUMN, 0); $query->closeCursor(); if($cache) $cache->save('InnoDB.stopwords', implode(',', $stopwords), WireCache::expireDaily); } $this->stopwordCache = array_flip($stopwords); } return $flip ? $this->stopwordCache : array_keys($this->stopwordCache); } Now I have other issue but it will be "simpler" to fix (I hope) - The stop words array returned by the "DatabaseStopwords::getAll();" are only in english and since the site is multi language I need to find a way to get the current user language and change the "DatabaseStopwords::getAll();" to return the stop words in the language that the user has selected. Right now is what I could do to put the search by text to work. I will look further into this and see what I can do in a better way since the client's server will not be updated for while and normally it means never! Thank you -
#1214 - The used table type doesn't support FULLTEXT indexes
vmo replied to vmo's topic in General Support
I might missed the question, thank you. Is there a way to search text in fields without using the table "INNODB_FT_DEFAULT_STOPWORD"? or in the mean while implementing a work around maybe with a hook implementation to be able to search text in fields and not have this issue? Thank you -
Hi, I am having an issue while migrating a site from the development server to the live server. On the dev server we have the mysql 5.6 and on the client live server we have the mysql 5.5. During the migration to the live server during the process of importing the exported SQL file we start to receive the following error: SQL query: ALTER TABLE `fieldtype_options` ADD FULLTEXT KEY `title_value` (`title`,`value`) MySQL said: Documentation #1214 - The used table type doesn't support FULLTEXT indexes After some research the solution was to run the following command on each table ALTER TABLE <table name> ENGINE = MYISAM So at the end of the SQL file we enter this command for each table and the SQL file was imported correctly without any error. It seams that everything was alright but while testing the search functionality on the frontend we are getting the following error: SQLSTATE[42S02]: Base table or view not found: 1109 Unknown table 'INNODB_FT_DEFAULT_STOPWORD' in information_schema (Full error on the attached image) Executing the query: SELECT * FROM INFORMATION_SCHEMA.TABLES the table "INNODB_FT_DEFAULT_STOPWORD" is not there. While questioning the server support I am not getting any answer how to fix this and i can't find any solution to fix this while using the mysql 5.5 or if it is a mysql 5.5 installation issue and the table should be there. As far as I can understand the table "INNODB_FT_DEFAULT_STOPWORD" is a internal mysql table and should exist on the "INFORMATION_SCHEMA", but I can be wrong about this. I could not find much information about this table on a mysql 5.5 server. Any ideia or solution (if any) I would be most appreciated. Thank you
-
this request was aborted because it appears to be forged
vmo replied to joshuag's topic in General Support
-
this request was aborted because it appears to be forged
vmo replied to joshuag's topic in General Support
After changing most of all files permissions to 777, on the admin while trying to save a page I got the same error: File: .../wire/core/SessionCSRF.php:191 181: * 182: * @param int|string|null $id Optional unique ID for this token 183: * @throws WireCSRFException if token not valid 184: * @return bool Always returns true or throws exception 185: * 186: */ 187: public function validate($id = '') { 188: if(!$this->config->protectCSRF) return true; 189: if($this->hasValidToken($id)) return true; 190: $this->resetToken(); 191: throw new WireCSRFException($this->_('This request was aborted because it appears to be forged.')); 192: } 193: 194: /** 195: * Clear out token value Any ideia? Thank you -
this request was aborted because it appears to be forged
vmo replied to joshuag's topic in General Support
Hi, while migrating a website to a staging server ant to put the site online today i got this error: ProcessWire: ProcessLogin: This request was aborted because it appears to be forged. DEBUG MODE ($config->debug == true): #0 /wire/modules/Inputfield/InputfieldForm.module(155): ProcessWire\SessionCSRF->validate() #1 /wire/core/Wire.php(397): ProcessWire\InputfieldForm->___processInput(Object(ProcessWire\WireInputData)) #2 /wire/core/WireHooks.php(823): ProcessWire\Wire->_callMethod('___processInput', Array) #3 /wire/core/Wire.php(465): ProcessWire\WireHooks->runHooks(Object(ProcessWire\InputfieldForm), 'processInput', Array) #4 /wire/modules/Process/ProcessLogin/ProcessLogin.module(362): ProcessWire\Wire->__call('processInput', Array) #5 /wire/core/Wire.php(394): ProcessWire\ProcessLogin->___execute() #6 /wire/core/WireHooks.php(823): ProcessWire\Wire->_callMethod('___execute', Array) #7 /wire/core/Wire.php(465): ProcessWire\WireHooks->runHooks(Object(ProcessWire\ProcessLogin), 'execute', Array) #8 /wire/core/ProcessController.php(337): ProcessWire\Wire->__call('execute', Array) #9 /wire/core/Wire.php(394): ProcessWire\ProcessController->___execute() #10 /wire/core/WireHooks.php(823): ProcessWire\Wire->_callMethod('___execute', Array) #11 /wire/core/Wire.php(465): ProcessWire\WireHooks->runHooks(Object(ProcessWire\ProcessController), 'execute', Array) #12 /wire/core/admin.php(153): ProcessWire\Wire->__call('execute', Array) #13 /wire/modules/AdminTheme/AdminThemeUikit/controller.php(15): require('/var/www/vhosts...') #14 /site/templates/admin.php(19): require('/var/www/vhosts...') #15 /wire/core/TemplateFile.php(318): require('/var/www/vhosts...') #16 /wire/core/Wire.php(394): ProcessWire\TemplateFile->___render() #17 /wire/core/WireHooks.php(823): ProcessWire\Wire->_callMethod('___render', Array) #18 /wire/core/Wire.php(465): ProcessWire\WireHooks->runHooks(Object(ProcessWire\TemplateFile), 'render', Array) #19 /wire/modules/PageRender.module(536): ProcessWire\Wire->__call('render', Array) #20 /wire/core/Wire.php(397): ProcessWire\PageRender->___renderPage(Object(ProcessWire\HookEvent)) #21 /wire/core/WireHooks.php(823): ProcessWire\Wire->_callMethod('___renderPage', Array) #22 /wire/core/Wire.php(465): ProcessWire\WireHooks->runHooks(Object(ProcessWire\PageRender), 'renderPage', Array) #23 /wire/core/WireHooks.php(924): ProcessWire\Wire->__call('renderPage', Array) #24 /wire/core/Wire.php(465): ProcessWire\WireHooks->runHooks(Object(ProcessWire\Page), 'render', Array) #25 /wire/modules/Process/ProcessPageView.module(213): ProcessWire\Wire->__call('render', Array) #26 /wire/core/Wire.php(397): ProcessWire\ProcessPageView->___execute(true) #27 /wire/core/WireHooks.php(823): ProcessWire\Wire->_callMethod('___execute', Array) #28 /wire/core/Wire.php(465): ProcessWire\WireHooks->runHooks(Object(ProcessWire\ProcessPageView), 'execute', Array) #29 /index.php(55): ProcessWire\Wire->__call('execute', Array) #30 {main} How can I identify the files and folders that I need to change the permissions from this? And what might be the permissions to change to? Thank you -
Change the order of the fields on a template programmatically
vmo replied to vmo's topic in API & Templates
It is exactly what I was looking for. Many thanks -
Hi, it is possible to change the order of the fields programmatically on a template? Thank you
-
Hi, I need to create a script to create a template and the template fields using data from a CSV file using the template and fields API: - The template will have more then 600 fields; - The fields are going to be organized using different FieldsetTabs fields; - There will be FieldsetTabs fileds inside FieldsetTabs. I saw some posts with examples how to create a template and fields using the API but looking to the API I can not figure out what is the correct order to do the steps to create the template and fields and how to organize them into FieldsetTab. What I understand but I am not sure: 1. Create a template 2. Create all FieldsetTabs 3. Create all needed fields 4. Create a Fieldgroup 5. Add all fields to the Fieldgroup 6. Add the Fieldgroup to the template There are any example how to create FieldsetTabs inside FieldsetTabs and fields inside that FieldsetTabs? Thank you
-
Thanks, that is really good to know, I will keep it disabled. Done for now. Will try to debug it asap. All the best
-
Hi @adrian - thank you for the hints to research the issue. I just disabled the "Fields Object" on the Request Info Panel > Panel sections and the issue of the 404 does not appear. I will take time to debug it but right now I need to put everything working for tomorrow and I will give feedback asap. Thank you, all the best
-
Hi @adrian - After disabled the "RequestInfo panel" on the frontend panels stop receiving the 404 errors and after disabled the "RequestInfo panel" on the backend panels the admin navigation and save is normal, does not delay. Any next steps? Thank you
-
Hi, @adrian - the installation is on a cpanel with Apache. The installation is a basic one with a few fields and templates (with no page) and with no modifications done to the original template files. I copied the installation with the issue to another sub-domain and did the following actions: - Disabled all extra site modules - Removed all the custom templates and fields - Only enabled the Tracy module in DEVELOPMENT mode (with no errors and 404 pages) - With the Tracy in DEVELOPMENT mode: I reenabled all the others extra site modules one by one and tested for any errors, delays or 404 pages - After reenabled all the modules no errors, delays or 404 pages were detected. - Recreated the custom templates - Recreated the custom fields After this actions there wasn't datect any issue, but... after added a repeater field to the "home" template the same issue appeared and started again to receive 404 pages and delayed page processing on the admin. I did the following steps to try understand if there was any issue on the repeater field: On the "home" template: - Removed the repeater field from the "home" template - After field was removed, No 404 errors were detected navigating the site - Added again the repeater field to the "home" template and the same issue started - Removed the field On the "basic-page" template: - Added the field to the "basic-page" template - After added the repeater field to the "basic-page" template, no 404 errors were detected navigating in the site Any ideia? I can make a zip of the installation and send it to you, if it helps.
-
Hi, in a new PW install after install the Tracy module and enable the "Development" mode I get strange responses from the site: - On the frontend after clicking on a link the site stays processing and after a while gives a 404 page - On the admin the site stays processing for a while and is slow. I need to select the "Production" mode for the site to able to work. This is strange, the module never had this behaviour. The installation is using: - Processwire 3.0.98 - Tracy Debugger v4.10.22 Right now I do not know if there a module conflict or configuration that is making this behaviour. Thank you
-
Hi, this has resolved. Thank you
- 1 reply
-
- domain
- pagespeed insights
-
(and 1 more)
Tagged with: