Re: New Feature Ideas for the Future: Private Mailing Lists
Well, a symlink is basically the unix version of a windows shortcut. It sounded like you may have been able to keep with a single WP install by linking the protected directory into your original WP install.
Now I don’t have a whole lot of experience with WP so I am not 100% sure where the folder would go. In drupal it would be something like sites/default/files so I am going to guess with WP.
For example:
DaDa protect: <shared home dir>/public_html/protected_files
WP install: <shared home dir>/public_html/wp
A symlink in “<shared home dir>/public_html/wp/wp-content/protected_files” that points to “<shared home dir>/public_html/protected_files” would present that protected file directory to wordpress as if they were in the WP install dir.
The problem is that in a shared hosting environment, typically one only gets FTP access and I am not entirely sure one can create a symlink with ftp.
The other option is that most shared hosting providers allow you to create aliases for you website. So, instead of a symlink, you could do:
“Alias /wp/wp-content/protected_files <shared home dir>/public_html/protected_files” so requests to that url would be served from the protected files dir.
The reason I am interested in this is that I am sure there are others who would be interested in integrating WP with DaDa and you may have stumbled upon feasible recipe. As long as one does not need two instances of WP.
Plus, right now, I am under the weather and trying desperately to keep my mind active..
From: Mary Ann Kelley [mailto:maryann@PROTECTED]
Sent: Tuesday, October 15, 2013 8:16 PM
To: Dada Mail Developers
Subject: [dadadev] Re: New Feature Ideas for the Future: Private Mailing Lists
Um, no. I have no idea what a SymLink is. I'm really just lurking on this list with the occasional comment/question as I am not a developer in any sense of the word. I know just enough hacks to get myself into trouble, to be honest.
There is only one private folder (it does have subfolders for downloads) and I just put the second WP install in that directory. The entire install directory is protected and is fed via iframe (I tried to find a more elegant solution but nothing worked and I had to limit the number of hours I was putting into this) to the main install. It's only 3 pages in the entire private install but there are many files linked from those 3 pages that needed to be private as well. I would have just hand-coded the pages but I was trying to make it so that if someone took over for me that doesn't know coding that they would be able to update the pages.
Now that Justin has updated the plugin so that it adds to instead of overwrites .htaccess in the protected directory, a hack to the Protect Directory plugin file wouldn't be necessary. At the time the script just replaced .htaccess with Dada code, which is obviously a problem if other scripts (like WP) are writing to the file as well.
But I still had to install the second WP installation if I wanted to use the Dada protect directories plugin to protect WP pages because it avoids the account sync issues. There is just no way that I would be knowledgeable enough to hook Dada profiles to WP users so that a single session logs you into both - way beyond my skillset. (Also, not sure if it matters, but this particular install is on a shared server so I don't have the same flexibility that I have on my server.)
Warm regards, |
On Oct 15, 2013, at 4:12 PM, AJ Fasano wrote:
One other question, did you try putting all the private file folders under a common directory and sym-linking it into the wordpress directory. Then there may not have been a need to hack the DaDa core and install another wordpress, assuming apache allows FollowSymLinks and/or SymLinksIfOwnerMatch to be overridden.
Post: mailto:dadadev@PROTECTED
Post: mailto:dadadev@PROTECTED
- This mailing list is a public mailing list - anyone may join or leave, at any time.
- This mailing list is a group discussion list (unmoderated)
-
Start a new thread, email: dadadev@dadamailproject.com
This is the developer discussion mailing list for Dada Mail.
If you are just looking for support Dada Mail, consult the message boards at:
https://forum.dadamailproject.com
Documentation for Dada Mail:
Specifically, see the Error FAQ:
https://dadamailproject.com/d/FAQ-errors.pod.html
To post to this list, send a message to:
mailto:dadadev@dadamailproject.com
All subscribers of this list may post to the list itself.
Topics that are welcome:
- Constructive critiques on the program (I like, "x", but, "y" needs some work - here's an idea on how to make this better...)
- Bug/Error reports
- Bug fixes
- Request For Comments on any changes to the program
- Help customizing Dada Mail for your own needs
- Patches
- Language Translations
- Support Documentation/Doc editing, FAQ's, etc.
- Discussion of any changes that you would like to be committed to the next version of Dada Mail -
Dada Mail is on Github:
https://github.com/justingit/dada-mail/
If you would like to fork, branch, send over PRs, open up issues, etc.
Privacy Policy:
This Privacy Policy is for this mailing list, and this mailing list only.
Email addresses collection through this mailing list are used explicitly to work within this email discussion list.
We only collect email addresses through our Closed-Loop Opt-In system.
We don't use your email address for any other purpose.
We won't be sharing your email address with any other entity.
Unsubscription can be done at any time. Please contact us at: justin@dadamailproject.com for any help regarding your subscription, including removal from the mailing list.
All mailing list messages sent from us will include a subscription removal link, which will allow you to remove yourself from this mailing list automatically, and permanently.
All consent to use your email address for any other purpose stated at the time of the mailing list subscription will also be revoked upon mailing list removal.