Erikvona

First of all, this plugin should never be used to add a div to a page, since this adds things to the head section, and divs aren’t supposed to go there.

Secondly, if the plugin is disabled, it does literally nothing, so it can’t add anything to any page.

Thirdly, the plugin adds a comment so you can see where it inserted something, and that comment is not present on the page you’ve shared, so it’s hard to believe the plugin is active on that page (it isn’t if it’s disabled, of course).

If you have steps for me to reproduce the issue, feel free to share them, but I’m 99% certain this issue is unrelated to this plugin.

In general, issues with the plugin remaining active after disabling may be caused by caching plugins, but then the comment should still be there (unless you use a caching plugin that strips comments too). These all allow you to clear the cache manually. But since I have no reason to think the plugin actually caused the issue that probably won’t help.

I’ve reviewed your mail and it’s just a scan report.

This plugin tends to trigger false positives, either because it’s closed (which indicates there is a vulnerability, so a lazy scanner that assumes all closed plugins contain vulnerabilities will think its vulnerable) or because, depending on your definition, it still makes XSS possible since as an authenticated user you can insert scripts (both on and cross site) into the head section, which precisely is the purpose of this plugin (you can argue that isn’t a false positive, but then you shouldn’t be using this plugin).

I wouldn’t worry about it. As soon as I receive information on a credible XSS attack I’ll update.

The recently identified vulnerability has been patched in version 1.4.4.
If you have information on a still present vulnerability, please let me know (https://evona.nl/contact/ should work, reply here too so I can check it didn’t end up in spam).

The plugin will remain closed, though, per a strong recommendation by the WordPress plugin team to do so, since I’m no longer actively developing the plugin and only addressing serious concerns. Any current users should have received and should install the update.

If you really, really want to use the plugin, you can always use SVN to get it.

Hey,

This plugin is sort-of maintained.

I don’t do a lot of testing with new WordPress versions, but since the code is simple I don’t anticipate incompatibilities, and I do monitor the WordPress changelog for things that could break compatibility with the plugin.

I monitor the forum and will try to respond to feature requests and bug reports.

I won’t actively think up new functionality and add it. And that’s a good thing, since it keeps the plugin small and clean, and it saves you from having to install and test new updates.

With this approach, updates haven’t been needed for the last two years. You can view the support threads to look into how I’ve handled past bug reports and requests. Usually, I respond within a few days.

Please try to provide steps for me to reproduce this problem.

While I haven’t updated the plugin in the past 2 years, if there’s a serious problem, I will attempt to fix it.

Note that version 1.4 had a bug with newline storage, but that got fixed, and 1.4.2 doesn’t have increasing size problems.

• This reply was modified 6 years, 2 months ago by Erikvona.
• This reply was modified 6 years, 2 months ago by Erikvona. Reason: Extra explanation

Eh… I could update the readme to indicate support of the latest version. I’ve been a bit sloppy with those kind of updates, since there have been no real changes in WordPress that break compatibility, and I haven’t done a lot of testing. I’m not in the habit of adding unwanted features bloating the plug-in, and there are no real bugs as far as I know.

The plug-in is intentionally feature-poor, to optimize speed, compatibility and size, and minimize maintenance and bugs. I don’t intend to add more features at this time. I’ve been doubting to add an option to customize loading order, but haven’t decided if that’s worth a minimal increase in load time.

Issues with data displaying just at the top of the page are almost always caused by invalid HTML added through the plugin. As said in the description, this plugin doesn’t validate anything, so make sure you validate your HTML before adding it.

Without a link to a webpage where the problem occurs, I can’t check for the exact cause.

Yes, of course. You can just enclose your CSS in <style> tags and add it like any other HTML. It’s one of the supported uses.

There is no CSS validation though. Some plugins might do a better job at managing CSS (but they won’t be this lightweight).

That’s a design choice. I would have to account for way more things (like one-page themes and such) if I were to output everything.

The plugin is open source, feel free to modify it yourself if this is something you want. But I’m not going to implement it.

See this post

Dear @waseemsajjad431
This is a support form for a specific plugin, not a general place to ask questions. If you have issues using my plugin, or questions about it, please describe the problem.

WordPress is a CMS, so you cannot edit the HTML directly, only the PHP that generates the HTML.

Furthermore, if you expect me to put effort into answering questions, please put effort into asking them as well (proper English, proper description of the issue).

Should be fixed under version 1.4.2. Update it. If you still have the error, notify me.

Thanks for notifying me. Due to an error in SVN, I was actually working in a way older version than expected, causing some bugs to be introduced. Since I removed the code adding the <%BREAK%> thingies in version 1.2, and they are gone for each post updated since then, I didn’t notice it in error testing

The bug is fixed in version 1.4.2.
Really sorry for the inconvenience, notifying me actually made me fixed some more bugs reintroduced by the same SVN error

Flagging this as not a support question.

Plugin behaves as expected (the select list selects which post type you can add per post/page stuff to, so it appearing on all pages is expected).

Caching is complex, I’d make sure the caching is not server side/mediated by the webhost. Control + F5 sends different headers, and might disable server side caches. Your modification to the head code will not solve that.

That is really odd. Have you checked your screen options after updating? Are any errors displaying?

In the code to make the latest version display, nothing has changed from 1.3. The only thing that has changed is the code used to store data entered, and that generating output (inserting the stored content into the head section). But as you can see in the changelog, several bugs have been fixed in the 1.4 and 1.4.1 version.

The plugin has been extensively tested under WordPress 4.7, both in a Linux and Windows configuration, and I have yet to discover any bugs in version 1.4.1.

Also, just to be sure, can you check the add head to every page section under settings, and make sure the appropriate user and post types are checked? (shouldn’t differ between 1.4.1 and 1.3)