AWOL

Hi @imath,

Thanks, I will keep an eye on the GitHub.

Hi Adam @wpmudev-support8,

I have just tried that – using the css you have provided with my popup id, if auto height is disabled and a height is set, the form expands but the popup box doesn’t, but with auto height enabled plus the css it works as it should, expanding the box and showing scrollbars, but only when it reaches the edge of the window. However I have discovered that this is due to what the popup position setting is; I have it set to Top Bar, but if I change it to Centred the scrollbar is gone again (with the same other settings), however if I change to auto height disabled and enter a height the scrollbar is there again. So this appears to be a purely css issue that I need to take up with the plugin author.

On a related note, just for your information, there is an ongoing problem with the same popup plugin and the datepicker calendar on both Forminator and Ninja Forms, and probably others, where the popup closes when anything other than the actual date being selected is clicked (for example the month arrow selectors or just the background of the datepicker itself) – this is being worked on by WP Popups and is related to the datepicker being regarded as being ‘outside’ the popup, so any click with the current plugin will close it (there is no setting to disable that behaviour, at least in the Lite version). One of the reasons I switched from Ninja Forms is that at least with Forminator I can avoid the use of the datepicker calendar and use dropdowns or text input instead to get around this issue, although I would obviously rather have the calendar from a usability perspective. I think this might be an issue with many popup plugins unless they allow disabling the click outside behaviour or change their css somehow. Not sure there is anything form plugin authors can do to prevent this issue.

Hi @wpmudevsupport16,
I think you have slightly misunderstood the problem, probably because of my explanation; there isn’t a problem with hiding a field with a default value , but a field to be hidden/shown based on that default value field. In the example of a datepicker field, I set today as the default, but with that in place and the next field set to be hidden or shown based on null or not null, or the ‘is before/after n or more days’ option, I can’t get the field to show/hide. As I mentioned in my original post, I understand this is because the form is treating the default value as what the user has entered, so is operating logically, but I was just trying to see if there was a way around it. I guess not, but it’s OK as I didn’t realise the calendar highlights today anyway, although users still have to click on it – I was just trying to avoid extra clicks for the user.

As for the second issue regarding scrollbars I am still looking into it and awaiting a response from WP Popups, but if you did not get this issue in your test then I will have to see what else can be the problem – given my past experiences this might be my theme, Blocksy, so I will ask them if the problem doesn’t show up with a different theme. I am assuming that you tested on a form that was longer than the page though, as it only happens on forms that become that long. A simple fix for me will be to try and make the form(s) fit the page, which is probably a good idea anyway. One very weird thing I have spotted is that when I open the inspector in Firefox (on Mac), the scrollbar appears, and then disappears again when the inspector is closed, so I thought it might be a browser (Firefox) issue, but it’s the same on Chrome. However, it doesn’t do it on mobile (Safari) but does on Android (Opera). I guess I will probably just have to give up on the idea of hiding/showing fields, annoying as that is. However if you were able to test further with other devices/browsers is it possible that it isn’t just my site?

Hi @wpmudevsupport11,

I have been updating whenever a new version is released, but I am still getting these errors; is there any further update on this?

Hi @iapial,

Thanks for that – can I assume yesterday’s update includes this fix?

Hi @imath,

Thanks for the response; I hope this type of thing will improve across the BP universe, as it would not only be a boon when people are styling their site but would also help site speed.

Hi @cteduard,

Completely understand your position. Would it be an idea for me to note any further issues I encounter as replies on this thread? Or should I wait until a more final version of BP is released?

Hi @cteduard,

Thanks for the responses – I am pretty bogged down with a number of things, hence the slow response. I agree that you should probably wait, at least until the BP team get closer to the final release. I generally have a lot of styling issues with Buddypress, as (at least in my installations) with Blocksy, BP is not consistent in inheriting theme styles and has a myriad of different classes with associated css for essentially the same things, such as buttons and inputs, so it is extremely difficult and time consuming to get a consistent look, and the Customizer isn’t much help. And then any BP plugins have their own classes and built in styles, some of which inherit the Blocksy child theme styles I have set and some don’t, and most don’t give any options to get around this. I am really hoping the revamp of BP will address some of this, but I get the feeling it isn’t. I suggest you play around with Blocksy and BP for a bit and you will see what I mean. Unfortunately there are no viable alternatives for me.

Hi @aaron13100,

Just an update, in case you were interested – I made my custom 404 page draft, and cleared caches, but it is still appearing. I have no idea how or why. I am already in contact with my host and they are as mystified as I am. Next step is to delete it completely but I suspect that won’t make any difference either.

Hi @aaron13100,

Thanks for the quick reply, that helps a lot. I had already deleted the database tables and checked as best I could, and as far as what I said about altering other files, I did find an entry in the wp_options table which is what caused me to wonder. As far as dealing with why the page is still appearing, making the page draft was to be my next move, but I have scoured my site and I can’t find anything that is referencing it, and I have cleared caches so many times I have ruled that avenue out. This issue though is not caused by your plugin clearly, so thank you and I hope I can track what is going on as well as deal with the original issue that caused me to seek out your plugin originally.

Thank you @pavanpatil1, that seems to have done the trick!

Thank you @iapial, I await any update.

Hi @cteduard,

Thanks for your usual quick response. The Buddypress beta is available here, and the BP Attachments plugin is here. I’m not sure why you wouldn’t have access? I imagine it might be helpful for you to contact the author of BP Attachments as he is also part of the BP team. If you install BP with Blocksy you will see that the Customiser does not seem to work as it should, but I don’t know if this is something they are still working on. However I think there is some incompatibility even with the current version of BP anyway, as I have a hard time, particularly with the css, getting the BP pages to look as I want, and have to use an inordinate number of !important statements, largely due to how BP has been written I think. Forms, tabs, buttons and inputs are a particular headache. I believe this is part of why they are making the new version, but if the beta is anything to go by, there is a lot of work still to do.

Hi @imath,

Thank you for your input – your custom css works so I have implemented it, and I have posted on the Blocksy support here. Hopefully they will have a look at this, and possibly other Buddypress/Blocksy issues that are out there. They are normally very good at dealing with stuff like this. I have certainly found it quite tricky to use the Customiser with BP, with both the existing and beta version of Buddypress, and I always have to write a ton of css to get BP to look as I want; as mentioned in other posts, I can’t get the recommended way to alter BP css to work on my sites, so I end up just using the child theme style.css with loads of !important statements, which I would like to eliminate if at all possible as it frequently causes other problems, particularly with tabs, buttons and inputs. I think this might be a fundamental issue between Blocksy and BP that I have hinted at in the post on their forum, but the theme is so flexible and I am so familiar with it that I am loathe to try and find a new theme.

Hi @iapial,

Sorry, yes, the issue is fixed. One other small query – I have been having an issue on my site with 404 errors that I have been investigating for months and has caused me to look at the site logs, and a recurring 404 error has been happening with a location connected to your plugin; I only know that it is when I (as admin) am doing something on the site, and it is probably when I am editing one of the docs created with your plugin. The location in question is

 /wp-content/plugins/betterdocs/assets/admin/editor.css

Obviously this file doesn’t exist on my site which causes the 404 error (in the logs), but on investigation and quite a lot of searching I found what I think the culprit is;

/wp-content/plugins/betterdocs/includes/Editors/BlockEditor.php

and on line 69 of that file is this;

            $this->assets->enqueue( 'betterdocs-admin-editor-css', 'admin/editor.css' );

So my questions are, should editor.css be where that file expects it to be or is this erroneous code that needs correcting?

I know this probably isn’t at all important, but I am trying to eliminate anything that might be causing the issues I am having, as it is, quite frankly driving me crazy!