[Xerte-dev] Re: Xerte Install

Sat May 4 11:36:07 BST 2013

Thanks, I'm glad I'm not the only one who can fat-finger this kind of data!

I can't find anything in the basic.sql code, however, that CREATEs a 'user'
table. Could this be a problem?

I've also run into a problem exporting LOs now, possibly because the
temporary directory isn't defined? Could be default to /tmp - that's
supposed to have write privileges for all users, isn't it. I'm not sure what
the equivalent is in Windows, however.

Kindest regards, Thomas

From: xerte-dev-bounces at lists.nottingham.ac.uk
[mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of Tom Reijnders
Sent: 04 May 2013 11:12 AM
To: For Xerte technical developers
Subject: [Xerte-dev] Re: Xerte Install

I fixed issue 2 yesterday evening. Too many people ran into that one.

Op 4-5-2013 11:21, Pat @ Pgogy schreef:

2 is simple enough to fix

3 is a problem - would want want the maximum size to be a php ini limit, or
a XOT specific limit? Different sites on the same server?

On 3 May 2013, at 22:09, "Thomas Rochford"
<thomas.rochford at jiscadvance.ac.uk
<mailto:thomas.rochford at jiscadvance.ac.uk> > wrote:

Good Evening Tom,

First of all a Big Thank you for your work. As a small gesture of
appreciation I have produced a document describing how to upload Learning
Objects directly, via FTP, webDav etc. If you think it will be useful,
please put it somewhere appropriate on the Community web site. It would be
good if you (and others?) looked it over, in case I have made some mistakes
or you feel things could have been explained a little better.

It was an 'interesting' experience, and I learnt a number of lessons that
may help others.

1)      My website is hosted in Germany (I believe) by  1&1 Internet. They
offer quite a restricted interface compared with some others that I have
seen and I think that there is a ridiculously long period in which pages are
cached by the server. For no reason that I can think of, Tom's new code
(replacing the 'fault' occasioned by not having a temporary upload file
specified in php.ini with a 'warning') did not seem to work. Furthermore any
changes that I made (e.g. trying to FORCE it to go to page1.php by
commenting out just about everything else), didn't work either, so I suspect
the output had been cached by the server (I flushed the browser cache). So I
just went straight to page1.php. It might be a good idea to add a link to
this at the bottom, rather than using the 'submit' button.
In any event generating a fault or warning of this kind is probably not
necessary. Because I wanted to do a clean installation in order to test it
out, I had to re-import my existing LOs as .zip files and they all worked
well, provided they were less than the ridiculously low level set by 1&1.
But of that more anon.

2)      The next problem I encountered was to do with database.php. 1&1 do
not allow you to choose the name of your database and give it a thoroughly
unmemorable and easily mistyped name and the same for the managing account.
I tried to copy and paste them from the web page but, in doing so,
inadvertently copied an extra space at the end of the database name.
Although I went back via the browser and re-entered it correctly, the
installer still had the pesky space and I had to get rid of it by editing
database.php. Would it be possible to overwrite any existing database.php
with a new one every time the data is re-submitted , because I'm sure other
users could also make this mistake.

3)      The final problem I had was uploading some LOs. I'm sure it was size
related, but the generic failure message about only accepting zip files
threw me for a few minutes. I would like to suggest that the upload script
checks to make sure that the size of the object to be uploaded is less than
'max_file_uploadsize' (or whatever the php variable is called), before
attempting the upload and warns the user that they will have to transfer the
data manually if it is.

Because of problem #3 I documented the process of FTP'ing data directly up
to Toolkits as described in the attached document.

I should point out that this could be quite an issue because many smaller
organisations are either using the free JANET-hosted web servers, or other
commercially hosted ones which have locked down php.ini files which they
will not change, so some or all of these points may have relevance to a
significant number of other users.

Apologies for the length.

Kindest regards, Thomas

<Manual Uploads to Xerte.docx>

_______________________________________________
Xerte-dev mailing list
Xerte-dev at lists.nottingham.ac.uk <mailto:Xerte-dev at lists.nottingham.ac.uk> 
http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev

_______________________________________________
Xerte-dev mailing list
Xerte-dev at lists.nottingham.ac.uk <mailto:Xerte-dev at lists.nottingham.ac.uk> 
http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev

-- 
--

Tom Reijnders
TOR Informatica
Chopinlaan 27
5242HM Rosmalen
Tel: 073 5226191
Fax: 073 5226196

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nottingham.ac.uk/pipermail/xerte-dev/attachments/20130504/01c464c9/attachment.html>