raoulunger

Thanks for the answer. I activated and checked the log-file, but there is no reference to any errors. I noticed though that the white screen isn’t about WordPress crashing. When I install your plugin, and hit the ‘activate’ button, the next page simply won’t load (and remains white). This is the url that is shown then in the browser (I removed the root domain here for security reasons):

/wp-admin/plugins.php?action=activate&plugin=email-encoder-bundle%2Femail-encoder-bundle.php&plugin_status=inactive&paged=1&s&_wpnonce=23cf67b870

The only way to get rid of that is to click the back button in the browser. The plugin then shows as being still inactive. So, actually, the plugin doesn’t activate.

I tested with other new plugins, but none show this problem, except for the one that I mentioned earlier, and that is similar to yours.

Any ideas?
Thanks!

• This reply was modified 1 month, 1 week ago by raoulunger.
• This reply was modified 1 month, 1 week ago by raoulunger.

Thanks for the very prompt reply – both options (no link tags, or alternative ‘rel’) work fine.

And my apologies, I read through the information last night on the plugin’s WP-page, but I overlooked the ‘docs’ button there (it was late…). I just found out that both answers (and some more) were already there on your website!
Cheers!

Further to my previous post, here is a screenshot of what I see:
https://ibb.co/cDPdrGC

The chat with Aarmie is blocking half of the screen, and looks very deformed. There is no window to enter text in, and the close button does not do anything, nor does the question mark. I think the code for this functionality is broken (‘I’m in Firefox Developer).

Regarding the above mentioned solution: in the settings page a can’t find anything related to this chatbox. Can you be a little more specific about where to find the switch to hide this?
This chatbox renders your plugin unusable for the moment…

Cheers

Hi people from Lightpress, sorry for this late answer. I tested a few things, and I think the problem with captions not showing is due to two things (in my case at least – the problems that Jalapenojuan is having might be different).

1
I ‘populate’ my pages with a custom post plugin (Pods). This allows to include or exclude every separate metafield related to media files. So I can include that image, and the caption separately. I can also choose not to show the caption on the page (even though I would want it to show up in the Lightbox).
But when an image in WordPress is inserted in the regular ‘classic’ way (in the TinYMC editor), WP wraps it in two caption tags (if a caption is filled in the media library). This means that WordPress will always show the caption if there is one. I tested your Lightbox with images that are inserted in that way, and then everything works fine (captions show up in the Lightbox).

2
I noticed some behaviour of your plugin that in my view is a little illogical. When I insert an image in the classical way, not only does WP wrap it in caption tags, but it also ‘prints’ the content of the caption in the html-code. So the html markup looks like this:

<caption><img>This is the captiontext</caption>

As said, in this way the caption is shown in the Lightbox, as expected. But I noticed that, if I alter the caption directly in the HTML markup, this altered version is shown in the Lightbox image.
This means that apparently Lightbox does not take the caption from the original metafield directly, but rather looks at what is essentially a copy of that caption printed by WP in the markup.

This means a number of things: firstly, captions will not work when images that have catpion are inserted in the markup through custom post fields (e.g. Pods) – as is the case in my example. And secondly, we always have to show the page-version of the image together with its caption for it to show up in the Lightbox version as well. If we delete the caption in the markup after inserting the image (because for some reason we don’t want it on the page itself), it also will not show anything in the Lightbox.

There might be technical reasons for this behaviour, but I think it would be more logical if Lightbox would look directly to the caption metafield pertaining to the image, rather than to the copy WP prints of it in the HTML markup. This would probably also solve the problems with the custom post fields.

Ok, in the meantime I found out that if you choose ‘Full Language Names’ in settings -> Langugage Switcher, and then change the ‘native field’ in the advanced tab, the new name is shown as typed (not in all caps). So problem solved.

However, in your documentation this ‘native field’ is never mentioned – so perhaps it would be good that revise that chapter a bit. I think the plugin may have changed since that chapter was written.

Cheers

HI, thank you for your answer. It does not cover my question completely though (also your documentation shows less field than the advanced tab does).

I figured out that, in order to change the language switch in the wordpress primary menu, I have to change the ‘slug’ in the plugin’s settings (not on the advanced tab). So I changed it from ‘en’ to ‘english’. That works in the sense that ‘english’ now appears in the menu.

What is not solved is that the word ‘English’, appears all capitalized, which I don’t want, as the rest of the menu is not capitalized either. I see in the HTML markup that the word is actually inserted in capitals by your software – which means I cannot undo it through css. It would be more logical if your plugin would insert the slug in undercast, and then capitalize it through css (which then can be undone).
Is there a way to change this?

Thanks

Chiming in: in your case you can add the following css lines (in the customizer):

For the background color:
.main-header-menu .sub-menu {
background-color: [color of your choice];
}

For the border color:
.ast-builder-menu-1 .sub-menu {
border-color: [color of your choice];
}

You may have to add !important between the color and and the ; in both cases.

Hi, Ok, thanks for the efforts! I understand that zooming out beyond the image frame poses problems in different scenarios.I also see that disabling the plugin below a certain view width poses technical issues for different situations. I managed to kind of simulate it now by hiding (display: none) the overlay and the outerImageContainer via CSS and a media query. Not the most elegant of solutions as the markup is being generated anyway – but in my case that’s not a big deal as I have 10 images max per page. I tried using ‘pointer-events: none’ instead of ‘display-none’, but that worked erratically.
Anyway, case solved for now!
Thanks again.

Hi,

Thanks for your very rapid response! And actions! – I saw just now that you already made an update to the plugin. Pinching is working now (I was using the new styles). However, when zooming in on the image, the image stays in its original frame/viewing area. (bit hard explain, hope you understand what I mean). For images that are landscape (on a portrait oriented phone) and therefore relatively small, this means the viewing area remains small as well, even when zooming in on a detail. When pinching the vingers then go beyond the area where the image is (which feels kind of unnatural).

For that reason I still think it would make sense (as well) to allow for the disabling of the plugin under a certain viewport width. It would be great if we could set that viewport width in the options. In most cases, a lightbox on a mobile phone makes less sense, as images often are shown as large as possible anyway.

Thank you for implementing the hiding of navigation in cases there is only one image. This works fine now! I have not found any lightbox plugin that had thought of that. Many portfolios are project-oriented, and while many projects can have multiple images, some projects (for example the design of a single poster) can have just one image. I had temporarily solved it with a marker on each single-image page and some css-hiding – but yours is of course a much better solution!

• This reply was modified 1 year ago by raoulunger.

Thank you! I will give that a try.

Cheers, Raoul

Hi – thanks for the answer, and good to know the plugin is still supported, It is in its base a good plugin that’s also very well customisable (cosmetically) through css.
I understand factors such as demand and extend to which people will benefit from an added feature, and the priorities you have to make in resources. However, it’s also perhaps good to realise that many people will install plugins, try them out quickly, and the moment they bump into an issue they will be gone (because there are many really bad plugins). They won’t first try to submit feature requests and go into dialogs with the developer. So the amount of demand (or rather the lack thereof) for a certain feature is not necessarily a good indicator of the actual necessity of that feature.

There are many designers, artists, photographers, etc, who organise their work in projects. It happens often that a project has only one image (for example one painting) while other projects might have multiple images. It does not make sense to show ‘previous’/’next’ arrows in the lightbox when there is only one image to be seen. This confuses visitors to no end because they will be clicking stuff that leads nowhere. You could perhaps (in my humble opinion) argue that fixing this is more akin a bug-fix (or a conceptual omission) than it would be a feature addition…

In my personal case I have solved it by adding css to project pages and hiding the arrows when applicable. This means I need to add a custom field to each project and indicate if it contains one image only, convert that field to a class, and then hide the targeted element. Not everyone of your potential users will be able to implement that kind of fixes – meaning they will probably just deactivate your plugin.

Cheers

• This reply was modified 1 year, 1 month ago by raoulunger.
• This reply was modified 1 year, 1 month ago by raoulunger.
• This reply was modified 1 year, 1 month ago by raoulunger.
• This reply was modified 1 year, 1 month ago by raoulunger.

Will do!

Hi, any progress regarding this issue?

Cheers, Raoul

Hi,

Thanks, but this is not an answer to my question I’m afraid.

My question was if (and how) we can maintain the aspect ratio of the images in the film strip, instead of cropping them all of the to squares.

Adjusting the height or width as per your instruction does not chance this behavior.

Cheers.