Как администрировать свой сайт?
Многие клиенты задают нам вопросы из ряда: «а после окончания работ я смогу самостоятельно администрировать сайт?». В этой статье постараемся ответить на этот вопрос, предварительно поняв, что же такое администрирование сайта.
Что входит в администрирование сайта
Давайте разбираться, что же входит в это понятие. Какие пункты включает в себя администрирование сайта и в каких «степях» оно важно:
- Наполнение контентом.
- Загрузка медиафайлов.
- Добавление новостей, статей.
- Возможность поменять заголовки, текст на страницах.
- Внести корректировки в форму обратной связи или контакты.
- Запуск акции или корректировка текущей распродажи.
На самом деле, список можно продолжать бесконечно: в администрирование сайта входит безумное количество пунктов, так или иначе завязанных на контенте и технической стороне сайта.
И вот теперь, оглядываясь на список выше, еще раз задайтесь вопросом: «после окончания работ с Волгой-Веб я смогу самостоятельно администрировать сайт?». Друзья, ну а сами-то вы как думаете? Разумеется — для того мы и работаем, чтобы облегчить ведение бизнеса и поиск клиентов.
Что сделаем мы для облегчения администрирования сайта
Мы сделаем очень гибкую страницу с качественным дизайном и таким же контентным наполнением. Таким образом, на выходе вы будете обладать крутейшим сайтом, способным конвертировать посетителя в клиента.
И разумеется, мы дадим вам инструкции по тому, как работать с этим продуктом на выходе. Никакие вирусы, или атаки не способны будут помешать сайту функционировать, если все делать корректно.
Вы всегда можете обратиться к нам с вопросами, если что-то пойдет не так. Наши менеджеры и разработчики всегда готовы помочь с администрированием сайта, однако в большинстве случаев дополнительных вопросов у клиентов не возникает.
Если вы готовы получить действительно качественную страницу, которая приносит клиентов и не требует постоянных доработок, мы ждем вашего звонка!
Теги: администрирование сайта управление сайтом cms система управления контентом как обновлять сайт
Предыдущая запись
Интернет-маркетинг: раскладываем по полочкам
Следующая запись
Как не слить бюджет на SEO?
Возврат к списку
Что мы умеем делать:
- Создание сайтов
- Разработка интернет-магазинов
- Фирменный стиль
- 3D Моделирование
- Забота о сайтах
- Разработка мобильных приложений
- Сопровождение сайтов
- Фотосъемка
- Аудит сайта
- Реклама в интернете
- Медийная реклама
- Поисковое продвижение
- Корпоративный портал
Cпасибо за заявку!
Мы свяжемся с Вами в течение половины рабочего дня.
Cпасибо за заявку!
Мы свяжемся с Вами в течение половины рабочего дня.
Записаться на встречу
Телефон
Нажимая на кнопку «Оставить заявку», вы соглашаетесь с правилами обработки персональных данных
Cпасибо за заявку!
Мы свяжемся с Вами в течение половины рабочего дня.
Заказать экспресс-аудит
РекламаSEOСайтКонсультация по развитию бизнесаНаправление
Нажимая на кнопку «Заказать», вы соглашаетесь с правилами обработки персональных данных
Cпасибо за заявку!
Мы свяжемся с Вами в течение половины рабочего дня.
Неудачный опыт создания и администрирования сайта научного журнала / Хабр
Говорить о том, как не надо заказывать сайты, у разработчиков уже язык устал. Но совершенно справедливо подмечено, что свой опыт крайне трудно вложить в чужую голову, а посему неопытные заказчики продолжают наступать на одни и те же грабли. Возможно, одна из причин в том, что подходят к роковому предмету садового инвентаря все с разных сторон и каждый собственным путем. Поделюсь своим.
Прежде всего признаюсь, в какой степени я чайник. В средней школе на уроках информатики якобы освоила (в пределах школьной программы) элементарные основы языка html, в начале XXI века с помощью хтмлеглюкатора (термин Максима Мошкова) MS Front Page открыла и вела на бесплатном хостинге сайт совсем без дизайна: главная страница оформлена по одному из стандартных шаблонов хостинга, прочие подчиненные страницы — с черным текстом на белом или сером фоне. Для сетевой публикации околохудожественных произведений собственного сочинения большего и не требовалось. А через несколько лет я зарегистрировалась на «Самиздате» у Максима Мошкова и свой сайт совсем забросила. Мои познания в области веб-дизайна так и остались на зачаточном уровне начала века.
В 2014 году в одном из технических университетов создали научный журнал гуманитарной направленности и я пришла работать в его редакцию. В университете уже выходил (и теперь продолжает издаваться) научно-технический журнал. Его сайт представлял собой один из разделов общего сайта вуза. Администратор университетского сайта напрямую подчинялся начальнику информационно-вычислительного центра (ИВЦ), а тот установил строгую очередность выкладывания материалов на сайт. Даже профильный журнал не был в этой очереди первым, и некоторые его новости ко времени, когда до них доходили руки у администратора сайта, уже успевали потерять актуальность. Само собой, редакция нового журнала, да к тому же гуманитарного, оказалась бы в самом дальнем конце очереди и не могла мечтать об оперативном размещении своих материалов на сайте.
Заведующая редакцией решила, что нас это не устраивает, тем более что ей чисто внешне был несимпатичен минималистский дизайн университетского сайта, работающего под управлением 1С-Битрикс.
У заведующей редакцией накопился большой опыт административной работы, но в сайтах она разбиралась еще меньше, чем я. Используя административный ресурс, она привлекла к созданию сайта нового журнала двух аспирантов с кафедры, готовившей специалистов по информационным технологиям. Оба разработчика поневоле, разумеется, не пылали энтузиазмом что-либо создавать за те деньги, что выделил проректор, но у них не было выбора. Выбор они предложили нам: скомпоновать сайт из готовых модулей («из детских кубиков», как они нам на пальцах объясняли) или написать его, как полагается по-хорошему и как делают взрослые серьезные люди.
И вот здесь мы совершили первую ошибку. Настолько неопытным пользователям, какими были и остаемся мы, сайта «из кубиков» хватило бы за глаза и за уши. Такие сайты просты не только в создании, но и в управлении, поскольку рассчитаны на людей, понимающих в администрировании веб-ресурсов чуть больше, чем ничего.
Но нет же, нам нужно было всё всерьез и по-взрослому. При этом никаких конструктивных предложений по функционалу сайта у нас не было. Из-за этого мы совершили вторую ошибку — не задали правильных вопросов разработчикам. В свое оправдание могу сказать только одно: если какое-то дело для тебя совершенно новое, ты не можешь догадаться, какие вопросы правильные. Завредакцией указала в качестве примерного образца сайт журнала другого вуза, а в остальном, по ее собственным словам, сформулировала требования в духе «вот с такими перламутровыми пуговицами». У меня же требований к внешнему виду сайта не было никаких, и я сказала: «Как сделаете, так и будет хорошо».
Через некоторое время разработчики принесли нам ноутбук, на котором продемонстрировали, как сайт выглядит и работает, и по нашей просьбе порекомендовали хостинг. Под их наблюдением мы заключили договор с хостинг-провайдером и зарегистрировали для сайта доменное имя.
Завредакцией рассчиталась за выполненную работу, и какое-то время всё было хорошо. Мне показали, как наполнять сайт содержанием, что-то я запомнила, а что-то так и нет. К тому времени, как у меня накопилась кучка вопросов, из двух разработчиков остался только один (второй защитился, и завредакцией утратила административные рычаги воздействия на него).
Оставшийся аспирант был крайне недоволен тем, что я постоянно лезла к нему с вопросами, на связь выходил редко и в конце концов заявил, что его делом была только разработка. О написании инструкций, технической поддержке и обучении бестолковых гуманитариев азам контент-менеджмента с ним никто не договаривался, и подписываться на это не входило в его планы. Заведующей пришлось привлекать мне на выручку других своих аспирантов, магистрантов и студентов, и их совместными усилиями изначальная структура сайта (работающего под управлением CMS Joomla) была сильно модифицирована в целях максимального упрощения. И всё равно мне было трудно справляться с сайтом. Загружать новые данные я худо-бедно научилась, а вот редактировать уже загруженные было по-прежнему тяжело. Я понятия не имела о том, что такое динамические сайты, и тщетно пыталась в режиме администрирования сайта искать страницы с нужным мне названием и расширением html. Их не было. Для меня оказалось большим неприятным сюрпризом то, что статические сайты (микроскопический опыт работы с которыми у меня был) давно уже канули в Лету, а в динамических сайтах страничек просто не существует до тех пор, пока к ним не обращаются. И если обратиться к одной и той же странице 20 тысяч раз подряд, она 20 тысяч раз послушно будет создана заново.
И это было еще полбеды. Настоящая беда пришла, когда закончился календарный год. С ним закончились все шаблоны, созданные разработчиками для примера. Для новых выпусков журнала в следующем календарном году нужно было всё создавать самой. Инструкции для нашего конкретного сайта у меня не было. Я почитала общие инструкции по Джумле и с грехом пополам создала набор категорий для нового года. Даже обрадовалась, что вроде бы всё получилось. Но, как оказалось впоследствии, греха было намного больше половины. Я заметила, что содержание номеров журнала, расписанное по статьям с помощью моих новых категорий, выглядит не так, как раньше. Откуда-то появились поля, которых прежде не было. Я поудивлялась, но решила, что это не страшно. Подумаешь, непривычно выглядит! Лишь бы работало.
В этом состояла третья ошибка. Внезапно мы начали получать сообщения от хостинг-провайдера о том, что наш сайт превышает допустимый объем трафика и чрезмерно перегружает хостинг. Все советы, содержащиеся в разделе «Часто задаваемые вопросы» на хостинге, я послушно выполнила, но это не помогло. А хостинг-провайдер продолжал слать грозные письма. В самых категоричных выражениях от нас требовали решить проблему превышения трафика, иначе в предоставлении услуги хостинга нам будет отказано. В университете мне помочь никто не мог или не хотел, и в отчаянии я попросила своего мужа взглянуть на злополучный сайт. Муж сразу же задал правильный вопрос: «А ты в курсе, что у вас комментарии к статьям открыты?»
Разумеется, я была не в курсе. Научные статьи — не сообщения в соцсетях, комментарии им не нужны. Модерировать комментарии и ставить защиту от злоумышленников было некому и некогда. В шаблонах, созданных разработчиками, ненужные функции были отключены. Но я-то не подозревала ни об их существовании, ни о том, что при создании категорий всё, что не требуется, надо самостоятельно отключать. Через бесхозные комментарии полезла мощная армия спам-ботов, именно это и стало причиной превышения объема трафика. Бороться с проблемой я пыталась примерно так, как звучит издевательский совет по борьбе с тараканами: «Загоните всех тараканов под шкаф и отпилите у него ножки». Я удаляла комментарии и отключала возможность комментирования постатейно. Управляющего элемента более высокого уровня, который устранил бы функцию комментирования сразу по всему сайту, я не нашла. И конечно же, пока я ковырялась, хостинг-провайдер устал ждать и выполнил свою угрозу. Нас вежливо попросили удалиться с хостинга.
Здесь сбылось пророчество начальника ИВЦ. Мы приползли падать к нему в ножки и Христа ради просить пустить наш журнал на хостинг университета. Точнее, ползти пришлось завредакцией. Меня начальник ИВЦ в упор не видел и мои попытки поговорить с ним считал нарушением субординации. К концу моей трудовой деятельности в университете он смягчился и переменил отношение ко мне, но тогда было так. Он некоторое время тешил самолюбие созерцанием коленопреклоненной заведующей и на разные лады повторял, что он так и знал, предупреждал, чем вся затея кончится и тому подобное, но в конце концов смягчился. Снова напоминаю, что я гуманитарий, и прошу извинить меня за упрощенный взгляд на сложные системные объекты и процессы. Насколько я поняла, нашему сайту как потенциально небезопасному объекту было выделено некое особое место на хостинге, нечто вроде карантина, под охраной специальных программ. Там он продолжал работать под Джумлой, как было задумано разработчиками. Но если для посетителей сайта ничего не изменилось, то администрирование стало еще труднее. Отныне выполнения каждой команды в режиме административной работы с сайтом приходилось ждать минуту и дольше. По всей видимости, защитные системы мешали сайту создавать динамические странички. Я закричала: «Караул, ну невозможно же так работать!» Завредакцией снова вступила в переговоры с кафедрой, готовившей специалистов по информационным технологиям, и волевым усилием двух заведующих (редакцией и кафедрой) системным администратором был назначен несчастный студент. От него я наконец-то получила инструкцию по управлению сайтом, а благодаря его ответам на вопросы, возникшие у меня после прочтения этого документа, и у меня кое-что начало проясняться в голове. Студент починил элементы интерфейса, надломленные усилиями по упрощению сайта и окончательно отказавшие после перехода на университетский хостинг. Правда, вникать в чужую работу слишком глубоко он не стал, посчитал простое решение наиболее надежным, благодаря чему в нескольких местах сайта появились милые моему сердцу статичные html-страницы. Общими усилиями мы со студентом рассортировали обратно по номерам журналов смешавшиеся в беспорядочную кучу статьи. Он создал запас нужных категорий с правильно установленными ограничениями функций еще на пару лет. Но всё хорошее когда-нибудь заканчивается. Студент завершил обучение, и я опять осталась с сайтом один на один.
Исчерпав запас созданных студентом шаблонов, в начале очередного календарного года я совершила очередную ошибку. Статичная html-страница, содержавшая перечень всех выпусков журнала за все года, позволила мне увидеть, что год является категорией. Но ведь журнал ежеквартальный, следовательно, в году четыре номера и нет такого выпуска, который содержал бы материалы за весь год. На этом основании я решила, будто бы можно сделать еще одно упрощение: для следующего года категорию не создавать. Тем более что в англоязычной версии сайта годы выпуска перестали быть категориями после 2015 года. Ничтоже сумняшеся я привела русскую версию к упрощенному стандарту английской и… инструкция перестала работать. Это теперь я понимаю, что иначе и быть не могло. Студент писал инструкцию без учета столь существенного упрощения. Но тогда я впала в панику: как же так, всё делаю как написано, а результата нужного не получаю?! Содержание выпусков журнала на русском языке перестало отображаться на сайте. Я засыпала выпускника, бывшего администратора, письмами, но получила от него суровую отповедь: он больше не учится в этом вузе, договор с ним никто не продлил, оплату до сих пор произвели не полностью, так что не о чем нам разговаривать. Напоследок он посоветовал проверить ссылки. Методом мучительного перебора вариантов весьма нескоро я нашла такой вариант русских ссылок, который был очень похож на английские, и это сработало. Пропавшие русские статьи появились каждая под своим номером и под нужным годом. Сказать не могу, какое облегчение я испытала! Будто гора упала с плеч.
Но тут выяснилось, что борьба с сайтом забирает слишком много рабочего времени. Журнал входит в Перечень ВАК, распространяется по подписке, а потому должен выходить вовремя. Это — первоочередная задача, а всё остальное потом, если и когда останется время. И я была вынуждена свести наполнение сайта к минимуму. Загружала только номера полностью и файлы отдельных статей, аналитическую роспись номеров вести перестала, как и пополнять базу данных об авторах. Сайт на три четверти зачах. Печальная история.
Но у нее всё-таки может быть хороший конец. Основному научно-техническому журналу университета была поставлена задача войти в международные базы данных. Одно из условий вхождения в них — развитый двуязычный сайт, самостоятельный по отношению к сайту издающей организации. Руководство вуза закупило у 1С-Битрикс соответствующую лицензию. И я прочитала в рекламном проспекте к ней, что минимальное количество сайтов, на которое эта лицензия распространяется, — не один, а два. Теоретически есть возможность перевести оба журнала на единую техническую платформу с удобным быстрым администрированием. Но это уже другая история, и рассказывать ее не мне. С октября 2019 года я больше не работаю в университете.
6 технических вещей, которые вы должны знать как администратор веб-сайта ‐ Webbuilders Group
Если вы не являетесь техническим специалистом и управляете контентом своего веб-сайта (часто это делается в системе управления контентом или «CMS»), вам необходимо знать, как выполнять некоторые общие действия. Я перечислил некоторые повторяющиеся проблемы, с которыми, как мы видели, боролись администраторы нетехнических веб-сайтов.
Примечание. В этом блоге я не сосредоточил внимание на инструкциях для , как выполнить эти задачи, отчасти потому, что они разные для Mac и ПК (и это сделало бы блог намного длиннее). То, как вы достигаете каждого из них, также будет меняться со временем с изменением технологий. Вы, как администратор веб-сайта, должны быть в курсе «как». Хорошей новостью является то, что в Интернете есть масса простых инструкций. Например, найдите «как сделать снимок экрана на ПК». Как сказал Эдисон, «Гений — это один процент вдохновения и девяносто девять процентов пота». Практикуйтесь и постоянно бросайте вызов себе, чтобы сделать эти задачи обычными. Удачи всем администраторам сайта!
6 технических вещей, которые вы должны знать как администратор веб-сайта:
- Знайте, как сделать снимок экрана. Скриншот — это просто файл изображения, в котором фиксируется все, что в данный момент видно на вашем экране. Возможность делать скриншоты важна по многим причинам, но, в конечном счете, это позволяет вам легко поделиться моментальным снимком того, что вы видите, с кем-то еще. Например, если вам трудно описать что-то, что вы видите, другу, вы можете просто сделать снимок экрана и отправить ему изображение по электронной почте.
- Научитесь просматривать веб-страницы с вкладками. Большинство современных веб-браузеров (программное обеспечение, которое вы в настоящее время используете для просмотра этой страницы) предлагают так называемый «просмотр с вкладками». Короче говоря, он позволяет открывать несколько веб-сайтов в одном браузере и значительно упрощает навигацию между ними без необходимости открывать и закрывать кучу окон. Это особенно полезно при управлении веб-сайтом, потому что вы можете открыть серверную часть CMS на одной вкладке, а общедоступный интерфейс — на другой.
- Знать адресную строку. Когда вы посещаете веб-страницу, например страницу, на которой вы находитесь, ваш веб-браузер отображает местоположение страницы в Интернете в «адресной строке». Обычно он находится в верхней части веб-браузера, и для этой страницы адрес должен выглядеть так:
http://webbuildersgroup.com/blog/6-techy-things-you-should-know-how-to-do- as-a-website-administratorЭтот адрес часто называют «URL». Важность этого заключается в том, что иногда вы можете захотеть поделиться адресом просматриваемой страницы с коллегой или техническим специалистом, поэтому важно понимать, как поделиться этим адресом.
- Знать, как изменить размер и/или обрезать изображение. Изменение размера изображения — это просто вопрос увеличения или уменьшения его размеров или размера файла. Обрезка — это обрезание определенной части изображения или изменение его формы в соответствии с предустановленным полем изображения. Если вы вставляете изображения в контент веб-сайта, оба навыка могут быть очень ценными. Чаще всего вы, вероятно, захотите узнать, как уменьшить размер файла изображения: это ускорит загрузку вашими посетителями, а в некоторых случаях потребуется (например, если вы снимаете большое изображение с цифровой камеры, он может не загружаться на ваш веб-сайт без предварительного уменьшения размера).
- Практика копирования и вставки с помощью горячих клавиш. Большинство пользователей знают, как выделить текст, а затем скопировать и вставить его с помощью меню файла или щелчка мыши, но также можно копировать и вставлять с помощью клавиатуры. Это немного отличается между Mac и ПК, но знание того, как копировать текст с помощью сочетаний клавиш, не только сэкономит вам много времени при управлении контентом, но в некоторых системах потребуется.
- Ознакомьтесь с текстовым редактором CMS. Все системы управления контентом разные: от WordPress до SilverStripe, у каждой есть свой набор функций и способов выполнения определенных задач. Тем не менее, большинство популярных CMS (две из которых мы уже упомянули) используют общий редактор форматированного текста для редактирования контента, и поэтому, изучив его, вы часто сможете применять эти знания, если когда-либо будете использовать другую CMS. Независимо от того, какой текстовый редактор использует ваша CMS, вам должно быть удобно выполнять следующие задачи: вставка изображения, создание таблицы и управление ею, управление текстом, добавление/редактирование/удаление ссылок и разрыв одной строки. два. Удобство работы с редактором форматированного текста и задачами, о которых мы упоминали, улучшит макет ваших страниц и ускорит работу с контентом.
Обзор средства администрирования веб-сайта
- Статья
- 000Z» data-article-date-source=»ms.date»> 22.10.2014
- 5 минут на чтение
Инструмент администрирования веб-сайта позволяет просматривать и управлять конфигурацией веб-сайта через простой веб-интерфейс.
Чтобы получить доступ к инструменту администрирования веб-сайта, в меню Веб-сайт щелкните Конфигурация ASP.Net .
Следующие ссылки содержат дополнительную информацию о том, как работать со средством администрирования веб-сайта:
Вкладка «Безопасность» средства администрирования веб-сайта
Вкладка приложения средства администрирования веб-сайта
Вкладка поставщика средств администрирования веб-сайта
Внутреннее устройство инструмента администрирования веб-сайта
Конфигурация веб-сайта
Параметры конфигурации веб-сайта хранятся в файле XML с именем Web.config, который находится в корневой папке веб-сайта. Инструмент администрирования веб-сайта позволяет изменять конфигурацию сайта без необходимости вручную редактировать файл Web.config. При первом использовании инструмента администрирования веб-сайта для администрирования определенного веб-сайта, если файл Web.config не существует, инструмент администрирования веб-сайта создает его. По умолчанию инструмент администрирования веб-сайта также создает базу данных в папке App_Data веб-сайта для хранения данных служб приложений, таких как информация о членстве и ролях. Для большинства параметров изменения, сделанные в инструменте администрирования веб-сайта, вступают в силу немедленно и отражаются в файле Web.config.
Унаследованные настройки
Настройки по умолчанию для веб-сайта автоматически наследуются из любых файлов конфигурации, существующих для компьютера или для веб-сервера в целом. Например, веб-сервер может иметь настройки по умолчанию, которые применяются ко всем сайтам на этом сервере. Используя Инструмент администрирования веб-сайта, вы можете создавать и изменять настройки для вашего конкретного веб-сайта, которые не унаследованы, и вы можете переопределять унаследованные настройки, как это разрешено настройками всего сайта. Если настройка была унаследована и не может быть переопределена, она отображается серым цветом, чтобы показать, что она отключена в Инструменте администрирования веб-сайта.
Требования
Инструмент администрирования веб-сайта входит в состав инструмента веб-разработки Microsoft Visual Web Developer. Чтобы использовать инструмент администрирования веб-сайта для администрирования веб-сайта, учетные данные пользователя для учетной записи пользователя, под которой вы запускаете Visual Web Developer, должны иметь разрешения на чтение и запись в файл Web.config и папку App_Data приложения, управляется. Если вы не можете управлять конфигурацией веб-сайта с помощью средства администрирования веб-сайта, обратитесь к системному администратору.
Функции
Инструмент администрирования веб-сайта имеет интерфейс с вкладками, который группирует связанные параметры конфигурации на каждой вкладке. Вкладки и параметры конфигурации, которыми они управляют, описаны в следующих разделах.
Вкладка «Безопасность»
Используйте вкладку «Безопасность» для управления правилами доступа, помогающими защитить определенные ресурсы на веб-сайте, а также для управления учетными записями и ролями пользователей.
Вы можете указать способ использования веб-сайта — из Интернета (общедоступно) или из интрасети (в локальной сети). Это, в свою очередь, указывает тип режима аутентификации, который будет использовать веб-узел. Интернет-сайты используют систему членства ASP.NET, где вы определяете индивидуальные учетные записи пользователей. ASP.NET использует систему безопасности для ограничения доступа к определенным учетным записям пользователей или ролям, которым принадлежат учетные записи пользователей. Веб-сайты интрасети используют проверку подлинности Windows, при которой пользователи идентифицируются по информации для входа в систему Windows.
Вкладка «Приложение»
Используйте вкладку « Приложение » для управления различными настройками, связанными с веб-сайтом, включая следующие: код из любой точки веб-сайта.
Настройки SMTP, которые определяют, как ваш сайт отправляет электронную почту.
Параметры отладки и трассировки.
Автономные и оперативные параметры, которые переводят веб-сайт в автономный режим (закрывают его) для выполнения обслуживания или перевода новой базы данных Microsoft SQL Server Standard edition в оперативный режим.
Вкладка Provider
Используйте вкладку Provider для тестирования или назначения поставщиков для членства и управления ролями для веб-сайта. Поставщики баз данных — это классы, которые вызываются для хранения данных приложения для определенной функции. По умолчанию средство администрирования веб-сайта настраивает и использует локальную базу данных Microsoft SQL Server Standard Edition в папке App_Data для веб-сайта. Вместо этого вы можете использовать другого поставщика, например удаленную базу данных SQL Server, для хранения членства и управления ролями.
Как использовать инструмент администрирования веб-сайта
Использование инструмента администрирования веб-сайта аналогично использованию других веб-сайтов на основе форм. Общая процедура заключается в том, чтобы открыть Инструмент администрирования веб-сайта, выбрать соответствующую вкладку, а затем настроить параметры, доступные на этой вкладке. Большинство изменений вступают в силу немедленно.
Как получить доступ к инструменту администрирования веб-сайта
Чтобы получить доступ к инструменту администрирования веб-сайта, в меню Веб-сайт щелкните Конфигурация ASP.Net .
Рекомендации
В следующих разделах приведены некоторые рекомендации по работе с Web Site Administration Tool.
Перезапуск приложения при сохранении
Большинство изменений параметров конфигурации, которые вы делаете в Инструменте администрирования веб-сайта, вступают в силу немедленно. Это требует перезапуска веб-сайта, к которому применяется изменение. Поскольку это приведет к потере текущих активных сеансов на веб-сайте, следует внести изменения в конфигурацию промежуточной или разрабатываемой версии веб-сайта перед публикацией этих изменений на рабочем сервере.
Сохранение настроек
Большинство изменений настроек конфигурации, которые вы делаете в Инструменте администрирования веб-сайта, вступают в силу немедленно. Для настроек, для которых в интерфейсе средства администрирования веб-сайта есть специальная кнопка Сохранить , оставление средства администрирования веб-сайта бездействующим или предоставление средству администрирования веб-сайта тайм-аута перед нажатием кнопки Сохранить приведет к потере изменений настроек конфигурации. .
Тайм-аут
В качестве меры безопасности средство администрирования веб-сайта истекает после определенного периода бездействия. Любые настройки, которые не вступили в силу немедленно и не были сохранены, будут потеряны. Если срок действия инструмента администрирования веб-сайта истек, закройте браузер, а затем снова откройте инструмент администрирования веб-сайта в новом окне.