pantheon-systems / solr-power Goto Github PK

Index is attempted on custom fields but they are not included within results

We should include a widget so it's easy for people to try this out on an existing site.

We should provide an improved status page as part of the first screen of admin UI.

• It should do a ping and report the status (which will surface if something is wrong right away)
• We can also show the current count of indexed posts, comments, pages, etc.

It will be beneficial for developers to have all filters in this plugin documented on the GitHub Wiki.

We need a script for converting this github project to publish via SVN to wp.org/plugins. There are a few already out there, eg:

http://scribu.net/blog/deploying-from-git-to-svn.html

https://danielbachhuber.com/2012/09/30/git-in-my-subversion/

And some tools that could help:

https://github.com/benbalter/WP-Readme-to-Github-Markdown

It would be great to make something that we can share w/others on this. Would be an excellent best-practice to share.

The goal is to have a "scripts" directory in the plugin that includes a shell script to do the translation/release in a repeatable way. We can rely on the local script-running user having all appropriate access credentials.

Bonus Points it would be great to lay out a pattern for doing development work on Pantheon as well, pulling changes from a Pantheon site repo into this repo via git subtree merge. That would be a separate item in the scripts directory.

Pre-requisite for #14 - we have a little shim in Solarium. We should subclass instead like the proper OOPers that we are.

Create an extension for the Debug Bar plugin to debug Solr queries.

There is a bug to where only 10 items(posts/pages/etc) get indexed.

Right now we bail if the request is in the admin area of is being done via AJAX. However, if we want to support use-cases like autocomplete or general purpose WP_Query() overriding, we probably can't continue to do that:

https://github.com/pantheon-systems/solr-power/blame/master/includes/class-solrpower-wp-query.php#L29

There is some inline CSS and JS in the options page that would be better abstracted out to dedicated resource files.

In the plugin header we see references to matt weber but it isn't clear what the relationship is. We should clarify that this is a fork.

Currently we rightly block the activation of the plugin on a Pantheon site where Solr isn't enabled. That's nice.

We should add a link to documentation for this though.

How should indexing be handled in a multisite environment?
Should each site have their own admin page or just one main page for the network admin?

CC: @joshkoenig

For users who want to work with the plugin locally, we should have a short "how-to" guide for getting Solr running locally.

Page-links for paginated posts produce 404s

Disabling the Output Result Pager option does not seem to remove page-links as assumed (not sure that's the intent behind the option though?)

The settings page routing is broken. Probably caused by #19.

• examples/example.custom_field_query.php
• edit readme.txt

Upon activation of the plugin all public posts, pages, and attachments should be indexed automatically.

I am a big fan of what the boys at Alley Interactive did here:

https://github.com/alleyinteractive/es-wp-query

Making the Solr backed available for complex queries would be an excellent way to support scalability and speed for sites with a lot of content.

This is a Pantheon specific thing, but I want to handle it better for a good first time experience.

When the plugin is first enabled, the developer needs to post the schema.xml file before search can actually work. Otherwise it will 404, leading to an unhandled exception from Solarium.

I think we should make posting the default schema.xml a part of enabling the plugin.

We also need to figure out how to catch the 404 and provide a helpful error message to the admin. This will happen when users first push the plugin into a new environment, and if they are cloning the DB they may not go through the enable step again. Catching the 404 and having a friendly error message would make for a better experience.

Currently the single admin page has severak sections:

1. Solr server status and configuration
2. Index options
3. Result options
4. Actions
5. Debug (solr query)

We should separate these out into their own tabs and forms, so they can be documented and utilized separately, and it will be easier for customers to set up solr.

Feature Request

Create a drop down within Indexing Options that allows the user to index existing public custom fields

I downloaded the master, added it to a WP site on Pantheon. Trimmed off the "-master" bit from the folder (named "solr-for-wordpress"), ensured that the SOLR addon was enabled, and then activated the plugin. Can access the settings and save changes, but cannot execute any of the actions ("Check Server Status", "Optimize Index", etc.).

Don't enable, display admin warning, etc.

Currently, the interface for the WP Solr plugin only allows searches for string values. While this is useful for the layman, most developers who are using Solr require the ability to test more complicated queries. The Pantheon's Drupal Solr Module does this well. One can run something like:

/select?fl=label,bundle,ts_ol_full_text&fq=bundle:bill%20AND%20ts_ol_full_text:property&wt=json

...and return results with the Drupal Solr module. Being able to do the same in Solr Powr would be invaluable.

We should support actions from the plugins settings page in wp-cli.

• Check Server Settings
• Optimize Index
• Delete All
• Repost schema.xml
• Index Searchable Post Types

We should also consider informative commands.

• info should return ping status, Solr server IP address, Solr server port and Solr server path.
• stats should return a table of indexing status by post type

I think these two would create a minimum viable product. Additional commands can be items from the indexing tab in the plugin settings such as setting the default search operator.

is there any way we can index only products ?

We should get up to 3.3.0. However this is not a priority for the first (alpha) release.

On a couple other Pantheon plugins now, we're using Behat to verify the plugin works as expected on Pantheon (e.g. pantheon-systems/wp-redis#103). It would be cool if Solr Power did this too.

At a high-level, here's how it works:

• We're using Circle (in addition to Travis) to automate the creation and destruction of a Pantheon environment for an existing Pantheon site. In accordance to our existing naming scheme, you'd use solr-power as the site name.
• bin/behat-prepare.sh creates the environment, pushes the current plugin copy up, activates it, and performs any other configuration steps needed.
• bin/behat-test.sh runs the Behat tests against the created environment
• bin/behat-cleanup.sh removes the environment after the tests are done running.

You can likely copy and lightly modify most of the referenced pull request. I'd be keen to get your input on the documentation, and implementation generally.

cc @stevector

From PR #74

PHP Fatal error: Call to a member function ping() on a non-object
get_solr() return NULL until Solr server configuration has been done.

We should check if the environment variables are set and, if not, display an WordPress dashboard warning to the user rather than having a fatal error.

To go along with #12 (a search widget), we need to include out-of-the-box search results.

The initial vanilla results should be equivalent to WP core search results except the default sort should be by relevance rather than date, and of course they would be fetched from the Solr index.

This will prevent developers from needing to do a theme-override to experience the power of search results.

When you've got a lot of context to index, doing it via the web UI is le suck.

Better would be this:

> wp-cli solr index --count=100
Indexing the next 100 posts
..........
Done! 100 posts sent to index in 7.16s

I think this plus a few other things could be enough for a 0.3 release!

Rather than having the following throughout:

$server = array(
    'ping_status' => $ping ? 'successful' : 'failed',
    'ip_address'  => getenv( 'PANTHEON_INDEX_HOST' ),
    'port'        => getenv( 'PANTHEON_INDEX_PORT' ),
    'path'        => SolrPower_Api::get_instance()->compute_path(),
);

We should have a method on the API class that returns this data, for use by the options page and CLI.

schema.xml should be sent to Solr automatically when the plugin is deployed to another environment (Multidev to Dev and up to Live)

see solr-for-wordpress-on-pantheon.php#L446

Per @allan23 we're best off using a consistent slug on these lines:

https://github.com/pantheon-systems/solr-for-wordpress/blob/master/solr-for-wordpress-on-pantheon.php#L1293

https://github.com/pantheon-systems/solr-for-wordpress/blob/master/solr-for-wordpress-on-pantheon.php#L1580

https://github.com/pantheon-systems/solr-for-wordpress/blob/master/solr-options-page.php#L205

We should make the slug align with the name we pick as resolution to #19

WPCS (https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards) is a series of PHP Codesniffer Sniffs to ensure a codebase adheres to WordPress' coding standards. We should set it up for the project, as we already have for https://github.com/pantheon-systems/wp-redis et al.

Setting up WPCS involves:

• Defining the dependencies in composer.json https://github.com/pantheon-systems/wp-redis/blob/master/composer.json#L11-L12
• Adding the grunt phpcs step, and defining associated dependencies https://github.com/pantheon-systems/wp-redis/blob/master/Gruntfile.js#L20-L28
• Having Travis call the Codesniffer step https://github.com/pantheon-systems/wp-redis/blob/master/.travis.yml#L39-L43

Once it's set up, we'll need to:

• Update all files to adhere to WPCS

We need to get some unit tests and system tests in place for this project to be able to move fast going forward.

Starting this issue to collect/prioritize test criteria.

The options page is not saving preferences. Checkboxes are going un-saved, and key text fields are being filled-in by Array. This is the result after un-checking "index pages" and then clicking "Save Changes":

Not "index pages" is still checked, and the two text fields below have Array as their value.

Could be related to #19 as a name-spacing issue?

We should be using WordPress coding standards.

Commits for updated formatting should be made independently of other commits.

WordPress coding standards for PHP_CodeSniffer will be useful.

[31-Aug-2015 12:22:21 UTC] PHP Parse error: syntax error, unexpected '[' in /srv/bindings/89d174f37673485283ee1f869b9d854d/code/wp-content/plugins/solr-for-wordpress/vendor/solarium/solarium/library/Solarium/Core/Client/Adapter/Curl.php on line 156

if ($endpoint->getOption('ssl')['local_cert']) {
           curl_setopt($handler, CURLOPT_SSLCERT, realpath($endpoint->getOption('ssl')['local_cert']));
       }

This site is using PHP 5.3

Case:
#44014

@joshkoenig @erik-pantheon

wp-content/plugins/solr-power/vendor/solarium/solarium/library/Solarium/Core/Client/Adapter/Curl.php:156

and i am not able to index products in live environment

Right now the defauly search query will still return posts sorted by created order. I think the default should be to sort them by their relevance (score). It would make for a pretty nifty demo:

• Before: Here are your Vanilla search results in date posted. (sad trombone)
• After: Behold! Solr Powered search results, which pulled an older post to the top because it's clearly more relevant. (gong!)

One of these isn't necessary:

Feature Request

Create a drop down within Indexing Options for indexing custom post types containing public content

Even manipulated to sets to 100 from the config page https://monosnap.com/file/bM3fyHDdaB8XyJsGurHawwpW0Z8R04
or using this file includes/class-solrpower-options.php

Is there a way to increase result value from 10?

I think we can jump from 4.3 to 4.5 in the README.

In the future this could be part of the automated test/release process. :)

facepalm - http://martinfowler.com/bliki/TwoHardThings.html

In preparation for release, I shortened the name of this project, which created a conflict with an existing plugin upstream, as well as creating issues with the admin UI. Mea culpa.

Alternate Names

• Apache Solr for WordPress / apachesolr-for-wordpress
• SolrPress / solrpress

Feel free to add your own in the comments.

We should extend s4wp_build_document() to include indexable attachments from the Media Library so that Tikka can do it's thing and make that part of the equation.

https://github.com/pantheon-systems/solr-for-wordpress/blob/master/solr-for-wordpress-on-pantheon.php#L245

One of the best features of a Solr backend is the ability to easily "facet" the search query. We should make it easy for users to discover this power. Using the built-in categories to power a basic "Faceted Search" widget would go a long way towards this.

Other primitive facets to consider:

• Post type
• Author
• Date (month?)