vollachr

I don’t know, I haven’t updated, I’ve put the entire project on hold for now, don’t have the time or resources to complete & maintain it right now, I might try again in a month or two, maybe near the end of the year.

Hi,

Yes, the background settings also effect the Gutenbrg editor, however, in my case, since I was using an image background for the frontend I left the background color as default, which caused it to be white on white in the editor.

You can see how that can be a problem…

however, I did test for a short period with dark background to see if it helped and it did change the editor BG, I just personally prefer to type in a light color editor with dark text.

This is a bug however, it doesn’t have to be like that as evident by the fact I managed to bypass it with custom CSS as I mentioned.

Hopefully it’ll help, for now, I’ve done what you asked, after a while of working with log level debug, this is the contents of the log files:

13-07-2020 09:00:44 – DEBUG – v: 6.7.9 – m: 68.7 MB, u: 1 – Main options saved
13-07-2020 09:00:44 – DEBUG – v: 6.7.9 – m: 68.7 MB, u: 1 – Refreshing the license data
13-07-2020 09:04:34 – DEBUG – v: 6.7.9 – m: 55.3 MB, u: 0 – Newsletter::hook_newsletter> Start
13-07-2020 09:04:34 – DEBUG – v: 6.7.9 – m: 55.3 MB, u: 0 – Newsletter::hook_newsletter> Emails found in sending status: 0
13-07-2020 09:04:34 – DEBUG – v: 6.7.9 – m: 55.3 MB, u: 0 – Newsletter::hook_newsletter> End
13-07-2020 09:09:52 – DEBUG – v: 6.7.9 – m: 55.3 MB, u: 0 – Newsletter::hook_newsletter> Start
13-07-2020 09:09:52 – DEBUG – v: 6.7.9 – m: 55.3 MB, u: 0 – Newsletter::hook_newsletter> Emails found in sending status: 0
13-07-2020 09:09:52 – DEBUG – v: 6.7.9 – m: 55.3 MB, u: 0 – Newsletter::hook_newsletter> End
13-07-2020 09:15:30 – DEBUG – v: 6.7.9 – m: 55.3 MB, u: 0 – Newsletter::hook_newsletter> Start
13-07-2020 09:15:30 – DEBUG – v: 6.7.9 – m: 55.3 MB, u: 0 – Newsletter::hook_newsletter> Emails found in sending status: 0
13-07-2020 09:15:30 – DEBUG – v: 6.7.9 – m: 55.3 MB, u: 0 – Newsletter::hook_newsletter> End

Not sure if it helps.

• This reply was modified 4 years, 4 months ago by vollachr.

Thanks, let me know what you find out, I’m working on another part of my site for now until I hear back.

Tried to remove the license key, still loads very slow, slightly faster though. the rest of the site & admin loads in max 1 second, Newsletter plugin pages in admin takes at least 30 seconds, soometime up to 2 minutes.

Do you think it’s because of the fact I’m on localhost? I don’t currently have an actual host to test it on, I’m waiting till the site is ready to figure out a web hosting solution.

As for the translations, I have Loco Translate installed, went to plugins page and clicked translate, translated to 100% and still, some things remain in English (mainly some admin menu items like “list building, security, newsletters, etc.)

I did set a free licnese in main settings.

Are you suggestiong I remove the lincese code for the time being?

Anyway, yesterday there was a short period of time it worked faster, but it went back to slow again.

Also, unrelated, I’ve used Loco Translate to translate the plugin to my language, but not all strings are working, either that or there are missing strings in the template.

Well, nevermind, figured this out on my own eventually, it did require editing one of the PHP files but it was a simple edit.

OK, I think I finally found the problem…

It seems it stems from translating the plugin name, whenever I translate the plugin name instead of leaving it in it’s original English state the plugin breaks, when I leave it in English everything seems to work correctly.

@sharmadpk03 Not a very helpful answer, I’ve already read that and I went through my entire translation files a few times both with Loco Translate and POEdit, changed anything I suspected might cause a problem but it doesn’t help, I’m probably missing something, maybe a missing character somewhere or unneccessary ones, I don’t know. I’m at a loss here.

Maybe I’ll try to translate it again from scratch, it’s a lot of work but I don’t know, unless someone else can take a look at the current translation files I created and find the problem, I just don’t see another way.

Is there someone I can send the files to for review, to see if I missed any problems?

@manuelrocha88 OK, changed what you said to change, renamed the existing .po & .mo files to match as well.

After a few tries I managed to get it working, but only when the files are placed in this folder:

\wp-content\languages\plugins

Didn’t work with the files in the plugin folder nor with the Loco Translate safe path, i.e. \wp-content\languages\loco\plugins

Anyway, bottom line it’s finally working, can’t figure out why it won’t work from the loco trasnlate safe path though.

@manuelrocha88 well, didn’t work either, it was highly doubtful anyway since there are already freemius-he_IL files in there, don’t know what these freemius language files are used for but it isn’t to translate the actual plugin, it doesn’t have the same strings, it is completely different.

Anyway, as I said, didn’t work as well.

I just tried that, Loco Translate shows the translation files for Simple Author Box Hebrew as 100%, all green bar.

So it seems to be correct, I even re-saved them using Loco Translated and it still won’t work, the plugin stays in full English.

is there any other language other than english that works? can I maybe send you the files for testing?

Are you certain about that?

I’ve place both simple-author-box-he_IL.po & simple-author-box-he_IL.mo at the following folder:

\wp-content\plugins\simple-author-box

it didn’t seem to do anything though.

I also tried putting the same files here:

\wp-content\languages\plugins

Still no luck

I haven’t messed around with functions editing in years, which file should it go in and where?

EDIT:
nevermind, figured it out, added it to the start of file inc\functions\functions.php.

Seems to work, thanks.

BTW, can you or someone else take a look at my other question, regarding translation of the plugin

HERE

• This reply was modified 4 years, 4 months ago by vollachr.
• This reply was modified 4 years, 4 months ago by vollachr.

I believe I already tried these, just in case I tried it just now again after I’ve seen your answer, I added it in the theme’s “Custom CSS” section, it doesn’t seem to do anything.

To be exact I added these at the end of my theme’s custom CSS section:

.sab-edit-settings > a {
    color: white !important;
}

a.sab-profile-edit {
    color: black !important;
}

But the color of said links still remains without any change, tried at the beginning of the “Custom CSS” section as well, no difference.

Thing is, currently, the “Settings” links is nearly invisible because the bottom section of the author box is in nearly the same color and I don’t want to change that, I love my color scheme, the “Edit Profile” I just want to have in a different color from the Author Name.

UPDATE:
Been playing around with it a little bit, still can’t get it to work, same thing for font size of the “Edit Profile” link btw.

Anyway, after playing around with Google Chrome’s Inspect feature, I think the “!Important” part of the original plugin CSS files might be the problem, if I un-tick the checkmark next to these in Chrome’s Inspect my “Custom CSS” start to work, but that is only a temporary solution until the page reloads.

Any way to bypass these “!Important” sections in your plugins CSS files so they won’t stop my custom CSS from working?

• This reply was modified 4 years, 4 months ago by vollachr.