Juniper

Loop:
1) Freeze N sites temporarily for “scheduled maintenance”.
2) Back up the table group for each site to keep Murphy’s Law at bay.
3) Copy those same table groups to an empty workspace database.
4) Run the optimization routine on the workspace tables.
5) Copy the optimized tables back to the live database to overwrite the originals.
6) Check the websites for errors.
7) Unfreeze those websites.
8) Empty the workspace database ready for the next batch.

In my production site, these notices disappeared when I upgraded to Hueman 3.2.8.

I’m using PHP 7.0.6, WordPress 4.6.1, and a child theme of my own design.

I was also seeing these PHP Notices using PHP 7.0.6, WordPress 4.6.1, and Hueman theme 3.2.3. I just upgraded to Hueman 3.2.8 and the problem was solved. My thanks!

Philosophically, I have to say that configuring PHP to suppress error display might serve as a temporary work-around of last resort but is not a credible fix for anything. Whether during production or in a live site, I want to know when any of the software components is misbehaving or failing to play nicely with the others. Even if I suppress error messages from public view, I need to know.

Warmly,
Paul

You can also test for the http-referrer in PHP:

// if they're not coming from PayPal
if (!array_key_exists('HTTP_REFERER', $_SERVER)
 || preg_match('#^https://www.paypal.com/#', $_SERVER['HTTP_REFERER']) === FALSE)
{
	// take them somewhere else
	header('Location: error_page');
}

If the $_SERVER global array doesn’t have an item called HTTP_REFERER it means that the visitor is trying to navigate to this page directly. If so, or if the referring page doesn’t look like the PayPal secure page, take the user somewhere else.

To plug this code into your WordPress template page you would need to check on the URL of the referring PayPal page to make sure this is testing for the right string and change ‘error_page’ to a real location on your site.

Regards,
Paul

lilqhgal, I share your exasperation, but I think the particular example you cite falls into the realm of styling, not markup. Most clients want to edit their web pages as though they were Word documents, i.e. applying arbitrary styling at whim. Although there’s always the temptation to just throw up my hands and let them make a mess of my hard work, I do try to educate them instead. In your example, I would want to find out why the client wanted the extra vertical space at that location, express it as a rule, debate its value , see if there’s an existing style rule that would equally satisfy the client’s purpose and if not incorporate it into the style guide for the entire site and add the new rule to CSS and whatever necessary classes to the markup. That’s the ideal scenario in my view. It puts an admittedly aggravating hurdle in the way of the client mucking around with the look and feel of the website and helps them get their money’s worth out of the design job. The client gets a site that communicates their message and maintains its aesthetic and technical integrity.

That said, I agree completely about how frustrating TinyMCE is in second-guessing existing markup and imposing its own crappy rules. I’m torn between spending the time necessary to bend TinyMCE to my will (or to find out whether it’s sufficiently and specifically bendable) or writing my own damn editor.

There’s no way around it: web work is a technical pursuit. I know graphic designers who like to approach web design as a purely artistic endeavor. Page design in the abstract might be purely artistic, but web design, like print design, is also technical. A competent web designer can’t be ignorant of the rules of markup and styling any more than a competent architect can be ignorant of building techniques and materials. A corollary to this is that we can’t hand a website over to a non-technical client to edit until we have a visual editor that obeys the particular rules of each site’s structure, markup, and styling.

An alternative, as suggested above, is to separate content from markup and styling, but this ideal isn’t truly possible using WordPress unless you route all content through your own plugins with input fields that don’t permit styling and markup. If you’re going to go to that much work, it becomes questionable whether the WordPress engine remains a large enough share of the final product to justify its use.

Sorry to sound so negative — I’m using WordPress as a CMS and grumbling because it’s not what it was never intended to be. Mea culpa. I’m able to do really good work with WordPress but my pride is the pride of someone who’s managed through great effort to use a wrench to hammer in a screw.

Nice wrench, though!

Paul