Answers.Body: <p>I don't feel that this is a good solution to the problem, but as requested, I'm reposting this as an answer. I "solved" this error by creating a symlink using:</p>
  
  <p><code>$ mkdir -p /var/lib/wordpress/var/lib</code></p>
  
  <p><code>$ ln -s /var/lib/wordpress /var/lib/wordpress/var/lib/wordpress</code></p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-11-17T20:55:12.360Z
Answers.LastActivityDate: 2018-11-17T20:55:12.360Z
Answers.UserDisplayName: Jeremy Malcolm
Answers.Body: <p>This is a shortcoming in CiviCRM, unfortunately. The problem is that CiviCRM tries to guess where WordPress and its resources are via directory traversal. This works (by and large) for "standard" WordPress installs but not for those where <code>wp-content</code> has been moved or where the CiviCRM plugin directory has been symlinked.</p>
  
  <p>Until this is remedied, your best bet is not to use the deb package and install WordPress manually in the <code>DirectoryRoot</code> location instead.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-09-18T17:42:44.107Z
Answers.Text: OK, thanks. The workaround that I have used for now is just to symlink `/var/lib/wordpress/var/lib/wordpress` to `/var/lib/wordpress`, and I should be able to do the same thing a bit more elegantly with some nginx configuration, once I figure it out.
Answers.UserDisplayName: Jeremy Malcolm
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-09-17T08:53:37.733Z
Answers.LastActivityDate: 2018-09-17T08:53:37.733Z
Answers.UserDisplayName: Christian Wach
Body: <p>I am using CiviCRM on Wordpress on Ubuntu where the Wordpress comes from a deb package, not from the original source. The only real difference that I know of is that Debian/Ubuntu split the Wordpress code into /usr/share/wordpress for the static PHP files, and /var/lib/wordpress for the content files and uploads.</p>
  
  <p>Anyway, probably because of some weird interaction between the Ubuntu package and CiviCRM, I end up with a whole bunch of resources trying to load from a path that starts with <a href="https://mydomain.com/var/lib/wordpress" rel="nofollow noreferrer">https://mydomain.com/var/lib/wordpress</a> and which creates a 404 error in the webserver log when it tries to access /var/lib/wordpress/var/lib/wordpress on my disk. What has obviously happened is that part of the filesystem path has accidentally been embedded into the URL for the resource.</p>
  
  <p>Problem is, I'm not sure where that setting comes from or how to change it. Can anyone verify this, or is it really just me? Should I report this as a bug against the Ubuntu package maybe? Among the resources that have the wrong path are:</p>
  
  <p><code>/uploads/civicrm/persist/contribute/files/delete-this-WjYpCHVDVl
  /uploads/civicrm/persist/contribute/index.php
  /plugins/civicrm/civicrm/js/wysiwyg/crm.ckeditor.js</code></p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-11-16T19:27:59.090Z
Comments.Text: Are you able to add your last comment and as Answer and then accept it so this can be closed off?
Comments.UserDisplayName: petednz - fuzion
Tags: <wordpress>
Title: Stock CiviCRM on Ubuntu package of Wordpress leads to /var/lib/wordpress/var/lib/wordpress/ paths
ThreadText: # Stock CiviCRM on Ubuntu package of Wordpress leads to /var/lib/wordpress/var/lib/wordpress/ paths
  
  (Asked by: username_0 on 2018-09-16)
  
  I am using CiviCRM on Wordpress on Ubuntu where the Wordpress comes from a deb package, not from the original source. The only real difference that I know of is that Debian/Ubuntu split the Wordpress code into /usr/share/wordpress for the static PHP files, and /var/lib/wordpress for the content files and uploads.
  
  Anyway, probably because of some weird interaction between the Ubuntu package and CiviCRM, I end up with a whole bunch of resources trying to load from a path that starts with <https://mydomain.com/var/lib/wordpress> and which creates a 404 error in the webserver log when it tries to access /var/lib/wordpress/var/lib/wordpress on my disk. What has obviously happened is that part of the filesystem path has accidentally been embedded into the URL for the resource.
  
  Problem is, I'm not sure where that setting comes from or how to change it. Can anyone verify this, or is it really just me? Should I report this as a bug against the Ubuntu package maybe? Among the resources that have the wrong path are:
  
  `/uploads/civicrm/persist/contribute/files/delete-this-WjYpCHVDVl
  /uploads/civicrm/persist/contribute/index.php
  /plugins/civicrm/civicrm/js/wysiwyg/crm.ckeditor.js`
  
  **Tags:** wordpress
  
  > **Comments:**
  > **username_1**: Are you able to add your last comment and as Answer and then accept it so this can be closed off?  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_0 on 2018-11-17. Score: 1
  
  I don't feel that this is a good solution to the problem, but as requested, I'm reposting this as an answer. I "solved" this error by creating a symlink using:
  
  `$ mkdir -p /var/lib/wordpress/var/lib`
  
  `$ ln -s /var/lib/wordpress /var/lib/wordpress/var/lib/wordpress`
  
  
  ---
  
  ### Answer by username_2 on 2018-09-17. Score: 0
  
  This is a shortcoming in CiviCRM, unfortunately. The problem is that CiviCRM tries to guess where WordPress and its resources are via directory traversal. This works (by and large) for "standard" WordPress installs but not for those where `wp-content` has been moved or where the CiviCRM plugin directory has been symlinked.
  
  Until this is remedied, your best bet is not to use the deb package and install WordPress manually in the `DirectoryRoot` location instead.
  
  > **Comments:**
  > **username_0**: OK, thanks. The workaround that I have used for now is just to symlink `/var/lib/wordpress/var/lib/wordpress` to `/var/lib/wordpress`, and I should be able to do the same thing a bit more elegantly with some nginx configuration, once I figure it out.  
  
  ---
  
  