Search the Community
Showing results for 'template'.
-
1 to 100 of 687951 (estimate) errors and website gone
BFD Calendar replied to BFD Calendar's topic in General Support
@BrendonKoz As said above I can't get into the PW admin interface anymore. No matter what page is called, everything gets stuck at Uff da… Fatal Error: Class FieldtypeImage contains 2 abstract methods and must therefore be declared abstract or implement the remaining methods (FieldtypeHasFiles::hasFiles, FieldtypeHasFiles::getFilesPath) (line 18 of wire/modules/Fieldtype/FieldtypeImage/FieldtypeImage.module) This error message was shown because: site is in debug mode. ($config->debug = true; => site/config.php). Error has been logged. I can access the errors.txt file via ftp. For today (2025-10-07) only there are 19092 errors as above. In my provider's error log I can see plenty of [Mon Oct 06 20:26:03 2025] [X-OVHRequest-Id: 0b8c2f578748d1061d5e670a11218ce2] [error] [client 54.161.50.125:0] [host birthfactdeathcalendar.net] AH10157: FastCGI: An error happened during Fastcgi processing, fallback to CGI [Mon Oct 06 23:52:49 2025] [X-OVHRequest-Id: da62e0ad0f08ee270e46e69c4cdbb0b7] [error] [client 51.57.57.231:0] [host birthfactdeathcalendar.net] AH01264: script not found or unable to stat: /homez.863/birthfac/cgi-bin All those are Amazon and Microsoft ip addresses. Apparently the robots.txt file doesn't keep those away. I manually replaced the latest wire and all site modules are up to date. Template errors that showed up earlier are all fixed. But as long as I can't get past the Fatal Error there's not much more to do or try I presume. And the most baffling thing is that everything worked fine yesterday for about two hours, without any further change the Fatal Error just popped up. -
1 to 100 of 687951 (estimate) errors and website gone
BrendonKoz replied to BFD Calendar's topic in General Support
I would recommend deleting the errors.txt file (if/when you have access to the PW admin, it's under Logs -> Burn [while viewing that log; expand "Helpers" at the top, and then "Actions"]), or if not deleting, pruning it. I suspect that log has lived since the website has been running. It's unlikely you care about errors from 2 months ago or more - just the recent issues. I leave that decision up to you, but having an error log that large is unlikely to be useful (at least for me). I think it would be good to fix the errors that are popping up first. Your upgrade of the /wire/ directory is the first step; making sure the modules you have installed and enabled are up-to-date is another (and maybe you have some that aren't fully compatible?). Then making sure each template no longer has any problems (since we're working on a newer version of the core, it's unlikely but entirely possible). If you don't yet want to invest in additional development time to implement ProCache, you could try the built-in template cache as a quick test to see how your website would behave with that enabled. This would be good for pages (URLs) where the content doesn't change often. The cache is rebuilt after a set period of time, or when changes are made to the page, or its template. To enable template caching, go to the template you might want to try this on, head to the "Cache" tab, then enable it and choose the settings you think would best suit your site's template. -
1 to 100 of 687951 (estimate) errors and website gone
BFD Calendar replied to BFD Calendar's topic in General Support
@ryan Well there were quite a few errors that occured after the upgrade from PW 3.0.123 and PHP 7.x to 8.2. Like in all templates "$feature->template==bfd_events" didn't work and needed change to "$feature->template=='bfd_events'". Or "$webimage = $page->images->random()->url;" no longer worked. I managed to find out everything and got the site back working, when the above mentioned errors started appearing and my provider shut down the site. I went back two weeks in time with a backup option from my provider to make sure I'd get it all as it was before upgrading anything. But now I only see the first lines of the site, and the admin site is no longer reachable: internal error or misconfiguration. Even downgrading to PW 3.0.98 doesn't make any difference and of course now I can't even see any error logs as admin. Other pages like https://www.birthfactdeathcalendar.net/phpinfo.php load normal. With my provider I upgraded my hosting to allow more resources. The AI bot option might be the culprit, could it be Google trying to crawl/index the whole site? There are over 30.000 pages.... Report from Google Search Console: https://search.google.com/search-console/index/drilldown?resource_id=sc-domain%3Abirthfactdeathcalendar.net&pages=ALL_URLS&hl=en&sharing_key=N-nvEOUPuUWWfngX3zI85w. -
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
-
@cst989 Okay, so I was unlcear if the entire page was showing a 302 or if just the file was showing a 302. This is going to lead you astray on this issue. The $this->modulesJsPath is a private variable limited to the Fluency class and isn't accessible anywhere else in ProcessWire. So if you attempt to dump that anywhere outside of a function in the Fluency module it will return null. If you are dumping this from within a function in the Fluency class then that is a different story. Let's try this. In a template file, run this code and share what you see: <?php $result = $fluency->translate('en', 'de', [ 'Testing the translation service', ], [], false); var_dump($result); die; ?> This will test to see that translation is set up correctly. If it isn't then it may be a configuration issue that Fluency is not detecting or handling. -
Hi @vmo - thanks for looking into this and coming up with a fix, but if I understand correctly, I feel like this is something that the PW core should handle because it's about fields within a template that has noLang = '1' not respecting that setting, whereas this module is all about specific pages/branches having this setting while others of the same template don't. Does that make sense?
-
Ty! I've had it working like this (skeleton code, in ready.php): $wire->addHookAfter('Page::addable', function(HookEvent $event) { $parent = $event->object; $tplArg = $event->arguments(0); $tplName = $tplArg instanceof Template ? $tplArg->name : (string) $tplArg; if($parent->template->name !== 'user-articles') return; $rep = $parent->get('repeater_publish_dates'); $hasDates = ($rep && count($rep) > 0); if(!$hasDates) { $event->return = false; } }); Pretty much 1:1 what you wrote. -
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
-
well, if you restrain the template access it won't be proposed to add/edit a page and a user who hs obnly access to certain templates/pages don't have access at all à the templates, this is a supreadmin feautre 🙂 have a look when logged as a non superadmin user
-
Thank you, my motive is to prevent people from having access to the templates not only the pages using that template.
-
Hi Ana, depending on what you need i would say yes 🙂 in the access tab of the template if you check the yes radio button, you will see the roles you've created and will be able to easily choose which one can have access to the pages using this template, job done 🙂 have a nice day
-
Image Hotspots Allows a Repeater field to be used to define hotspots on an image. Being able to add multiple fields of any type to the Repeater provides flexibility for the information you can store for a hotspot. Setup 1. Install the module. Two decimal fields will automatically be created on install: hotspot_x and hotspot_y. You can set custom hotspot and highlight colours in the module config if needed. 2. Create a "single" image field (i.e. maximum number of files = 1) that you will use store the image that will have hotspots defined on it. Add this field to a template. 3. Create a Repeater field and add the hotspot_x and hotspot_y fields to the Repeater. Add any other fields you need to store information about the hotspots you will create. Save the Repeater field. 4. In the "Details" tab of the Repeater field, expand the "Image Hotspots" section (this section appears for any Repeater field that has the hotspot_x and hotspot_y fields). For "Image field", select the image field you created in step 2. The "Image height" setting defines the maximum height of the image when displayed in Page Edit. 5. Add the Repeater field to the template you added the image field to in step 2. Usage in Page Edit When an image has been saved to the image field, the Repeater field will display a preview of the image at the top of the field. Click "Add New" to create a new hotspot. The hotspot appears at the top left of the image initially and can be moved by clicking and dragging it to the desired location on the image. The X/Y coordinates of the hotspot will be automatically updated as the hotspot is moved. For precise adjustments you can modify the X/Y coordinates directly and the hotspot position will be updated. To identify which Repeater item corresponds to a given hotspot, click on the hotspot. The corresponding Repeater item header will receive an orange outline. Click the hotspot again to remove the orange outline. To identify which hotspot corresponds to a given Repeater item, expand the Repeater item and focus either the X or Y coordinate fields. The corresponding hotspot will be highlighted in orange. On the frontend It's up to you to display the hotspots on the frontend in any way you need. The values of the hotspot_x and hotspot_y fields are percentages so when given absolution positioning over the image your hotspot markers can preserve their positions as the image scales up or down in a responsive layout. https://github.com/Toutouwai/ImageHotspots https://processwire.com/modules/image-hotspots/
-
Hello PW friends, Is it possible to hide a template and prevent all accesss to a template in the backend except certain users. Thank you
-
Disable "new page" functionality if parent page has insufficient data
BitPoet replied to Sebastian's topic in API & Templates
Hook after Page::addable. $event->object will be the page to add a child to. Untested example code written off the top of my head: <?php namespace ProcessWire; // For ready.php wire()->addHookAfter('Page::addable', function(HookEvent $event) { $thisPage = $event->object; // Exit early if already disallowed if(! $event->return) return; // Only apply to pages with template article-list if($thisPage->template->name !== 'article-list') return; // Now check the fields on the page whether they allow // adding children. Adapt the field name to your use case. if($thisPage->dateslistrepeater->count() == 0) { $event->return = false; } }); This should disable the Add / Add Children button. You'll probably have to save the page after adding a repeater item before you can add children from the page editor. -
Hello dear forum, I'm building the backend of a kind of magazine. The magazine has different contributors. Each contributor has it's own tree in the page tree, like this: home/user-articles/contributor-a/ and should be able to post articles as children to contributor-a. On the contributor-a page (template called "article-list") there needs to be a list of dates. These dates (a repeater in "article list") are used as select options in the article the user is going to post. So far so good. However, if the user tries to create a new article, and there haven't been any dates posted to the future parent yet, I get an error : "TypeError ProcessWire\InputfieldPage::getPageLabel(): Argument #1 ($page) must be of type ProcessWire\Page, string given, called in /var/www/html/wire/modules/Inputfield/InputfieldPage/InputfieldPage.module on line 700" wich only occurs when there's no date(s) posted to the parent yet. Now I'm thinking about only allowing adding new children to that "article-list" template when at least one date is available, and am stumped as to how to solve this. I basically need to disable the "new" button in the tree view - or basically anwhere it might show up - and post a message explaining what's up. Pretty sure I need to hook into ready.php (or admin.php) but other than that I'm struggling.. If anyone has any pointers (or just some skeleton code) that would be great, thanks in advance!
-
Small update following a small issue I had: when saving a template the module now makes sure "sortfield_reverse" is unset, in case the user was previously sorting using a reversed sort direction
-
FYI, you can view all the template access overrides for a field on the Overrides tab of Edit Field.
-
Thanks for this module. I've been using it a lot recently given that the web app I'm building makes heavy use of roles and permissions and I appreciate the "helicopter view" the module gives you. Recently, I've been using access rules on fields within the context of a template. Unfortunately, ProcessWire doesn't have a "helicopter view" of being able to see those settings, which means you have to go into each template and click on a field to bring up the modal, then go to the access tab to see what the settings are. Now imagine having to do that for dozens of fields. I wonder if you've dealt with that and if a feature like that makes sense for this module (or if it's out of scope).
-
Textformatter module Textblocks renders content double
BrendonKoz replied to Jan S.'s topic in General Support
Hi @Jan S.! Welcome to the forum, and congratulations on your first post! We're glad to have you. 😊 Based on what you're showing, your code looks good from what I can see of the TextBlocks documentation, so I am not entirely sure what to suggest, other than maybe seeing if removing the "echo" from your template call to the field will still render the field. I don't think it should, but since it's being duplicated, it can't hurt to try. Beyond that, TextBlocks is a paid ProDevTools module, so support for that module is in its own forum, locked down for paid/active module owners. Assuming your module support status is up-to-date, that can be found in the ProFields Support subforum here. -
I would love to try this but I am getting an error when trying to restore the backup on the prod machine. When trying to go into the Database Migrations page I get an error that says: Unknown field supplied to saveField for page 1167 If I choose the migration from the admin section of the page tree I get the same error. I can open up the bootstrap one though. It was only a simple test. I added a field and a template in the dev side.
-
enum TournamentType:string { case MYSTERY = "Mystery"; case PKO = "PKO"; case VANILLA = "Vanilla"; } class FilterSolvesForm extends AbstractFrontendForm { protected function buildForm(): void { $tournamentTypeSelect = new Select("tournamentType"); $tournamentTypeSelect->setLabel(__("Type de tournoi")); foreach (TournamentType::cases() as $tournamentType) { $tournamentTypeSelect->addOption($tournamentType->value, $tournamentType->value); } $this->add($tournamentTypeSelect); } } abstract class AbstractFrontendForm extends Form { public function __construct(string $id) { parent::__construct($id); $this->buildForm(); $this->addSubmit(); } private function addSubmit():void { $button = new Button('submit'); $button->setAttribute('value', __("Valider")); $this->add($button); } abstract protected function buildForm(): void; } // TEMPLATE PHP FILE $command = new SelectSolvesDatabaseCommand(1, 10); $filtersForm = new FilterSolvesForm("solvesFilterForm"); if ($filtersForm->isValid()) { // DevUtils::prettyPrintObject($filtersForm->getValue('tournamentType')); // $command->addFilter('tournamentType', $filtersForm->getValue('tournamentType')); } $filtersForm->showForm(true); $command->execute(); $solves = $command->getPaginatedSolves(); Twig::render('browse-solves', [ 'paginatedSolves' => $solves, 'filtersForm' => $filtersForm, ] ); -
I found in your code that it is $form->setAttribute('method', 'get'); (documentation needs an update 🙂 ). But now the page is empty after submission, empty head and body. I don't understand what's happening. EDIT: Looks like there is an exit() somewhere, because no code in my template is executed after $form->isValid() when I use GET method. 🧐
-
[solved] Panic: File-Compiler Log new entries every second
matjazp replied to biber's topic in General Support
FieldtypeSelect is very old module from 2013 that "produces a drop down list (via a "select" input) that would allow you to define a list of options in the field's configuration from which to select a value. After installing, you'll have a new "Select" fieldtype that will allow you to define the items you'd like in the drop down. You'll be able to define these options in a text box on the field's configuration screen. Just put each option on it's own line." Github Repo: https://github.com/Hani79/Processwire_FieldType_Select_Drop_Down My fork: https://github.com/matjazpotocnik/Processwire_FieldType_Select_Drop_Down You should use FieldtypeOptions nowdays. Can't answer that, see if the fieldtype Select is used in any template? -
@Stefanowitsch asked about using the File Mover module with a "media library" page that is accessed via a modal. I thought I would share some hook code publicly in case it's useful for others too. // Add a button to file and image fields to open a media library page in a modal // Hook InputfieldFile::render to affect file and image fields, // or InputfieldImage::render to affect only image fields $wire->addHookAfter('InputfieldFile::render', function(HookEvent $event) { $inputfield = $event->object; // The field associated with the inputfield (if any) $field = $inputfield->hasField; // The page containing the inputfield (if any) $page = $inputfield->hasPage; // Don't add the button to fields on the media library page // as we don't want the possibility of nested modals if($page && $page->template == 'media_library') return; // You can also check the field name if the button should only be added to a specific field, e.g. // if($field && $field->name !== 'article_images') return; // Get the media library page $media_library = $event->wire()->pages->get("template=media_library"); // Construct the URL to edit the media library page $url = $media_library->editUrl; // Add &modal=1 so the admin header isn't shown $url .= '&modal=1'; // We don't need other tabs or fields besides the image/file field(s), // so specify the field name(s) in the URL // Unfortunately there is this layout bug: https://github.com/processwire/processwire-issues/issues/1972 $url .= '&field=images,files'; /** @var InputfieldButton $f */ $f = $event->wire()->modules->get('InputfieldButton'); $f->href = $url; $f->value = 'Open media library'; $f->icon = 'picture-o'; // Add pw-modal class so the button link opens in a modal $f->addClass('pw-modal'); // Make it a large modal $f->addClass('pw-modal-large'); // Add a bit of space above the button $f->attr('style', 'margin-top: 10px;'); // Append the rendered button to the inputfield $event->return .= $f->render(); });
