WPSolr free
Forum Replies Created
-
The contact form is located in the header and footer of our website. We don’t typically sell ready-made plugins, but we offer a complete service for search, recommendations, and AI data integration.
(like ingesting pdfs, docx, xlsx, pptx with undefined.io or Docling. Or ColPali)
WPSolr free is only working with self-hosted engines.
Using Kubernetes gives you scalability and fault resistance, as data and queries are distributed across nodes.
But Docker is great. The plugin description has a link to install Weaviate on Docker.
You can edit wpsolr-free/wpsolr/core/classes/models/post/class-wpsolr-model-meta-type-post.php,
function get_fields() {...}
Or comment the use of this function in file wpsolr-free/wpsolr/core/dashboard/dashboard_settings.inc.php:$model_type_fields = $model_type_object->get_fields();
Your modifications will be lost in next update, but it should be enough as a workaround.
If true, this means you have 1 million+ custom field names in your system (not values, names). Screen 2.2 tries to display those 1M+ names, which is impossible.
Can you try this SQL statements?
SELECT distinct meta_key
FROM posts as POSTS INNER JOIN postmeta as POSTMETAS
ON POSTS.ID = POSTMETAS.post_id
WHERE POSTS.post_type = 'your_custom_post_here'2.2 Data tab?shows your post types and custom fields. To do so, WPSolr has to scan the wp_postmeta table, which takes a long time and memory resources on the server for 1.4 million post types.
I ran out of memory for the browser tab
This should not happen, unless you have many distinct custom field names in your wp_postmeta. Usually, you should “only” have tens of custom field names for millions of custom field values.
Try to find out how many custom field names and how many custom fields you get in your database.It means you can choose which WP archive queries will be replaced with WPSOLR queries: search, categories, tags, authors, post types …
With OpenSolr, the situation is different.
WPSOLR will upload configuration files automatically, but also configure a great deal of things on your behalf: archives, search, facets and sort plugins, recommendation widget, and so on.
Just follow the setup wizard, and you should be running in seconds.You should execute the red instructions first, as they will install the necessary Solr config files before WPSOLR creates the Solr index (aka “core”).
I advise to:
– Restart a new index setup in WPSOLR, with a new label and name
– Execute the red instructions
– Let WPSOLR create the index with the “Finish” button
Let me know how it goes.Hello,
WPSOLR does not work with PHP 7.4. It requires PHP 8.1.
Would you like to continue investigating your issue?
Nice.
Vespa.ai offers multi-stage hybrid ranking and supports ColBERT models, which are very trendy these days.
With Weaviate, you will get ready-to-use multimodal models with local embedders, like CLIP.
I installed the WP RSS Aggregator plugin, and it appears to use a five-year-old version of Twig (v1.41.0) from Twig’s repository.
Unfortunately, I don’t believe we can run easily both Twig versions simultaneously without conflicts.
You might edit the Twig file in one of the plugins to wrap the twig_cycle() function in a conditional to prevent redeclaration.
In the WPSOLR plugin, open the file:/home/[notdisclosed]/public_html/wp-content/plugins/wpsolr-free/wpsolr/core/vendor/twig/twig/src/Resources/core.php
Wrap the
twig_cycle()
function definition with a check to see if it’s already been declared:if (!function_exists('twig_cycle')) { function twig_cycle() { // function code here } }
But the same issue on other methods could also happen.
This error occurs because the
twig_cycle()
function is being declared twice. It seems that both the WP RSS Aggregator plugin and WPSOLR plugin are using the Twig templating library, and each is loading a different version or a conflicting part of Twig, leading to a function redeclaration.WPSOLR always try to use the latest external library version, which includes the latest security fixes.
Here Twig 3.14.0 (2024-09-09)