Fail to create thumbnail (style images) in domains not having the default language

I to had this problem, fixed it with a check on the default file path. Created patch

Do this bug happen if there is a language prefix for all languages?
My recommendation is to ALWAYS use language prefix on ALL LANGUAGES, this avoids lots of bugs.

@Drupipi thank you for the patch. I think we need more people to test this patch before merging.

Things I'm afraid of:
- The first versions of D7 Domain Locale did not lock the options at the page admin/structure/domain/view/language. All language settings must be done at /admin/structure/domain/view/[domain_id]/language. I'm afraid the first people which may had modified these options at that time are the ones facing this issue.

- I'm not sure how this patch will affect sites which are already working fine. Maybe it creates double language path prefix?

- Probably we should write an update hook to make sure all languages are enabled under the hood, as need. This already done today at the installation. http://cgit.drupalcode.org/domain_locale/tree/domain_locale.install?id=f...

Try removing the changes you had done and running code to update the database to enable all languages, as done at the hook_install. Let me know if it works for you. If you write this code, please send a patch.

Hello,

i have the same problem on several subdomains.
If I define only one language on these subdomains, the images aren't generated. If I choose all the available languages for these subdomains, the images are created.

I use the version 7.x-1.0-beta5.

Drupipi have you found a solution?

Thanks for your help. Perhaps have you a temporary solution to resolve this problem?

P.S. The code in the patch#3 seems to be the same in the 7.x-1.0-beta5 version...

Hello Drupipi,

My problem is resolved with your code ! THANKS !!!!

Can we include this code in a future version of the module?

Thanks.

there is a real problem with the enabled languages and your fix can be improved.

Can we have a reply by the maintainers for to know if this problem can be resolved in a future release?

Thanks.

@kumkum29 I am maintainer of this module but currently I am only testing patches other developers send to check if they should be merged because I do not have any ongoing paid project with Domain Locale and right now I need to focus on paid projects.

If any person or any company is willing to hire my time to investigate this issue I would love to work on it. Otherwise, I will wait for someone else to send a definitive working solution to be tested and merged.

Changing the priority as per Priority levels of issues

I ran into this problem and solved this by adding $_SERVER['REQUEST_URI'] to the redirect:

<?php
    if ($language_default) {
      $languages = language_list();
      // Get the current prefix
      $current_prefix = $language->prefix;
      // Set the current language to the default language.
      $language = $languages[$language_default->language];
      // Check if we are on a secure connection.
      if (!empty($_SERVER['HTTPS']) && $_SERVER['HTTPS'] !== 'off' || $_SERVER['SERVER_PORT'] == 443) {
        $http = 'https://';
      }
      else {
        $http = 'http://';
      }
      // Set URL suffix to the language prefix, if available.
      if (isset($language_default->prefix)) {
        $url_suffix = '/' . $language_default->prefix;
      }
      else {
        $url_suffix = '';
      }
      
      $request = strpos($_SERVER['REQUEST_URI'], $current_prefix) === 0 ? substr($_SERVER['REQUEST_URI'], strlen($current_prefix) + 1) : $_SERVER['REQUEST_URI'];

      drupal_goto($http . $_domain['subdomain'] . $url_suffix . $request);
    }
?>

Hi,

I thinks that the problem is the path is a path internal of drupal, and is created by hook_menu.

/**
 * Implements hook_menu().
 */
function image_menu() {
  $items = array();

  // Generate image derivatives of publicly available files.
  // If clean URLs are disabled, image derivatives will always be served
  // through the menu system.
  // If clean URLs are enabled and the image derivative already exists,
  // PHP will be bypassed.
  $directory_path = file_stream_wrapper_get_instance_by_scheme('public')->getDirectoryPath();
  $items[$directory_path . '/styles/%image_style'] = array(
    'title' => 'Generate image style',
    'page callback' => 'image_style_deliver',
    'page arguments' => array(count(explode('/', $directory_path)) + 1),
    'access callback' => TRUE,
    'type' => MENU_CALLBACK,
  );
  // Generate and deliver image derivatives of private files.
  // These image derivatives are always delivered through the menu system.
  $items['system/files/styles/%image_style'] = array(
    'title' => 'Generate image style',
    'page callback' => 'image_style_deliver',
    'page arguments' => array(3),
    'access callback' => TRUE,
    'type' => MENU_CALLBACK,
  );

I created this patch and solved for me. I don't now is the best solution.

I created new patch, as the last patch doesn't work correcly. This new patch work perfect about image styles.

@eloiv I really like your last patch, yet I haven't tested it manually myself.

I see a coding standard that could be improved if you follow these guidelines https://www.drupal.org/coding-standards#linelength

+++ b/sites/all/modules/contrib/domain_locale/domain_locale.module
@@ -247,7 +247,10 @@ function domain_locale_init() {
+    if ($language_default && !(strstr($current_path, $public_file_path) || strstr($current_path, $system_path))) {

When you send the next patch please change the issue status to needs review.

I invite others to test this patch, and when you do so please post the list of modules you are using for translation because different module sets may have different outcomes (Entity Translation, i18n, etc).

I can confirm that the patch on #18 fixes the thumbnail generation.
But I'm not sure about:
- You're checking the public file scheme. Can't it be a valid problem for private file directory as well?
- Why do we need to check the system_path? I think the problem it's just about accessing files on the server, while the system/* routes are defined in hoom_menu isn't it?