1.7.9 bug?

ben · January 14

Just upgraded to the latest 1.7.9 release to fix the media import issues I was having, and it seems to have broken my "lists & vocabularies" page under the "manage" menu. It partially loads, but with no CSS. See img below…

seth · January 14

This happens when you navigate there for the first time? I'm not seeing that in any of my test installs. We did test lists & vocabularies. Please make sure you've replaced all of the views with current 1.7.9 ones as there was a change there in this release that unpatched would cause this.

If you're sure it's all updated properly then please take a look in the logs and let me know if there's any clue there.

Thanks,

Seth

ben · January 19

Yeah it's a consistent issue, and I've definitely updated the entire views folder – just did again to double check.

Which log? Apache?

jmorga3 · January 20

We've noticed the search function is wonky and doesn't pull the items we search for but literally everything else. Programmer checked the DB schema but it's up to data. I tried rebuilding search index but that didn't work. He's still tooling around with it but will submit a bug if he can't figure it out.

seth · January 20

Could you be a bit more specific about the precise nature of the problem?

jmorga3 · January 21

When performing a basic or advanced search for an item's identifier, the search takes a long time and doesn't return the desired identifier. It's difficult to tell why it returned results that do not relate to the searched identifier. We rolled back to the previous version and the search performed as expected.

seth · January 21

Have you tried reindexing?

ben · January 22

Seth, bumping this thread w/r/t my question about which log I should be looking at regarding the original issue I posted about…

seth · January 22

Yes please look in the Apache log. Also, you can add this line in your setup.php file to force on-screen error messages:

ini_set("display_errors", "On");

We'll need an error message if we're going to be able to figure out the cause of this.

ben · February 9

Fatal error: Uncaught Error: Call to undefined method ListItemSearch::suggest() in /var/www/html/themes/default/views/administrate/setup/Results/no_results_html.php:36 Stack trace: #0 /var/www/html/app/lib/View.php(329): require() #1 /var/www/html/app/lib/View.php(297): View->_render('/var/www/html/t...') #2 /var/www/html/themes/default/views/administrate/setup/Search/ca_list_items_search_basic_html.php(46): View->render('Results/no_resu...') #3 /var/www/html/app/lib/View.php(329): require('/var/www/html/t...') #4 /var/www/html/app/lib/View.php(297): View->_render('/var/www/html/t...') #5 /var/www/html/app/lib/Controller/ActionController.php(163): View->render('Search/ca_list_...', false) #6 /var/www/html/app/lib/BaseSearchController.php(313): ActionController->render('Search/ca_list_...') #7 /var/www/html/app/controllers/administrate/setup/ListsController.php(84): BaseSearchController->Index(Array) #8 /var/www/html/app/lib/Controller/RequestDispatcher.php(273): ListsController->Index(Array) #9 /var/www/html/app/lib/Contr in /var/www/html/themes/default/views/administrate/setup/Results/no_results_html.php on line 36

ben · February 9

I'm also getting this on almost any page I navigate to: Warning: fsockopen(): unable to connect to tls://[redacted domain]:443 (Connection refused) in /var/www/html/app/lib/Controller/Request/RequestHTTP.php on line 660

VaclavCerny · February 10

Hello Ben,

i have had similiar problem with server connecting to itself.

During debugging it i have realized, that also comandline command "curl https://mytestdomain/" returned something like

fial, wrong certificate or something like that.

Our testserver is running with self-signed certificate, but the same may apply with internal certificate authority, etc..

I have repaired it with adding my cert authority public cert to /usr/local/share/ca-certificates and running update-ca-certificates on Debian server.

I hope, some part of my answer will help you.

Vaclav

seth · February 10

Yes, that error indicates the server cannot connect to itself, which is done to trigger the search indexing queue. The may be a certificate problem, or sometimes a DNS configuration issue.

To resolve this you can set disable_out_of_process_search_indexing in app.conf to a non-zero value and simply disable the triggering. You won't see these errors any longer, but all indexing will be done in-request, which can make saves in the editor slow to return if the changes trigger a lot of indexing.

You can also override the defaults for internal connections to get it working in your environment. The relevant options in app.conf are:

# Hostname to use when triggering out of process indexing
# By default the site hostname configured in setup.php is used but you can override it
# here if the hostname resolvable on the server differs from that used for incoming requests
out_of_process_search_indexing_hostname =

# Socket protocol to use when triggering out of process indexing. Maybe set to tcp or tls
# By default tcp is used when the incoming request is http and tls is used when https is employed.
# You can override it here to use a constant protocol.
out_of_process_search_indexing_protocol =

# Port to use when triggering out of process indexing
# By default the port used is 80 when the incoming request is http or 443 when https is used. 
# You can override it here to use a constant port.
out_of_process_search_indexing_port =

# Disable verification of SSL certificate when connection uses https.
# With some server/network configurations it may not be possible to validate the certificate
# when connecting internally to trigger indexing. You can disable certificate checks here if
# you need to. No data is transferred over the connection used to trigger indexing, but disabling
# certificate checks is never a great idea. It is recommended that disabling be done only as a 
# last resort.
out_of_process_search_indexing_dont_verify_ssl_cert = 0

1.7.9 bug?

Comments