Adam,

You'd be amazed how much better the process went after I saved the changes 
to settings.py. I'd been interrupted and forgotten I hadn't done that yet. 
I hate when that happens. Once I restart Apache, I should be good.

Thanks,
Martha


On Thursday, May 23, 2019 at 7:44:17 AM UTC-7, Adam Cox wrote:
>
> Hi Martha, thanks for the detailed information.
>
> Good note about the PACKAGE_ROOT setting. That must be a holdover from v3 
> settings which was never updated in those docs.
>
> I think most of the other things you mention stem from the STATIC_ROOT 
> setting. That is the only thing that determines where Django places the 
> directory and static files--if it is trying to create a directory where you 
> aren't expecting it, then the setting has not been set properly. I'd 
> recommend reading over our Settings Beyond the UI 
> <https://arches.readthedocs.io/en/stable/settings-beyond-the-ui/> docs to 
> make sure you have a clear understanding of the inheritance patterns, and 
> it's always good to checkout django's docs 
> <https://docs.djangoproject.com/en/2.2/ref/settings/#static-files> too.
>
> I didn't actually know that STATIC_ROOT is set in Arches projects by 
> default, and I can't think of a good reason for it to be set within 
> /var/www.... doing so requires that you do extra file-system permissions 
> (with chmod/chown). I usually put mine in a directory alongside the 
> project, or within the project as is shown in those docs.
>
> As for permissions, if STATIC_ROOT is a directory inside of my_project, 
> then whichever user you used to create the project should also have no 
> problem running collectstatic. Indeed, as you point out, /var (and all 
> other directories) have more restrictive permissions by default, which is 
> why in the example I put STATIC_ROOT in the project. I didn't realize, 
> however, that collectstatic makes the directory for you, so that is great 
> to know.
>
> Adam
>
> On Wed, May 22, 2019, 6:59 PM Martha S <[email protected] <javascript:>> 
> wrote:
>
>> Adam,
>>
>>  
>>
>> Just a heads-up on a problem and some 4.4.1 documentation changes needed 
>> with regard to setting up Apache to access the arches static files. 
>>
>>    - It turns out that clean installs of arches need to run 
>>    collectstatic, too, even if neither of the two conditions noted pertain. 
>>    The static files are not available to Apache. 
>>    - The procedure recommends creating a static folder under my project, 
>>    so I did, though I noted that settings.py already had a setting 
>>    STATIC_ROOT = /var/www/media, which does not exist. 
>>    - One of the lines I was directed to copy into settings.py is 
>>    STATIC_ROOT = os.path.join(PACKAGE_ROOT, 'static'); PACKAGE_ROOT is 
>>    undefined, so I imagine it should be APP_ROOT. 
>>    - I ran python manage.py collectstatic, which promptly failed, 
>>    because it attempted to create the directory      /var/www/media and the 
>>    user I was logged in as doesn't have sufficient permission. Looks like I 
>>    should keep the original setting for STATIC_ROOT, but I don't know 
>>    which files I need to get there. 
>>    - By default, /var permissions (at least on my 18.04 server) restrict 
>>    the root group to read and execute only, so even my root group member 
>> user 
>>    couldn't run the program.  
>>
>> Is there any way around having to change folder permissions at the root 
>> level? Is there a way to overwrite the default file destination at run 
>> time, for example? 
>>
>> Thanks,
>> Martha
>>
>> On Tuesday, February 6, 2018 at 8:11:49 AM UTC-8, Adam Cox wrote:
>>>
>>> Hi Dale, it sounds like you may have to continue to the next step in the 
>>> production documentation after all, 
>>> https://github.com/archesproject/arches/wiki/Basic-Production-Configuration#handling-static-files.
>>>  
>>> Could you try that out and let me know how it goes? I think your issue may 
>>> have to do with the static url and apache not interpreting Django's urls 
>>> correctly. I really don't know why that would be different for 4.1 from 
>>> 4.0, but perhaps those plugins which are showing errors are referenced in 
>>> the codebase in a different manner than the other plugins...
>>>
>>> One other note, related to your last post, I need to fix the link in the 
>>> docs so that the dependency installation link goes to 
>>> https://github.com/archesproject/arches/tree/stable/4.1.x/arches/install 
>>> instead of the master branch. Also, please note, the docs you should be 
>>> using are arches.readthedocs.org/en/ 
>>> <http://arches4.readthedocs.org/en/>*stable*, as opposed to /*latest*. 
>>> Stable is (and will alw bays be) docs for the latest stable release (i.e. 
>>> released to pypi) version of arches, where /latest is built directly from 
>>> the archesproject/master branch. I'll address this in your other post as 
>>> well.
>>>
>>> Adam
>>>
>>> On Tue, Feb 6, 2018 at 9:53 AM, Dale Lloyd <[email protected]> wrote:
>>>
>>>> I was able to serve Arches 4.0 with Apache, but cannot get a fresh 
>>>> install of Arches 4.1 to work correctly with Ubuntu 16.04.
>>>>
>>>> I ran the dependency install script,  
>>>> <https://github.com/archesproject/arches/blob/master/arches/install/ubuntu_xenial_setup.sh>then
>>>>  
>>>> installed Arches by following the instructions here 
>>>> <https://arches4.readthedocs.io/en/latest/installation/#installation>. 
>>>> I then followed the Serving Arches with Apache instructions here 
>>>> <https://github.com/archesproject/arches/wiki/Basic-Production-Configuration#serving-arches-with-apache>
>>>> .
>>>>
>>>> When I try to access the site with a web browser, I get text but no 
>>>> pictures. The apache error log shows:
>>>>
>>>> [wsgi:error] Not Found: /media/plugins/style-switcher.js
>>>> [wsgi:error] Not Found: /media/plugins/revolution-slider.js
>>>> [wsgi:error] Not Found: /media/plugins/one.app.js
>>>> ...
>>>>
>>>> The files are present in 
>>>> /home/user/Projects/ENV/lib/python2.7/site-packages/arches/app/media/plugins/
>>>>  
>>>> and the issue occurs even if the permissions on this folder are set to 777.
>>>>
>>>> Advice greatly appreciated.
>>>>
>>>>
>>>> -- 
>>>> -- To post, send email to [email protected]. To unsubscribe, 
>>>> send email to [email protected]. For more information, visit 
>>>> https://groups.google.com/d/forum/archesproject?hl=en
>>>> --- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "Arches Project" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to [email protected].
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> -- 
>> -- To post, send email to [email protected] <javascript:>. To 
>> unsubscribe, send email to [email protected] <javascript:>. For 
>> more information, visit 
>> https://groups.google.com/d/forum/archesproject?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Arches Project" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected] <javascript:>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/archesproject/9eab1dc6-0b04-47f3-b23b-a6b57e120377%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/archesproject/9eab1dc6-0b04-47f3-b23b-a6b57e120377%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
-- To post, send email to [email protected]. To unsubscribe, send 
email to [email protected]. For more information, 
visit https://groups.google.com/d/forum/archesproject?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Arches Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/archesproject/1f3f6310-02e6-4adb-a77c-fce9062517a7%40googlegroups.com.

Reply via email to