vmo

Hi @adrian, for your information, I have posted a comment on the issue already open: Repeater template with multilanguage fields does not take in account the noLang setting in the parent template. The link for the comment is: - https://github.com/processwire/processwire-issues/issues/2077#issuecomment-3385589884 If you have more information to add to the issue I would appreciated if you could add it. Thank you Kind regards

Hi @adrian, I found an open issue on github https://github.com/processwire/processwire-issues/issues/2077 realted to the same issue and this was the reply from @ryan at the time: - https://github.com/processwire/processwire-issues/issues/2077#issuecomment-3024317669 I will add a comment to it as soon as possible and thank you for your feedback. Kind regards

Hello @adrian, I am a newbie to Processwire but after thinking about this in a different perspective and doing a little bit of debugging I think I found the "issue": - A repeater uses pages to hold the fields but to be able to create that pages it needs to create a specific templates for that pages and that templates are not the same template of the page were the multi-language support is set. - It means that the multi-language support that is set on the top template of the page itself do not propagate to the hidden templates used by the repeaters and that is why you have the following loop: foreach($p->fields as $f) { if($f->type instanceof FieldtypeRepeater === false) continue; $this->wire('templates')->get(FieldtypeRepeater::templateNamePrefix . $f->name)->noLang = '1'; } and if you return without setting the noLang=1 on the template of the repeater field: if($p->template->noLang === 1) return; the fields inside the repeater will not know about the noLang set on the top template of the page itself. At this point I don't have a opinion if the PW core should or not should handle the propagation of the noLang attribute to the hidden/sub templates used by the repeaters (or other composed fields) or if it is the template job to understand if it is operating as a hidden/sub template and get the noLang value from the top template. Kind regards

Hi @adrian, thank you for your reply. As far I could understand PW core handles this for the fields that are not fields inside repeaters. In the beginning of the function is the following code: // if actual noLang setting for this page's template is set to disabled (1) then exit now so we don't potentially enable if($p->template->noLang === 1) return; // ... What this code tells me, is that, if the template of the page has the multi-language support set to "disabled" (noLang===1) it returns whitout processing the fields inside the repeaters like it does if it passes this step: // ... // if there's a match, set the noLang value for the page's template appropriately if(isset($this->data['multilanguageStatus'][$this->closestMatch->id])) { if($this->data['multilanguageStatus'][$this->closestMatch->id]['status'] == 'disabled') { $p->template->noLang = '1'; // we want repeater fields single language as well foreach($p->fields as $f) { if($f->type instanceof FieldtypeRepeater === false) continue; $this->wire('templates')->get(FieldtypeRepeater::templateNamePrefix . $f->name)->noLang = '1'; } } else { $p->template->noLang = '0'; } } // if no match, then use default from config settings else { $p->template->noLang = $this->data['multilanguageDefaultStatus'] == 'disabled' ? '1' : '0'; } I found this behavior by debugging, because, not matter what I would set on the "Multi-Language Default Status" of the module settings (enabled or disabled), the fields inside the repeaters would always show with multi-language support while the other fields (like the multi-language title) would show with no multi-language support. So the only way to be able to fix the issue was to process the fields of each repeater on the page when the "if($p->template->noLang === 1)". Maybe it makes more sense if you take the following into account (at least in my case): - The template has the multi-language support disabled (noLang === 1) - In all the pages of that template, on the "Multilanguage Restrictions" section on the Settings tab, what I see is the following: "Language Branch Restrictions: The template for this page has disabled multi-language support, so we don't want to override here." This tells me the following: - If the "Multilanguage Restrictions" are on the template level: the "Multilanguage Restrictions" are set for all the pages of that template. - If I want to set "Multilanguage Restrictions" for one page and not for the others: I need to remove the "Multilanguage Restrictions" from the template and set it on that page. In my case, I am setting the "Multilanguage Restrictions" to disabled at the template level so for me it makes sense. Maybe I am wrong about my understanding but by reading the code and how the module configurations behave that was my understanding. I hope my explanation wasn't to confusing. Kind regards

Hi, I was having trouble with the Repeater fields including the RepeaterMatrix and the following patch is working for me: Changes to the "function multilanguageStatusCheck": /** * Checks if page should show multi-language inputs * * @param HookEvent $event */ public function multilanguageStatusCheck(HookEvent $event) { $p = $event->object->getPage(); // ORIGINAL // if actual noLang setting for this page's template is set to disabled (1) then exit now so we don't potentially enable //if($p->template->noLang === 1) return; // PATCH // if actual noLang setting for this page's template is set to disabled (1) // ensure any repeater/repeater matrix item templates are also single-language, then exit if($p->template->noLang === 1) { foreach($p->fields as $f) { if($f->type instanceof FieldtypeRepeater === false) continue; $this->wire('templates')->get(FieldtypeRepeater::templateNamePrefix . $f->name)->noLang = '1'; } return; } // No other changes after this point. } I don't know if it is the best way to patched it or if there is a better way. If this change is okay, to make it persistent during module updates, can you please add this change to the module. I will open an issue on github. Kind regards

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

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

I am using the module "Session Handler Database" Thank you

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

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

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

Many thanks to all, I was getting frustrating about this, saved the day.

Thank you for the wild gess about the languages problem, it seems that the is related to the languages. I had only one language active that was Portuguese, and after added a new language the home was shown correctly, now I need to verify the issue in other pages. Many thank you for help I think now it is just a time issue to verify all the pages and file templates.

The htaccess file is from a processwire instalation. The original htaccess from the version 3.0.89 and the htaccess from the other installation with a lower version are not working, the issue continues.

In the same server I have other processwire site that is working and after replacing the htaccess file from the one that is working the issue continues, back to zero.

You might be right about the htaccess directives, but I do not have much knowledge about the htaccess directives, I will try to verify. Thank you