Note: You are currently viewing documentation for Moodle 2.0. Up-to-date documentation for the latest stable version is available here: Installation FAQ.

Talk:Installation FAQ: Difference between revisions

From MoodleDocs
(another method pagename# takes to top)
(Tidy, left 2 which could be still relevant)
 
(12 intermediate revisions by 7 users not shown)
Line 1: Line 1:
I just added a bunch of questions/answers to the generic FAQ page, and then looked at this to see how it was done (backwards, I know). Clicking on the item jumps you down to the question... but should we add a link to jump back to the top? -- D.I. 29jan06
:Nice idea, say jump back to the TOC,  I bet even a <nowiki>[[Installation FAQ|Top]]</nowiki> might even work.  I think it is possible to force a ToC (by <nowiki>__TOC__</nowiki> , so the alternative would be to create a section with just the ToC called Table of Contents, then a <nowiki>[[Installation FAQ#Table_of_Contents|Top]]</nowiki> would also work.  I will try it --[[User:chris collman|chris collman]] 12:47, 5 January 2008 (CST)
::Just discovered that [[Sandbox#]]  or [[Installation_FAQ#]] will take you to the start of the page.  Using the <nowiki>__TOC__</nowiki> as an address does not work. 
-----
Someone said, under : My pages show fatal errors such as : Parse error, call to undefined function: get_string()
"You may also be running a php script which uses short open tags, e.g. instead of <?PHP ?> it uses <? ?>. Either replace short tags with conventional ones, or set this line in php.ini:
" short_open_tag = On"
However, this should never be necessary with Moodle code. If you find any short tags anywhere, file a bug in the [http://moodle.org/bugs/ bug tracker] against the affected code. There are currenly none of these abominations anywhere in the Moodle core code.[[User:Tim Hunt|Tim Hunt]] 01:19, 26 July 2006 (WST)
---
Agreed. Such an "abomination" should not be in Moodle core code but the person who deleted it doesn't appreciate the point. This comment was added to help those who are having problems with code which is '''not''' part of Moodle core, e.g some of the third party blocks which are mentioned frequently in forums. There is no reason, IMHO, why fellow Moodlers in such a predicament would not turn to this FAQ for help. - Ken Wilson 25 July 06
---
Sorry, my mistake. I had not reallised that this actually happened with contrib modules. I'll reinstate the that bit (but keep my point about reporting the problem so it can be fixed).[[User:Tim Hunt|Tim Hunt]] 01:19, 26 July 2006 (WST)


== Memory limit limitations ==
== Memory limit limitations ==
Line 34: Line 14:
--[[User:John Walling|John Walling]] 14:56, 11 May 2007 (CDT)
--[[User:John Walling|John Walling]] 14:56, 11 May 2007 (CDT)


== PHP Debugging Configuration Confusion ==


The FAQ about getting a blank page during installation refers the reader to the FAQ about checking your error logs, which tells him/her to add ini_set calls to config.php if using Moodle 1.7 or higher. Problem is, during installation ''there is no config.php file''! This leaves the reader in a quandry, and so the instructions should be clarified. See http://moodle.org/mod/forum/discuss.php?d=87473
== Comprehensive Solutions ==
 
I think that because the docs tend to be a response to specific issues more often than not,  they are sometimes written in global language,  when the recommendation, solution, advice, etc should be more local.
 
By way of example,  while suggesting that the web server need be restarted after editing php.ini may in some cases be true as a matter of practice,  it is not true in many cases and it creates confusion because it does not address the underlying issue,  that the programs must be made aware of configuration parameters, and how various programs do that (especially in shared environments).  
 
Another example is some of the discussion about where php looks for php.ini files.  In trying to answer a question for a user on this point I came across quite a bit of inconsistency, but in fact no cite to the php docs setting out how php.ini is sourced. I know RLE has worked hard at helping folks understand that php.ini is used differently under PHP4 than under php5,  and that it is important to sort out which version you are using before thrashing about changing files ;=}
 
In any event,  I did a quick strike through and amendment on the FAQ,  but as has been discussed elsewhere, I am concerned that one or more of the referenced docs may all potentially create confusion over such questions....14:10, February 12, 2009 Marc Grober


--[[User:Richard Enison|Richard Enison]] 08:00, 4 January 2008 (CST)
::Good points as usual.  Context can really impact the suggested solution for administrators or teachers. I just did a major edit of this page. I did create a new [[PHP error logs]] page from existing material in this FAQ page. But did not feel comfortable in placing the most commonly asked questions at the top. I know just enough to understand that it is an important file :)  --[[User:chris collman|chris collman]] 09:47, 13 February 2009 (CST)

Latest revision as of 11:06, 25 August 2011

Memory limit limitations

Each method of increasing memory limit has limitations.

.htaccess
directive php_value memory_limit may be disabled by the host
php.ini
no root access

There is a third way which may or may not work:

php function ini_set
Example: ini_set("memory_limit","24M");
It will not work if phpinfo() does not show Configure Command '--enable-memory-limit'
see http://us.php.net/manual/en/ini.core.php#ini.memory-limit

On my host, none of the three methods will work. I am limited to 8M memory per PHP session. I am able run the basic installation. I haven't seen the dreaded error "Allowed memory size of Xxx bytes exhausted" but I expect it at some point.

--John Walling 14:56, 11 May 2007 (CDT)


Comprehensive Solutions

I think that because the docs tend to be a response to specific issues more often than not, they are sometimes written in global language, when the recommendation, solution, advice, etc should be more local.

By way of example, while suggesting that the web server need be restarted after editing php.ini may in some cases be true as a matter of practice, it is not true in many cases and it creates confusion because it does not address the underlying issue, that the programs must be made aware of configuration parameters, and how various programs do that (especially in shared environments).

Another example is some of the discussion about where php looks for php.ini files. In trying to answer a question for a user on this point I came across quite a bit of inconsistency, but in fact no cite to the php docs setting out how php.ini is sourced. I know RLE has worked hard at helping folks understand that php.ini is used differently under PHP4 than under php5, and that it is important to sort out which version you are using before thrashing about changing files ;=}

In any event, I did a quick strike through and amendment on the FAQ, but as has been discussed elsewhere, I am concerned that one or more of the referenced docs may all potentially create confusion over such questions....14:10, February 12, 2009 Marc Grober

Good points as usual. Context can really impact the suggested solution for administrators or teachers. I just did a major edit of this page. I did create a new PHP error logs page from existing material in this FAQ page. But did not feel comfortable in placing the most commonly asked questions at the top. I know just enough to understand that it is an important file :) --Chris collman 09:47, 13 February 2009 (CST)