Rules hiba 7.x-2.5 óta

DruTa képe

Üdv!

Frissítettem a Rules modult pár napja a 7.x-2.5 verzióra, és egyes szabályoknál, ha rákkatintok a szerkesztésre, akkor ez fogad (korábban nem volt gond):

A program nem futtatható!

A hiba lehetséges okai
- a program hibás
- cgi program esetén hibás az interpreter elérési útvonala
- cgi program esetén rossz a programkód sorvégjele (unix sorvégjel kötelezõ)
- php / cgi program esetén rosszul vannak beállítva a fájl futtatási jogosultságok
- php / cgi program esetén rosszul vannak beállítva a könyvtár futtatási jogosultságok

Webmester infó
A futtatási jogosultságok megfelelõ beállítása minden esetben chmod 711, vagy chmod 755

Nálatok is, vagy ez csak nálam hiba?

Melyik modulhoz, modulokhoz kapcsolódik a téma?: 
Drupal verzió: 
eager képe

Ez annyiban tárhely-függő, hogy a szolgáltató az eredeti hibaüzenet helyett ezt jeleníti meg.

Azt hiszem, hogy az én esetemben ezt akkor tette ki a szolgáltató, amikor az Apache http 500 'Internal Server Error'-ral válaszolt.

500-as hibát rengeteg minden tud okozni.

Viszont így már el lehet kezdeni nyomozni, hátha a drupal rules 2.5 500 internal server error keresés közelebb visz a megoldáshoz...

EDIT:

hát, csak a drupal +rules-7.x-2.5 internal server error keresés ért valamit, ezt találtam, ezen mintha már 2.0 körül dolgoztak volna, azért megnézném:

https://drupal.org/node/1258284 (a rules releases oldalról jutottam ide)

  • Ettől függetlenül megnézném az /admin/reports/status, illetve közvetlenül a hiba előidézése után a /admin/reports/dblog oldalakat.
  • Követve a szálakat, úgy néz ki, hogy nem csak a Rules háza táján rejtőzhet a probléma (említenek Entity-t, majd i18n-t is), itt is megnézném, lehet-e ebben az esetben követni azt a bevett gyakorlatot, hogy készít az ember egy klónt az oldalról a kísérletezéshez, amin kifele kapcsolgat modulokat, és nézni, hogy mi a sorsa a hibának.
0
0
DruTa képe

Kösz!

Az érdekes az, hogy van, amelyik szabályt lehet szerkeszteni, nem mindegyiknél jön ez elő, viszont következetesen ugyanazoknál, pedig eddig azok is jók voltak.

Megpróbálom visszatenni a régit, csak az a kérdés, hogy megvan-e az még valahol...

0
0
balazsgabi képe

DruTa képe

Kösz, közben megtaláltam, csak nem mertem még visszatenni, mert azon gondolkodtam, hogy mi lesz a beállításokkal.

Exportálnom kell és majd vissza, vagy csak telepítsem a régit, tiltsam le előtte az újat és a korábbi felveszi a beállításokat?

Vagy amikor letiltom az újat, amit most törölni akarok, akkor a beállítások is elvesznek?

Ráadásul nem is tehetem ezt csak éjjel, mivel a regisztrációt is kezeli a rules-s.

0
0
balazsgabi képe

a beállításokat adatbázisba írod (írja a drupal) de, hogy mi van akkor mikor downgradelsz azt nem tudom, mert lehet, hogy az új verzióban volt olyan fícsör, ami "új" dolgot írt az adatbázisba, amit a régi jobb esetben nem tud értelmezni. A rosszabbikat fantáziádra bízom :)

és igen a protokoll ez: kikapcs-töröl-ír-bekapcs

a (talán) legfájdalommentesebb, hogy az aktuálist localba exportálod szőröstül-bőröstül, ott megcsinálod a csere-berét, ha minden OK, akkor a localból töltöd vissza a szerverre. ha ezzel megvagy, egyben tapasztalatot is szereztél, hogy mennyivel egyszerűbb nem éles oldalon hegeszteni. Egy átlagos weboldalt localba klónozni, nem több negyed óránál, ha szerver környezet emulálása nem menne, akkor minimum egy fejlesztek.domainem.hu-s aldomain (külön adatbázissal természetesen) ugyanazon a vason.

1
0
DruTa képe

Kösz, a fejlesztéses aldomaint alkalmazom is, mivel jobban megbízom benne, mint a XAMPP-ba, ami azért nem 100%-ig ugyanaz.

Sőt, ha jól tudom, akár azt is megtehetem, hogy az aldomaint átirányítom a rendes domainra és onnantól az él, persze a rendes domain mappáit ki kell cserélnem a fejlesztett mappáira.

1
0
balazsgabi képe

ennek megtárgyalása már erősen off ebben a szálban, meg aztán nem is biztos, hogy én vagyok a legmegfelelőbb megmondóember a témában, de elvileg igen, bár én nem tenném.

0
0