Jump to content

da²

Members
  • Posts

    375
  • Joined

  • Last visited

  • Days Won

    5

da² last won the day on December 17 2024

da² had the most liked content!

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

da²'s Achievements

Sr. Member

Sr. Member (5/6)

253

Reputation

  1. What is disturbing me the most is the fact that I'm not finding pages (using Pages API) that are not enabled for the current user language. For example, I have a few templates that are not meant to be translated, so I disabled multi-language management ("Settings tab" in the template). But if user is not using the default language I don't find them. pages()->find('template=foo'); // Need all pages even if not enabled for current user language In Page Names module option, we can avoid the page to show a 404 and make it render in default language, but it's missing the same option using API to find pages (find(), children()...). I see 2 workarounds, not really satisfying: Always enable all languages on every page and template, even if they are not meant to be translated. Set user language to default before every kind of page search. This is too much, and error prone. A global option would be better. Maybe I'm missing another option?
  2. Just to add to this topic, Page class has a function to enable language, a bit cleaner than using "status$lang": foreach (languages()->findNonDefault() as $language) { $page->setLanguageStatus($language, true); }
  3. Thanks, I find this behavior a bit odd and think the option implemented in RockMigrations could be on the core module "Page Names". Creating pages via API doesn't use the same behavior as when using the admin interface, or even when generating pages within an admin hook (all languages are activated by default in these cases). I don't understand why this is different in a hook and when bootstrapping PW. Also, when we add a new language, every existing page is automatically enabled for this language, so why not doing it by default when a new page is created on front-end? Do you know the reasons behind these choices?
  4. Hello, My site (PW 3.0.240), using multi-language URLs since a few months, has default language french, and another language english. I don't know why, but a specific template is not accessible to english on front-end: If I go to the english URL of one of these pages, I get a 404. If I go to one of this pages in french, the language switcher shows only french as available language. If I display the pages of this template while using english, I get an empty list. I found that I checked in "template > advanced" the option "Disable multi-language support for this template" but: Enabling it again doesn't solve the issue. This option doesn't show a 404, it just switch language to default when loading this page. That was a mistake to check it, but not the cause of this issue (apparently). While writing this post, I investigated more and found the following. I finally found what makes these pages unreachable in english, this in the pages themselves, this checkbox is disabled in Settings tab: These pages are created dynamically, why is this "active" checkbox disabled, is it expected, and how to enable it automatically? This is more serious than it looks, because it ends with important bugs in the site and database inconsistencies. The problematic template represents a team in a competition. When a user using english language registers to a championship and creates a team, it is well created, BUT when he leaves the championship the team is not deleted because the find() method is not returning it, and the user is still referenced in the team even if not in this championship anymore. I'm disabling english to avoid more damages until I can fix this properly. How can I fix this? And if you have informations about this behavior, please explain or give documentation links, I'm a bit lost actually.
  5. Create 2 dates, one on the first day of the month, one on the last day, and use the selector "event_date>=begin, event_date<end". You are potentially loading thousands of pages here.
  6. Check that the root directory configured in your web server is the same than previous. The path before that has no importance. And obviously, don't use absolute paths in your code, but that shouldn't be the case. Also maybe check if your less compiler has an option to delete its cache, or a cache directory that is set to an absolute path maybe?...
  7. languages() global function is another way to get the instance, but wire()->languages property should work too.
  8. Hello, You can use $this->languages, wire()->languages or wire('languages'). I prefer to use wire()->languages so PhpStorm knows what I'm using.
  9. If trying to migrate an existing site from one server to another, the easiest is to copy files and replicate the database. No need to use the PW installer. Then, if wanted, you can update PW to the last version using the official module ProcessWireUpgrade.
  10. Both codes are NOT giving the same selector, you could check by printing it. First case gives: "item_number= " (with a space) Second one gives: "item_number=' '" (space inside quotes) To find empty values, you can just use "item_number=''" (no space inside quotes), or "item_number=" (nothing after equal). But I don't know why the first one is returning a page with item_number=50032. If you're sure everything is right on your side, maybe report a bug on Github.
  11. Hello, Are you using Apache? Is it configured to read .htaccess files? Is mod_rewrite enabled? https://gcore.com/learning/how-enable-apache-mod-rewrite/
  12. I won't help for reading a function name. 😆 I don't know the module, check the documentation.
  13. Question is: will the Javascript be aware of the changes on the field? I bet no, and that it will need to be reloaded. I confirm that, I had to remove these conditions on a page because it was totally bugged (3 or 4 fields with dependencies), reported the issue but nothing has been done. 😐
  14. Hi, My first though is about .htaccess. Is it the original one? Does the web server process it correctly and does the server have more rules (redirections...) that could interfere with the PW .htaccess rules? Could it be related with the 404 page configuration in config? $config->http404PageID = 27; Also check that no hook is doing that redirection, like a hook that would say: "redirect normal and guest user to home page if they try to access admin"? ^^
×
×
  • Create New...