cfish

Did anyone ever find a solution to this problem?

I've been trying for years to find a way of adding a LISP code mode to the editor for syntax highlighting and getting no help as to how I might even begin such a thing. Assuming that is impossible, the option to change the default from HTML to no highlighting would at least be a step in the right direction.

On 4/9/2023 at 11:30 AM, Stuart Silvester said:

One or more of your other login handlers will also be set to display name or email address. You will also need to edit those and set them to display name only.

Thanks, it seems that the Converter has it's own login handler - who knew?

Once I changed that, the dummy text displays correctly.

I recently changed the Authentication Type to "Email Address" in line with best practice for security. Previously members could login with either screen name or email address.

However, the dummy text for the Sign In modal continues to state "Display Name or Email Address" and this has caused frustration for some users who missed the notifications we made. I think this text should automatically update to reflect the authentication type being used.

Is anyone else seeing this?

I am running AdSense with traditional static ads and with Auto Ads turned on. The setup worked perfectly with 4.7.0. After the upgrade to 4.7.1, any attempt to scroll to the bottom of a page with ads results in a browser crash. If I turn off Auto Ads in the AdSense control panel, the forum works fine.

I can only assume that some change in 4.7.1 is conflicting with AdSense Auto Ads. Would be good to know if others are seeing the same thing so I can confirm this is the source of the problem 🙂

2 hours ago, opentype said:

You can probably also get a perfect score with PHP Mails

@opentype It turns out that a perfect score is not possible with PHP. SpamAssassin automatically adds a value of -2.499 to any message sent via a PHP script, so even if everything else is perfect, the maximum score is 7.5. Simply changing my settings to SMTP increased the score from 2.2 to 8.9, and now Gmail is accepting emails sent from the forum.

That's a great help. Now that I know the root of the problem, I should be able to resolve it with my host. In the short term, I'll switch to SMTP and then work on improving the score for PHP mail. Thanks for your input, much appreciated.

Thanks @opentype, the results of that test = "Your email may never see the light of an inbox" 2.2/10

The problem flagged is that the mail server is not fully authenticated - looks like a problem with the MX record being used for PHP emails. If I use the same check from an address on the same domain via Outlook, I get 9/10 and no problems. I'm guessing that if I switch to SMTP mode, that should resolve the issue?

Thanks @Nathan Explosion I'll give that a try.

I should probably add that this does not appear to be an IP blacklist issue, as I am able to send an email using the same outgoing mail server to Gmail addresses without problem. This issue seems only to affect emails from the forum.

Up until recently, all emails sent by the forum were being received by all email services. Now, emails sent to users with Gmail accounts are being rejected. This seems to affect validation emails, password recovery emails etc. Anyone registering with a Gmail account is effectively locked out of the forum. I believe some security changes were made at Gmail on 30th May, the last successful registration via Gmail on my forum took place on 28th May, so I'm guessing this may be the cause. I'm using the PHP method to send emails, so I don't understand why emails that were previously getting through are now being rejected. Is anyone else seeing a larger than usual number of failed registrations?

On 6/10/2022 at 9:14 PM, Refsmmat said:

Hi,

have you ever figured how to extend the list of supported languages?

 

I'm afraid not. After a lot of research with no progress, I gave up. I would still dearly love to make it happen, but I have no idea how to do it. If you have better luck than I did, please do let me know.

On 6/11/2022 at 1:10 AM, teraßyte said:

That list is updated with a javascript controller. I don't have access to the code right now to check the exact name/path though.

Any help on this would be most welcome.

UPDATE:

One week after the upgrade, the database is back to an expected size. I suspect that the Cron Job needed time to do it's work and keep the database optimised. The upgraded database is only slightly larger than the previous version:

4.5.2 = 275MB gzipped

Hopefully this update will help anyone worried by massively inflated databases after upgrading.

So I found the template file for the code block modal in Core>global>editor>code:

<div class="ipsPad ipsForm ipsForm_vertical" data-controller='core.global.editor.code' data-editorid='{$editorId}' data-randomstring='{$randomString}'>
	<form method='get' action='#'>
		<div class="ipsPad ipsAreaBackground_light">
			<div class="ipsFieldRow ipsFieldRow_fullWidth ipsFieldRow_primary ipsLoading" data-role="codeContainer">
				<textarea id='elCodeInput{$randomString}'>{$val}</textarea>
			</div>
			<div class='ipsFieldRow'>
				<button type='submit' class="ipsButton ipsButton_primary cEditorURLButton cEditorURLButtonInsert" data-action="linkButton">{lang="editor_media_insert"}</button>
				<div class="ipsPos_right">
					<select id='elCodeMode{$randomString}' data-role="codeModeSelect" data-codeLanguage="{$language}">
						<option value="null">{lang="editor_code_null"}</option>
						<option value="htmlmixed" {{if $language == 'html' OR $language == 'htmlmixed'}}selected{{endif}}>{lang="editor_code_htmlmixed"}</option>
						<option value="css" {{if $language == 'css'}}selected{{endif}}>{lang="editor_code_css"}</option>
						<option value="javascript" {{if $language == 'javascript'}}selected{{endif}}>{lang="editor_code_javascript"}</option>
						<option value="php" {{if $language == 'php'}}selected{{endif}}>{lang="editor_code_php"}</option>
						<option value="sql" {{if $language == 'sql'}}selected{{endif}}>{lang="editor_code_sql"}</option>
						<option value="xml" {{if $language == 'xml'}}selected{{endif}}>{lang="editor_code_xml"}</option>
					</select>
				</div>
			</div>
		</div>
	</form>
</div>

Would the solution be as simple as changing the null option to be "selected"?

UPDATE:

Editing this template makes no difference to the drop-down and the options must be coming from elsewhere? This would make sense because the options on the actual drop-down don't match those shown in the template:

By default, the syntax highlighting in code blocks is set to HTML. This may be OK for the majority of forums, but if a forum is a special interest group for a different code language, users must set the value every time they use a code block. Is there a way to change the default to something other than HTML, even if it's "No Syntax Highlighting"?

Hi All, I just upgraded my community from 4.4.10 to 4.5.2.

The upgrade went smoothly and the forum is looking good. However, as usual, I made a database backup via cPanel before the upgrade and have just done so again after the upgrade. It seems as though the latest version of IC uses a great deal more space:

4.4.10 = 265MB gzipped

4.5.2 = 882MB gzipped

I'm amazed at the difference - the new vesrion takes well over three times the space! Does this seem normal, or am I missing something?