CRM-16421 Work to get CiviCRM for WordPress in WordPress' official Repository

Getting back on this after delays on all sides (me and WP Plugin staff).

Comments from WP Plugin Team (based on review of CiviCRM WP Plugin version 4.6):

• I think the main issue here remains 'Is CiviCRM a separate, non WP, app, or is it a plugin?' Because it acts like both.
• 20megs is still huge, but it's okay now. I will note that installing it locally on VVV took FOREVER. So people will complain. A lot.
• The fact that, once installed, the plugin says it can't install civicrm is bad.
• Asking to connect the DB is one thing, but saying "And we will install that DB for you!" is another. Don't have it install, JUST have it connect. This is why the 'what is your plugin?' issue is still an issue. It's behaving like a plugin that connects to CiviCRM (see Yourls plugins as an example) but then it's installing things for you...
• Also I got this error: The user account used by your web-server - www-data - needs to be granted write access to the following directory in order to configure the CiviCRM settings file: //srv/www/vvv-ass/wordpress-plugins/htdocs/wp-content/plugins/files Why are you writing to the PLUGINS folder? That should never happen. You should write to wp-content/uploads/ if you have to. I would even suggest wp-content/uploads/civicrm/files/ to make sure no one gets derpy
• I did a quick check and you guys are calling wp-content in multiple places. Absolutely that has to be fixed before you go anywhere.

 elseif ($config->userFramework == 'WordPress') {
      $url = preg_replace(
        '|wp-content/plugins/civicrm/civicrm/|',
        '',
        $config->userFrameworkResourceURL
      );

$defaults['userFrameworkResourceURL'] = $baseURL . "wp-content/plugins/civicrm/civicrm/";

• When you hardcode in paths, or assume that everyone has WordPress in the root of their domain, you cause anyone using 'Giving WordPress it's own directory' (a VERY common setup) to break. In addition, WordPress allows users to change the name of wp-content, so you would break anyone who choses to do so. Please review http://codex.wordpress.org/Determining_Plugin_and_Content_Directories and update your plugin accordingly. And don't worry about supporting WordPress 2.x or lower. We don't encourage it nor expect you to do so, so save yourself some time and energy.

End WP Plugin Comments

All That said, it was not as bad as I expected. A few remarks related to these comment:

• VVV is standardly used in WP Core Development. I used to use it and abandoned as CiviCRM ran like a dog. VVV is a Virtual Enviornment – https://github.com/Varying-Vagrant-Vagrants/VVV It is awesome, but I like Buildkit Better
• I agree about the install routine, the errors on initial activation and the hard coded wp-content

To solve, I think that https://github.com/civicrm/civicrm-wordpress/pull/73 and https://github.com/civicrm/civicrm-core/pull/5728 on Issue https://issues.civicrm.org/jira/browse/CRM-16408 Should be merged into 4.7 branch so we can test throughout the Beta Cycle. These patches need updating/rebasing as they are from April and I can do that in the next week. I can accelerate if needed.

We need to rid ourselves of the wp-content hardcoding. This came up again today here: http://civicrm.stackexchange.com/questions/4940/wordpress-content-directory-setting This task can be reviewed in the fall Sprints – Maryland and Edale.

Let me know if there are any other tasks I should take on to get this started.

Updated PR for 4.7.

Would like to see these merged:
civicrm-core
https://github.com/civicrm/civicrm-core/pull/6629
civicrm-wordpress
https://github.com/civicrm/civicrm-wordpress/pull/85

https://github.com/civicrm/civicrm-wordpress/pull/87 and https://github.com/civicrm/civicrm-core/pull/6926 are the first two PRs merged related to this ticket.

These cleaned up the installer for WP relating to the database, hard coded wp-content and supporting legacy configurations.

Next steps are to test with alternate content directories and WP in a sub-directory.

Tested with alternate content directory, found some straggling 'wp-content' references. Grepped code base and corrected.

PRs:
civicrm-wordpress https://github.com/civicrm/civicrm-wordpress/pull/88
civicrm-core https://github.com/civicrm/civicrm-core/pull/6991

Update with current issues to solve:

1- https://wiki.civicrm.org/confluence/display/CRM/WordPress+installed+in+its+own+directory+issues
WP needs to work in a more complex directory structure. currently have working foks at https://develop.tadpole.cc/internal/civicrm-wordpress and https://develop.tadpole.cc/internal/civicrm-core which I am testing. PR to follow.

2 - issues on initial install with userFrameworkResourceURL see https://issues.civicrm.org/jira/browse/CRM-18221

PR submitted for shortcode button hardcoding – https://github.com/civicrm/civicrm-wordpress/pull/98

Status Update June 5th 2016:

From the initial comments from @ipstenu (above) the following still need to be answered:

• I think the main issue here remains 'Is CiviCRM a separate, non WP, app, or is it a plugin?' Because it acts like both.

• When you hardcode in paths, or assume that everyone has WordPress in the root of their domain, you cause anyone using 'Giving WordPress it's own directory' (a VERY common setup) to break.

The first bullet can be addressed in am email and when we submit. The second issue is tracked here https://issues.civicrm.org/jira/browse/CRM-17633

Further to this we need to create a CiviCRM account on wordpress.org and review the plugin guidelines here: https://wordpress.org/plugins/about/ and in detail here: https://wordpress.org/plugins/about/guidelines/

Reviewing these I see these items that we have to review:
A) You have to actually use the Subversion repository we give you in order for your plugin to show up on this site. The WordPress Plugins Directory is a hosting site, not a listing site.

B) No "phoning home" without user's informed consent. This seemingly simple rule actually covers several different aspects:

No unauthorized collection of user data. For example, sending the admin's email address back to your own servers without permission of the user is not allowed; but asking the user for an email address and collecting if they choose to submit it is fine. All actions taken in this respect MUST be of the user's doing, not automatically done by the plugin.

All images and scripts shown should be part of the plugin. These should be loaded locally. If the plugin does require that data is loaded from an external site (such as blocklists) this should be made clear in the plugin's admin screens or description. The point is that the user must be informed of what information is being sent where.

In general, things like banner or text link advertising should not be anywhere in a plugin, including on its settings screen. Advertising on settings screens is generally ineffective anyway, as ideally users rarely visit these screens, and the advertising is low quality because the advertising systems cannot see the page content to determine good ads. So they're best just left off entirely. Putting links back to your own site or to your social-network of choice is fine. If the plugin does include advertising from a third party service, then it must default to completely disabled, in order to prevent tracking information from being collected from the user without their consent. This is the method commonly known as "opt-in".

Note that if you do include what we consider to be "advertising spam", or attempt to game somebody else's advertising system, then we will not only remove your plugin, but also report your code to the advertising system's abuse mechanism as well. We do not react kindly to spam. Don't try it.

C) The plugin must not embed external links on the public site (like a "powered by" link) without explicitly asking the user's permission. Any such options in the plugin must default to NOT show the link.

D) All code changes to a plugin that has a Stable Tag of "trunk" must result in the version number being upgraded. For the trunk and tags method, trunk can be continually updated without version number changes, while tags should generally not be updated ever past the initial tagging.

Thoughts on the above:

A-- So we need to use subversion - this should not be an issue, we can push to SVN after distmaker runs. I do not see this as an issue

B-- No Phoning Home - our stats are important, so we need to work on a way to allow easy opt in

C-- The no empowered by CiviCRM would again mean a simple opt in/out

D-- Versioning has been discussed and we can comply with this, we just need a methodology

Lastly, we need to handle support by default all plugins have a support form much like: https://wordpress.org/support/plugin/civicrm-wp-profile-sync We can put a sticky notice up and direct users to stack exchange, but we will also need to monitor the tags to ensure no one 'ignores' that sticky.

Therefore, I will head back to CRM-17633 which is documented here: https://wiki.civicrm.org/confluence/display/CRM/WordPress+installed+in+its+own+directory+issues as this appears to be the last code blocker, the balance are policy and opt-in changes (which will involve code after decisions are made)

Submitted PRs against civicrm-core and civicrm-wordpress to reflect work done to date on CRM-17633 - WordPress in it's own subdirectory a blocker to resubmitting to the WP Repo.

Next steps are to update Installer with settings to support the following changes:

Update template for civicrm.settings.php

if (!defined('CIVICRM_UF_BASEURL')) {
  define( 'CIVICRM_UF_BASEURL'      , 'http://site.dev/wp/');
}
 /*
if (!defined('CIVICRM_UF_WP_BASEURL')) {
  define( 'CIVICRM_UF_WP_BASEURL'      , 'http://site.dev/');
}
 
if (!defined('CIVICRM_UF_ADMINURL')) {
  define( 'CIVICRM_UF_ADMINURL' , 'http://site.dev/wp/wp-admin/' );
}
*/

If wp-config.php has defined an alternate WP Content directory :

define( 'WP_CONTENT_DIR', dirname(__FILE__) . '/apps' );
define( 'WP_CONTENT_URL', 'http://site.dev/apps' );

Test to see if the option 'home' matches the option 'siteurl'

/

/get home url
 
get_option('home');
 
//result - http://site.dev/wp   
 
//get site url
 
get_option('siteurl');
 
 
//result - https://site.dev

If WP is in it's own directory these will not match

If either condition exists, then enable the below override in civicrm.settings.php

global $civicrm_setting;
// Override the resource url
$civicrm_setting['URL Preferences']['userFrameworkResourceURL'] = 'http://sites.dev/app/plugins/civicrm/civicrm/';

These changes to the installer are in addition to the details listed above (B, C, D)

WP Plugin testing has now moved to php 7 and mysqli is required

4.7.12-rc tested on php7 and it is working fine.

Work at Jefferson Sprint detailed: https://wiki.civicrm.org/confluence/display/CRM/WordPress+installed+in+its+own+directory+issues

Next Step - update installer so the last two manual steps detailed are done automatically.

https://github.com/civicrm/civicrm-core/pull/9106

Rebased on 4.7.19

Installer updated to create an "extra" file so no manual editing is necessary

No, I never resolved this issue. I had to put it in the root directory to get it working. Still running 4.6.27.

I'm sorry the 4.6.27 is my Drupal civi site. The Wordpress site is no longer a client. To resolve the problem I had to put the site in the root directory.