Drupal - Search showing preg_match error - php

I have a custom search going on in one of the website I am building in Drupal. Search works perfectly fine when the "Rebuild theme registry on every page." checkbox is selected on the Theme Configure page. However, when I uncheck it (for production), the search no longer works, the same page just reloads again on hitting the search button. Upon looking at the Recent Log Entries I found the error:
preg_match() expects parameter 2 to be string, array given in /var/www/devel_sites/SITENAME/docroot/modules/search/search.module on line 671.
Anybody got any ideas why my search would be depending upon the theme registry and how to fix this? I have a custom module for search and part of the functionality is in template.php.
Any tips are appreciated, thanks.

Without posting code (since the code is custom,) I don't think anyone can answer your question satisfactorily. However, if you don't mind modifying module code, simply do a is_array conditional before line 671 and if it is, implode the terms (or inspect it and get rid of any garbage.) Pass that string on to line 671.

I was (finally) able to resolve the issue and I am posting the resolution below in case someone else faces the same.
I started by moving all the functional logic from template.php to my custom module (I should have done it anyways and it seemed like it might be an issue) but it didn't solve it. I had to dig in my custom module code and that's where I found what the problem was. I was using the following to get the entered keywords:
$form_state['values']['processed_keys']
It turns out, when Rebuild Theme registry option is turned off, the above array value is overwritten by the theme registry and is being replaced by an empty array, hence causing the error in line 671 of the search module which, is expecting a string as the second argument, and not an array. Replacing the above with the below solved it for me:
$form['basic']['inline']['processed_keys']['#post']['keys']

Related

Bring result of PHP-Script to accepted field in TYPO3 FORM

So, it's my first question here - i found a lot of hints which all working for itself but im struggling now with the final step to get solved.
Guess it's very specific pointed to TYPO3-CMS V9 and higher.
I can also support with all of the Codes, for the moment i guess this will be better on request.
Task: Create a simple Productorderform for logged-in-users pointing just there specific products form the specific price-lists. -> solved by using PHP-Script working with a CSV-File, grabbing also some functions from TYPO3 itself to get needed parameters.
This PHP creates a DATALIST on runtime for the INPUT-Field producing the needed HTML-Code -> solved and working as expected.
Tricky part.
As TYPO3 offers a CORE-Extension called FORM and the Option to - REPEAT - the fieldset.
Also for TYPO3 there is an extension which allows to put PHP-Code directly to TYPO3 as a Content-Element.
FORM itself allows to put Content-Element to a form.
Working so far, but as described, the field (its value) is not recognized when i fire the send button.
So for some reason i have to predefine the trigger also.
I tried step for step to extend the predefined field in the php with the tags of an empty one, all(?) the surrouding DIV etc. to make FORM recognize this field as a "native" field, just extend in the main tag with ... list="prodlist" ...
Well, as you might see, i'm not a developer or programmer, i might have some skills and experiences to know where and how to go with the level (and timeframe) i have.
So i guess the final step might not be that far, but as we say here, i can't see wood because of trees...
The FORM structure by the way is saved to a YAML-file which might be also manipulated, but as i have seen, it gets the triggers -what- to parse in some way from the FORM created.
Many thanks for hints, ideas an hopefully noone was falling to sleep reading this question... ;)

Wordpress Fields getting swapped when having specific values

This is a strange one, but it seems like it should be really easy to solve.
I have a wordpress website Version 4.8.3. PHP 5.6.32.
Whenever I put in a specific value into the title field 6147989800 (or other fields) it get's swapped out on the front end with 8552226270.
I searched in every file on the server for some code (i suspect javascript) that is swapping out the numbers. No luck.
When I search the database the original number 6147989800 is there. But when I do a var_dump of the field is shows 8552226270 and it shows up as 8552226270 on the front end.
This switch happens when I put in 6147989800, 614.798.9800, and 614-798-9800.
I'm at a loss. Even stranger is that when I duplicate the website to a local instance and on a test server the swap doesn't happen.
Any ideas would be great. Thanks!
Thank you John Ellmore for your help. It did end up being a third party Javascript that was doing the phone swap.
I don't know how I missed it [smacks palm against forehead]

When duplicating a Wordpress page, it breaks and looks different

I tried duplicating a page in Wordpress in order to translate it for local users in different countries, but for some reason, even though it's the exact same page (it even looks the same inside wordpress preview) it just breaks and looks different (seems like a css problem of some sort, probably?)
The "nice" website is:
www.blaqkdesign.com/?noredirect=true
The one i'm having problem with:
www.blaqkdesign.com/mx/?noredirect=true
Side note: "noredirect" is the command used in order to bypass IP redirection
Any ideas on what could be happening? Thanks in advance!
I found that the second one missing of themify-builder-4534-generated.css?ver=17.09.19.04.52.54, it should be named themify-builder-2534-generated.css?ver=17.09.19.04.52.54
Difference is 4534 should be 2543, please try to change if possible.

How to cure a "Illegal string offset" php error in an unmaintained wordpress plugin

I am not a php programmer so this is as clear as mud to me.
Wordpress plugin is WP Custom Search Version: 0.3.26 It seems to be the only remotely usable plugin that will allow me to create a multi field search form for the sidebar of a site. It works reasonably well on my WAMP installation on the office PC but throws the error below when I moved it up onto the client's hosting on a GoDaddy VPS.
Warning: Illegal string offset 'preset' in /home/clubfund/public_html/wp-content/plugins/wp-custom-fields-search/wp-custom-fields-search.php on line 401
The error appears to refer to this section of the php code.
function process_shortcode($atts,$content){
return $this->generate_from_tag(array("",$atts['preset']));
}
Most answers to similar questions refer to confusion between string and array values. I wouldn't know where to start despite having read through many similar questions and solutions. Unfortunately the plugin creator doesn't seem to be able to respond to questions. I wondered if anyone here would be willing to help.
Many thanks in advance.
You probably have different error levels in production and development. The issue is probably happening locally as well, you just don't see it being logged. Anyways, the issue is that the array key preset doesn't exist in the $atts array.
To remedy this you could do this right above the return line -
if(!array_key_exists($atts, "preset"))
{
$atts["preset"] = "";
}
That will set the value to an empty string if it isn't already set.
If you aren't sure what is actually being passed in, you could do something like- var_dump($atts) or gettype($atts) to see if the type is even an array.
Do not put the shortcode in your template, put the long code:
<?php if(function_exists('wp_custom_fields_search'))
wp_custom_fields_search(); ?>
I also had the same problem and already this solved it.

Nusphere PHPEd: PHP Function Hints Lost Arguments?

My PHPEd suddenly stopped showing arguments and arg order in the hints, and now just shows a basic description of the function.
Before I go digging around in the config files, has anyone else had this problem?
Thanks!
Edit:
Sorry, I may not have been entirely clear on this. There is no problem with my own classes, only with the actual php functions.
Example:
How it used to work:
I type a PHP function, say strpos. As soon as I type the '(' at the end of it, I get the little yellow box, showing something like this:
int strpos ( string $haystack , mixed $needle [, int $offset=0 ] )
with the first argument bold. If I type it, and then a comma, it bolds the second arg, and so on. This is really nice, since PHP functions are a bit scrambled as far as argument order, and I don't have to look them up every time.
How it works now:
I type a php function, say strpos. As soon as I type the '(' at the end of it, I get the little yellow box. It says something like "strpos - Returns the numeric position of the first occurrence of needle in the haystack string."
There are no arguments shown, which makes the little box basically worthless - I know what strpos does, I just want a reminder of the argument order.
I think this may be a problem with the included PHPDoc, which I never use, but may be the source of the data for the hint box.
I did recently upgrade to 5.6, but ended up removing it and restoring 5.2. I installed to a different folder, and uninstalled from there, but it may have overwritten something in the original folder?
I'm using v5.2 (5220).
A complete re-install seems to have done fixed the problem. Perhaps it was a problem with a partial upgrade or a version mismatch on the settings.
What version of PhpEd are you using ? And did you made an update of PhpEd recently ?
As mentionned in the forum, that can modify the "Function Arguments Tooltip" feature behavior.
One way to check if this is linked to settings is to move the phped.cfgconfig file (save it), and let PhpEd recreates it with default values. If that does restore the tooltips, use a diff program to check what option may have been changed.
Do you see no hints for all classes, or only your own Php classes (in the latter case, this thread has some setting advices) ?
Note: the reason I ask for the version is because of this very recent thread, about PhpEd5.5:
In that case, the advice is to copy %PROGRAMFILES%\nusphere\phped\config\func.rel into %APPDATA%\nusphere\phped\config\ directory overriding the file in it.

Categories