Веб-форма не подається, натомість переспрямовує до себе

Веб-форми мого найближчого виробництва Webpals Drupal перестали зберігати матеріали; натомість він повертається на ту саму сторінку, доповнену введеними значеннями. У мене немає часової шкали, коли вона перестала працювати. У середовищі пісочниці веб-форма 7.x-3.17 працює чудово.

Я шукаю кілька пропозицій щодо подальшої налагодження.

Я спробував таке, але до успіху:

• Вимкнення будь-яких модулів, що посилаються на веб-форму (зокрема, шаблон веб-форми та перевірка веб-форми , і власний власний модуль, який використовувався hook_form_alter).
• Оновлення до останньої веб-форми (так, я пам’ятав, що використовую update.php).
• На основі документації , поєднуючись hook_form_alter($form, &$form_state)із array_unshift($form['#submit'],'my_custom_submit')вставкою користувальницького зворотного дзвінка, де я закликав drupal_build_form($form['form_id']['#value'],$form_state)наслідувати подання
• Очевидно, послідовно промиває кеші.
• Забезпечення публікації веб-форми.
• Написання модуля з голими кістками для простого моніторингу $form_state['executed'](він завжди повертає помилку).
• Перевірка мого сервера error_logна SSH та FTP.
• Перевірка звітів> Останні повідомлення журналу.
• Нове: спробували відключити та видалити веб-форму, видалити старі файли веб-форми та встановити нову нову версію веб-форми; не добре.

Я впевнений, що проблема не ізольована до веб-форми, тому не було б сенсу розміщувати їх у черзі випусків.

Які інші методи налагодження я можу витягнути, щоб допомогти знищити цю помилку? Якщо я відключую кожен модуль без видалення, чи потрібна ціла резервна копія FTP чи просто SQL?

EDIT: Ще кілька речей, які я спробував відповідно до пропозицій (безуспішно)

• Явне визначення $ cookie_domain та $ base_url у settings.php
• Переглядаючи модулі тригера та дії для будь-яких потенційних переспрямувань на неправильне запуску

У мене ніколи не було проблем з модулем Webform, але якщо це трапилося зі мною, я би перевірив сайти / default / settings.php, щоб побачити, чи є якісь налаштування для явного $base_urlабо $cookie_domain. Останнє набагато малоймовірне, оскільки ви, мабуть, мали б проблеми із входом у систему.

У мене було те саме питання. Як і Денніс, проблема була викликана розміщенням псевдоніму URL на вузлі веб-форми. Коли я видалив псевдонім і зробив повну URL-адресу, тоді він працював чудово. У моєму випадку стався конфлікт, оскільки вибраний псевдонім URL-адреси дорівнював імені каталогу на моєму веб-сайті. Тож я міг використовувати інший псевдонім, і він спрацював чудово. Я просто не можу використовувати псевдонім, який я хотів, якщо я не перейменую конфліктуючу директорію на своєму сайті.

Я тільки отримував саме це питання. Я виявив, що проблема полягає в тому, що форма змінюється таким чином, що заважає веб-формам зрозуміти її. Наскільки я міг сказати, зміни $ form_state не вплинули на зміни, але зміна $ форми все одно було достатньо, щоб розбити всю справу.

Я поки не знайшов вирішення проблеми. Я оновлю свою відповідь, якщо це зробити.

Оновлення: для вирішення проблеми я використав #prefix та #suffix, щоб додати розмітку до елементів замість того, щоб розміщувати їх у контейнерах форми. Це вирішило проблему.

Я хотів тут додати свої два центи. У мене був такий самий випуск на сайті розробників. Сайт незабаром відкриється, але я перевіряв функціональність і отримав цю саму проблему.

Проблема була викликана розміщенням псевдоніму URL на вузлі веб-форми. Коли я видалив псевдонім і зробив повну URL-адресу (mysite.com/?q=node/8), тоді він працював чудово.

Також у мене не ввімкнено чисті URL-адреси, які могли б вирішити проблему з псевдонімом URL-адреси.

Але я хотів це викинути комусь із проблематики. . .

На випадок, якщо ви використовуєте модуль Boost, що зі мною траплялося, і проблема була у файлі .htaccess, перевірте моє рішення тут: https://drupal.stackexchange.com/a/207102/11424