Чи можливо ефективно розробити програми PHP в Windows, які будуть розгорнуті на серверах під управлінням Linux?


19

Чи добре кодувати PHP в Windows і розмістити його згодом на сервері під управлінням Linux? Чи можуть виникнути проблеми при міграції такого проекту?

Я думаю, що справді не може виникнути жодних проблем, тим більше, що я початківець у PHP, і я не буду використовувати жодну з розширених функцій, яка може бути специфічною для ОС. Однак я хотів би переконатися, оскільки мені справді зовсім не подобається Linux.


1
Просте рішення вашої проблеми - це Linux VM з Samba, що працює на хості Windows.
treecoder

Так, це можна зробити, але ви повинні врахувати кілька речей. Перевірте відповіді для отримання додаткової інформації. Це одна з тих речей, яку розробники повинні робити, завдяки ресурсам, а не тому, що їм подобається.
umlcat

Відповіді:


27

Деякі вказівки:

Чутливість регістру файлової системи

Якщо ваш файл називається HelloWorld.php це:

include "helloworld.php";

є законним у Windows та працюватиме. Але імена файлів Linux чутливі до регістру, ви можете мати файли з іменами HelloWorld.php, helloworld.php, hEllOwOrlD.phpв тому ж каталозі. Таким чином, ви повинні розвиватися в Windows, як якщо б ви розробляли файлову систему з урахуванням регістру: використовувати саме правильні назви файлів, імена каталогів, імена розширень - .phpтеж відрізняється від .PHP.

Роздільники каталогів і шляхів

У Windows ми говоримо:

include 'classes\myClass.php';

Але в Linux ми б сказали:

include 'classes/myClass.php';

PHP досить розумний, щоб не турбуватися, обидва сепаратори працюють в обох системах. Але ви повинні бути послідовними і ходити з косою рисою (/) скрізь, оскільки це також є нормою для більшості систем. Є видатна заздалегідь визначена константа, DIRECTORY_SEPARATOR яка переводить на правильну, якщо ви хочете піти так далеко:

include "classes" . DIRECTORY_SEPARATOR . "myClass.php";

Те саме стосується роздільника шляху, який є крапкою з комою у Windows, двокрапкою - в іншому випадку. Тож для безпеки ви повинні зробити:

set_include_path(get_include_path() . PATH_SEPARATOR . $path);

коли потрібен роздільник шляху. Хоча більшість людей вважає, що оскільки PHP не проти того, яким роздільником ви користуєтесь, це нормально, але є одна важлива увага: роздільники будуть специфічними для системи, коли ви запитаєте систему для каталогів або шляхів. Отже, скажімо, ви хочете підірвати шлях включення в його частини:

$includePath = get_include_path();

$pathParts = explode(";", $includePath) // Will only work on Windows
$pathParts = explode(":", $includePath) // Will work on other systems but not Windows
$pathParts = explode(PATH_SEPARATOR, $includePath) // Will work everywhere!!!

Кодування файлів та роздільник

Вам слід встановити IDE, щоб встановити кодування файлів для всіх ваших скриптів на UTF-8 замість Cp *, а роздільник рядка файлів на Unix ( "\n"замість "\r\n"). У більшості випадків це насправді не має значення, але ви повинні бути послідовними, і найкращим способом є спосіб Unix (який відмінно працює в Windows, але не навпаки).


1
Для рядків, де ви можете зіткнутися з новими проблемами, PHP також включає константу PHP_EOL, яка використовує правильний символ нового рядка для поточної платформи.
Джонатан Патт

5
Люди насправді використовують косої риски на своїх шляхах до PHP / Windows? Навіть якби я вперше не використовував PHP в Linux, я б уникнув зворотних косих нахилів лише тому, що вони врятувалися.
cHao

2
Чи не повинні це бути "класи \\ myClass.php"?
luiscubal

@luiscubal Так, оскільки я використовую подвійні котирування ... Дякую за те, що відмітили це, відредаговані на одинарні лапки.
янніс

3
Чутливість регістру та кодування файлів - це два, які завжди викликають у мене проблеми між Windows / Linux.
Rangoric

6

Ви не можете працювати strftime()з %eв середовищі Windows , як зазначається в довідковій сторінці :

Не всі специфікатори перетворення можуть підтримуватися вашою бібліотекою С, і в такому випадку вони не будуть підтримуватися строфом PHP (). Крім того, не всі платформи підтримують негативні часові позначки, тому діапазон дат може бути обмежений не раніше епохи Unix. Це означає, що% e,% T,% R і,% D (і, можливо, інші) - а також дати до 1 січня 1970 року - не працюватимуть у Windows, деяких дистрибутивах Linux та кількох інших операційних системах. Для систем Windows повний огляд підтримуваних специфікаторів перетворення можна знайти на сторінці « MSDN .


4

Проблем із запуском коду не виникне. Якщо ви редагуєте файли, збережені в Windows в Linux, ви можете помітити, що символи кінця рядка можуть бути різними, але це нічого не зашкодить. Якщо це не турбує, ви налаштовуєте свій редактор Windows IDE / редактор для використання Unix кінця рядка.


3

Налаштуйте себе на тестовій панелі Linux. Це може бути віртуальний комп'ютер Linux, що працює під Windows, це може бути комп'ютер з двома завантаженнями, це може бути система друга. Потім раз у раз (наприклад, вранці в понеділок) переносіть свій код на систему Linux і тестуйте його.

Інші відповіді вирішили основні проблеми, з якими ви зіткнетесь, але є численні менші розміри, як-от:

  • каталог temp знаходиться в іншому місці
  • дозволи на файли та каталоги різні
  • функція system () радикально змінюється
  • Ім'я користувача, яке Apache запускає у міру зміни
  • Речі, які працюють під Windows XP, можуть не працювати в Windows 8.

Так, є способи ретельно вирішити всі ці відмінності, але ви обережно використовували цілі роботи? Звичайно, ні - ви закодували, і він запустився, так що це повинно бути добре.

Не кладіть нічого на хост-комп'ютер, поки він не перевіриться на подібній операційній системі.

Я не маю досвіду переносу з Windows на Linux, але у мене є певний досвід перенесення з Linux на Windows і більше досвіду перенесення з Linux на OS X. Це можна зробити, але ключі - це тестування, тестування та тестування.


1

Незважаючи на те, що мені досить зручно в командному рядку Linux і за допомогою інструментів редагування Linux, таких як vim, я більшість моїх розробок PHP розробляю на машині Windows.

У мене є віртуальний сервер в Інтернеті (працює мені близько 20 доларів на місяць), який я використовую як сервер розвитку, і я підключаюся до нього за допомогою FileZilla. FileZilla завантажує файли, які я редагую, у тимчасовий каталог і відслідковує збереження, а коли я зберігаю, повертає його назад на сервер розробників, і я перевіряю його звідти.

Це трохи громіздко, але дозволяє мені робити розробку майже де завгодно; Використовуючи FileZilla та простий редактор на накопичувачі, я можу навіть підключитися з іншого комп'ютера та внести зміни. Все тестування завжди знаходиться на сервері Linux, тому я зафіксував будь-які проблеми, які, можливо, виникли поза коробкою - менше неприємних надмірностей, коли я кидаю код на сервер.

Можна зробити те ж саме і з дешевим хостинговим обліковим записом (хоча залежно від того, який саме додаток ви розробляєте, у вас можуть виникнути проблеми з ефективністю, оскільки дешеві облікові записи хостингу зазвичай досить недостатні) та інші багато FTP-додатків також мають редагування та функціональність завантаження.


1

Так, це можна зробити, але ви повинні врахувати кілька речей. Перевірте відповіді для отримання додаткової інформації.

Це одна з таких речей, яку розробники іноді доводиться робити через ресурси, а не тому, що їм подобається.

У вас може бути встановлений локальний веб-сервер (apache, cherokee, навіть M $) на вашому ПК та PHP-сервер. І ваш ПК, можливо, не має підключення до Інтернету або може підключатися лише на короткий проміжок часу.

Пізніше ви можете оновити реальний веб-сайт, оновивши свій файл на реальний сервер, за допомогою ftp-інструментів, з тим же ПК або іншим ПК, підключеним до Інтернету.


0

Як сказала більшість людей, проблем дійсно не повинно бути. Сказавши це, VirtualBox робить насправді дуже просто налаштувати віртуальну машину Linux, на якій ви можете протестувати свою кодову базу, щоб переконатися, що вона працює у виробничому середовищі, не маючи зручності.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.