Hi,
I did notice you mentioned this elsewhere as well once, but i never heard back from you when I followed up to hear where you ar experiencing this problem?
There’s no file edits being pushed without the user typing them in them selves, so I’m very curious where this is happening and what edits you are making at the time.
I don’t remember mentioning this issue ever before.
I was using string locator with a theme called “CityNews”, which uses Visual Composer, to find the string “twitter” in the theme files, because the twitter share button has had issues with correctly escaping double and single quotes for the url (that is an issue with the theme, not with string locator)
My problem with string locator came when I opened a theme file called wp-content/themes/citynews/inc/shortcodes/inc/shortcodes_set.php. The file opened and the nice, color coded editor displayed. I edited line 506, which was part of a PHP if statement, to remove the esc_attr function to see how that would affect the output of the share links.
After saving the file, I noticed I was getting header errors on some pages in WordPress (after trying to update posts, view media files, etc), and the error messages directed me to the last line of that file I had edited. It turns out that after editing and saving the file a few times, there were a few newlines appended to the end of the file. I was able to erase the newlines and the problem was fixed, but I can tell the editor is adding newlines because every time I load the file, a newline has been added to the end of the file. So by opening, editing, and saving the file repeatedly, newlines get appended to the file repeatedly.
Here is a video of opening the file, finding a newline at the end, erasing it, saving the file, and seeing the newline still appear at the end: https://youtu.be/RsxvcUG8_sE
Thank you very much for that detailed report, the video it self actually helped a ton! (And it is possible it was someone else reporting it, they just wrote the exact same text so it seemed very much like the same person, so apologies for the mix-up there)
Normally it’s not advisable to end .php files with the closing ?> tag because it can easily lead to problems with headers already being sent messages, as is the case here, but I also do recognize that edits are some times made where this is not easy to be aware of, I’ll be pushing a patch for this shortly as I’ve already created a fix and just need to test it before I make it public.
Again, thank you for the report, the video really helped make it more understandable
I’m glad I was able to be precise enough to be helpful. Yea, ending files in ?> isn’t best practice before headers, but I was dealing with already written third-party theme files that had them in there. I’ll make sure to check that when editing theme files in future until you release the patch. Thanks for responding!
If you wish to test the patched version (1.8.1-beta1) you can grab it from the development archive at https://downloads.wp.xz.cn/plugin/string-locator.zip now 🙂 It should discover that and also filter them out to help keep your files reasonable
Just pushed out 1.8.1 which handles cases where the file is being ended with closing PHP tags.
