Kurt Flint

That makes us very happy. Thank you.

Hey there, it might relate to what I’m about to open, a bug where there is the ngnix.conf file path in the field marked as being the backup location string on the setup page.

Maybe see “UI error on Settings page” to see if that helps when they get to it.

++

Kurt

Nice www.ads-software.com bug! Add a tag, get your unfinished post cleared. Bummer.

I had this. Bizarrely enough it just went away. When I know why I’ll upgrade my review back to five stars.

+1

Fred isn’t noted for answering unless you buy a service contract. He has even been known to tell users who have not anted up that he has more important things to do on the product etc, since support to non subscribers doesn’t make him any money.

I can’t remember the cure, but there may not be one. It is just a “strict standards” notice, useful for future proofing your code. It is there so that plugin and application programmers can write clean, secure code.

I suggest that you look into changing your production errors string in php.ini or your fast cgi conf file to include ~strict. You also need to be sure that you are logging in production of course, not displaying errors. Many people just turn all errors off unless there is some problem, but that means paying attention ot your strict, notice and doingitwrong notes while you develop, and catching all the real world edge cases in testing. Not always possible ??

Here, I give you a present, not a link to another cache product, but https://www.ads-software.com/extend/plugins/log-deprecated-notices/ which separates out your depreciated messages during dev and keeps track of them. That way your debug streams are uncluttered by endless repetition with every page load!

You know, I don’t recall at all how I fixed that. New Relic would pick it up in production and alerted me to it. I’m thinking maybe Fredrick did fix it, or maybe an upgrade to APC fixed things up.

Good luck!
Kurt

Thank you Jeremy, you have just resolved a problem I had on the back burner… Yoast gives you a whole page of handy settings to take that over with and mess up at will, so it was easily fixed.

@yardhype, I believe that you intended to say in your initial post that you are using all-in-one-seo, and you will notice that it is on the “list of evil plugins” in Jeremy’s code. I suggest moving to Yoast, who has a handy export/import tool so that your valuable efforts in A-I-1-SEO (which we used to use too) will not be lost.

Good luck, hope to see your issue closed soon.

Kurt

Oh, by the way, I thought of you, and maybe this could be handy: https://www.loudnoises.us/the-noise/the-truth-behind-wpautop/

It comes with a good explanation of what not to do and why, as well as a good work around on a case by case basis. Less labor intensive than lovingly hand marking up all the entries (full disclosure, I work at a news organization and we often just use interns to insert paragraphs, breaks and divs in our posts. I kid you not. They get to learn layout, we get to keep programming).

I hate to say it, there is only one real solution. You only use probably 8 tags 98% of the time, and 5 of those are h1-h5. Ditch the view tab. Its useless. I know it sounds cruel, but replacing that view tab with something that just does a clean preview of what you have in the text tab in an iFrame would be 100% more useful. Then replace the text tab with Ace or Codemirror for code color and completion(lots of plugins doing that already, but compatibility with the view tab tends to be low), put the codemirror/ace input field under a rectangle of that iFrame preview and script the iFrame to be refreshed every time the user presses the enter key in the edit window.

Just like the editing programs we used to use about 20 years ago. I used to be very attached to one named something with “frog” in it. I also had a similar css editor at one time with the same layout that beats everything I have used since.

Has anyone seen anything like this “in the wild”?

As for your question, don’t forget to back up first, and depending on how good you are with sql and regular expressions, it might be easiest if you have less than a couple hundred posts to prepare them by hand. Just xerox the sql table and modify them manually is what I would do, up to maybe 300 then I’d use queries and stored procedures, and after that if it is complex i’d just sift for tags and swap them out using php or C#. Regex builds character they say.

Time’s fun when you are having flies – the forgotten frog code editor

Not worried in the slightest. Unless you are adding so much that it is slowing delivery of your page you are ok. And you should be running all of your HTML through a comment stripper/minifier on the way out anyway, which will streamline your output. Try using one based on Tidy.

Cheers!

That sounds sort of like what I mean. Not that your plugin’s settings get lost, but that the relationship between widgets and widget areas get lost.

I think it is this bug, just showing in your product.
Steps:
Find or create a theme with three or four widget areas.
Fill all areas with Widgets
Find a theme with one less widget area, lets say two.
Change theme to second theme.
* At this point there should be a widget or two in the unused widget area or even an unused widget area waiting to have widgets moved out.
Switch back to original theme
* Widgets will no longer be in original widget areas
* The widgets in the unused widget store will be missing from their original areas
* The remaining widgets will have shifted, usually up a number of spaces most likely to match the number of widgets in storage.

And now for the bad news, all of the above happens any time I add or remove a widget area myself, or one of your grids.In fact I am about to do it now, and I will have to rebuild my whole site’s widget order. If this is just the way WordPress is written, we need to get widgets a lifetime instance ID that they keep until they are disposed of, regardless of which theme is loaded, and then make themes and plugins give guid’s of some sort to their widget areas and keep an index of last known widget area positions for every widget they have known.

Does that make sense? It doesn’t sound that hard to fix. In fact, I have a project in mind that would cover it, if my assumptions and guesses are all correct and not just a house of cards. It just bugs me, I forgetfully find myself doing it before informal client shows and meetings too much.

You have all figured out that the sitemap is dynamic by now, right? Not just something that will be generated and then sit around aging in your root directory? Just request it from your browser and you will see it.

I have seen problems with it timing out under load, but Google Webmaster Tools (which everyone should be signed up for) no longer complains since I have identified the FQDN of sitemap_index.html in my robots.txt. I have also gone ahead and put in the FQDN of the other major sitemaps, Posts, Categories, etc. that are generated on the fly. The index does little but identify the URL of those anyway.

Good luck! (I won’t be watching this thread, this was a “drive by helping” for today)

Hey there @tarrion: Did you transfer your config to pastebin, or did the moderator just delete your code and leave the thread crippled? May as well delete the whole thread if so.

I’ll post any significant differences if I find them between what I have and what you have. The mods from W3TC seem pretty good though. And to get the code in your install page Nic you check a box at the bottom of the General page. At least that is what works for me, though I have never UN checked it now that I think about it!

Kurt

It is a false positive. Your provider is just scanning all scripts for eval statements which should never be used on production web servers.

No disrespect to the author, but I advise that you do not install this plugin. You are asking for trouble. Eval + WP API access == your user data gone in a heartbeat. If you don’t know about the eval thing right up front, no offense intended to you, but you are playing with fire.