jschinnerer
Forum Replies Created
-
OK, thanks for the suggestion. I will try this as our next newsletter send comes around. Will be a couple weeks but I will add reply here after testing.
Forum: Plugins
In reply to: [Events Made Easy] html output with too many br-tagsJust installed the update. That fixed the br tag after heading tag. Don’t see any other issues at this time in my templates, thanks!
Forum: Plugins
In reply to: [Events Made Easy] html output with too many br-tagsI entered this as a bug in the E-dynamics bug forum.
I applied the modified eme_functions.php linked above.
That fixed the most obvious cases (div and p tags generating a br tag) but I am finding some remaining problems.
First one is that a <br> is generated after heading tags in templates.
I have an <h4> which gets a <br> rendered after it.Example – code in template:
<h4>Registration</h4>
Rendered code:
<h4>Registration</h4>
<br>I will post more remaining issues if/as I find them.
Forum: Plugins
In reply to: [XML Sitemap Generator for Google] Wordfence Security » Suspected malware URLWell, looks like a pilot error on Wordfence end that is now fixed – didn’t see those posts at first.
However the google reference is still relevant…don’t know what the consequences of trying to use HTTP instead of HTTPS with that URL is for whatever you’re doing with it. My hunch is something will not work right, if google says it is supposed to always be HTTPS.Forum: Plugins
In reply to: [XML Sitemap Generator for Google] Wordfence Security » Suspected malware URLDitto this issue. Same flagged by Wordfence on one of my client sites.
Looks like you need to update URLs for this to HTTPS, per the google developer reference on Measurement Protocol:
https://developers.google.com/analytics/devguides/collection/protocol/v1/reference…which says specifically:
“URL Endpoint
You send data using the Measurement Protocol by making HTTP requests to the following end point:https://www.google-analytics.com/collect
All data should be sent securely with the HTTPS protocol.”Could be problematic for sites where HTTPS is not available…:-b
Thanks @wfyann,
Please do come back with what developers find – if it is wordfence code selecting what engine to use a fix is needed to avoid cross-platform issues like this one.
Good to know one can change storage engine in an existing DB. I was not familiar enough with DB manipulation to know to try that.
I had to get this done, so just did a workaround of removing wordfence on old host, exporting that DB, importing it on new host (with no Aria engine issues, since export DB no longer had wordfence tables), and then reinstalling wordfence after it was live on new host.
The wordfence reinstall created those two tables using InnoDB engine, since host doesn’t support Aria engine.Made some time to quickly regress this.
Looks like 0.3.9 fixes this issue. Ordinary HTML links in page are working again.
Thanks for the quick turnaround!Thanks Matt, I will test it as soon as I can. May be a few days as I am about out the door on a business trip and will probably not have free time but will post here as soon as I have time to test it.
Thanks Matt – if it’s helpful I can send relevant snippets of rendered page source code.
As in example above they are just ordinary links within page. Some are on plain text, some on CSS-rendered ‘buttons’ with text. Pretty ordinary links.
Other possibly helpful info:
The pages with links in page that break using 0.3.7+ don’t even have tabs or accordions from this plugin on them. So it’s presumably something this plugin is loading on all pages…?NOTE: this bug may have been introduced originally in 0.3.7. Checking your changelogs, it looks like you added some per-accordion linking functionality in 0.3.7. Sounds suspect given this issue affecting normal in-page links.
I went from 0.3.6 to 0.3.8. Or if I did briefly use 0.3.7 before your 0.3.8 update, I didn’t catch this then.This issue definitely does NOT exist in 0.3.6 as I’ve rolled back my version to 0.3.6 and links in pages work as expected.
If you read all the details – that’s not possible.
Unless the plugin causing the conflict is the 1.01 version of FormBuilder itself. Nothing else changed but that, at that point in the process. All other plugins were the same prior to and after the upgrade, no problems with plugins.php until after the upgrade.Something is tweaked on that install since the upgrade, such that *any* plugin upgrade causes the blank plugins.php page.
The consistently reproducible workaround is steps 3-4 in my previous post above (steps 1-2 were probably not necessary in the first case either but I did them as part of standard procedure for troubleshooting this).
That is, the workaround is rename the plugins directory, reload the plugins.php page (which then works), change the plugins directory name back to ‘plugins’, and reload plugins.php page again, at which point it still works, and no issues continuing with reactivating plugins.Very strange, since the code in place when it fails (after upgrade, before workaround) is the same as the code in place when it works, after the workaround.
I was able to resolve this by:
1) deleting plugin files from plugins folder
2) manually removing formbuilder settings from wp_options table in DB
3) renaming plugins folder and verifying plugins.php displayed as expected
4) naming plugins folder back to pluginsThis restored a working plugins.php with all plugins shown as deactivated.
Re-activated all plugins OK (formbuilder completely gone of course).Note that removing formbuilder plugin files, by itself, did NOT resolve this. I also tried restoring an older formbuilder version, and that did NOT resolve it either.
Also breaks Dashboard -> updates page, that is:
wp-admin/update-core.php
That now also returns blank page.
Sorry, that’s upgrade to 1.01, not 1.0.1.