Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Nao
The Pub / Re: PHP 5.4?
« on March 18th, 10:50 PM »
I'd started doing something quick'n'dirty in just two lines of code, but then it started getting complicated, even with just two lines, so I give up for now. :P

I'd rather stick to the lowest 'acceptable' version that Wedge actually supports.
If I start asking for a higher version, I'll start using "??" as a replacement to "?:" (basically removes the need to do an isset() call), and then I'll start wondering if I shouldn't ask for PHP 7.1 support so that I can do [$foo, $bar] = func(); instead of list ($foo, $bar) = func(), but I'm NOT actually using list() much in Wedge, so who cares about that... :P

Well yeah, so I guess PHP 5.4 is doable, just hoping that no one currently using Wedge will be locked out of it. I'm surprised no one replied to the poll though. ^^
The Pub / PHP 5.4?
« on March 18th, 01:02 PM »
Since Wedge is 5.3+, maybe it's safe to simply up the min reqs to 5.4..?

The main advantage is the ability is use [ ] instead of array( ) inside the code. It's really just that.
I could also modify Subs-CachePHP.php to automatically replace [ ] with array() as needed. I can't be arsed for now.

I just checked, and 5.3+ is supported by ~90% of the user base, and 5.4+ by ~70%... Hmm. Then again-- what we care about is the current userbase, as I've long given up on turning Wedge into a popular engine. It's just the cool engine that people in the know use.

Anyway, I'm likely to go for PHP 5.4 + some support for PHP 5.3, but I can't be arsed to code said support for now. ;)
Features / Re: New revs
« on March 18th, 12:55 PM »
Quote from Nao on March 18th, 12:45 PM
IMPORTANT: this commit and the previous one only work on PHP 7+.
Actually, PHP 5.4+.
Features / Re: New revs
« on March 18th, 12:45 PM »
[Commit revision df6398f]
Author: Nao
Date: Sat, 18 Mar 2017 12:45:04 +0100
Stats: 1 file changed; +674 (insertions), -725 (deletions)

  • IMPORTANT: this commit and the previous one only work on PHP 7+. Don't update Subs-BBC.php if you're using an older version! This will be fixed later.
  • Spacinazi. Big time. (Subs-BBC.php)
  • Removed some useless things that were obviously leftovers of a bad print_r/var_dump, like arrays indexed from 0. Also, just as a quick note, array(1 => 'hello', 'world') will return an index of 2 for 'world'. It's a nice thing to know. See font size handling. (Subs-BBC.php)
  • Started reintegrating a couple validation functions into the array. This needs testing, I'm pretty sure this will neither be faster nor slower, but it just looks better and is easier to debug. (Subs-BBC.php)
  • Note: I removed an allowed tag mention in the spoiler tag, when it only had a single space instead of a list of tags. My guess is that Pete pressed space by mistake when filling in the database. Also noticed that 'len' was being used... strlen() would do the job fine. After all it's more about convenience than speed here (we're in an era of fast web hosting where... who cares about BBCode speed?!)
  • Note: Another thing, I've seen spaces in 'li', 'media' and other tags that got removed. They don't seem to show up in rev d3a5a117eade320a3d8b89b46f667d9f0a7dfd17, where the original BBCode was moved to the database, but I'm also unable to find a version of install files from that day so I don't know if these were errors made at export time. I really think we should compare with the old code.
Features / Re: New revs
« on March 18th, 11:44 AM »
[Commit revision 4b63508]
Author: C3realGuy
Date: Thu, 09 Feb 2017 12:46:03 +0100
Stats: 1 file changed; +857 (insertions), -63 (deletions)

  • BBCodes are now hardcoded in Subs-BBC again.
  • Still loading bbcodes from plugins from database.
  • Should increase performance.

[Commit revision 5c077e8]
Author: Nao
Date: Sat, 18 Mar 2017 11:44:36 +0100
Stats: 1 file changed; +857 (insertions), -63 (deletions)

  • Merge pull request #58 from C3realGuy/dev_bbc_move_only_bbc_to_disk
  • BBCodes are now hardcoded in Subs-BBC again.
Features / Re: New revs
« on March 18th, 11:27 AM »
Quote from Nao on March 13th, 10:41 PM
Updated a date and position. ;)
Yeah CG, thought you'd appreciate that ;)
Least I could do, really! I'd just forgotten about that file...
Bug reports / Couple things to look into...
« on March 18th, 11:25 AM »
I really, really don't have time these days, so can anyone (okay, CerealGuy) look into these potential issues?

- DoLogin() in Subs-Login accesses we::$user['ip'] (previously $user_info['ip']). I couldn't find any reference to we::$user being set during the login process, leading me to believe maybe we should use $user_settings everywhere across that short function. Can you find one reference to it..?

- On LT I've been marking topics as unread and noticed the number of unread counts was higher than before I reached said topic. I specifically rewrote the unread system to make sure it would keep track of it. Can you look into it and determine if I screwed up something..? :edit: Just tried on your last post on the BBC topic, and voilà, 9 unread posts... I definitely screwed something up then, because I'm positive that it used to work.

Features / Re: New revs
« on March 13th, 10:41 PM »
[Commit revision 38d17d4]
Author: Nao
Date: Mon, 13 Mar 2017 22:40:48 +0100
Stats: 1 file changed; +2 (insertions), -2 (deletions)

  • Updated a date and position. ;) (contributors.txt)
Bug reports / [Security] Re: BBCode in SQL Database
« on March 13th, 10:33 PM »
I'm currently very busy adding a large feature to Lestrade's (see over there, it's being discussed), so I really don't have the time for this I'm afraid.
Did you check that all your spaces are there, around dots? Like, 'Hello'.$world; should be 'Hello' . $world; for instance. (I'm only saying because that's the thing I noticed in your previous pull request.)

Wysiwyg: feel free to make a poll on about overall use (not use by forum admins but by their communities...), for now I don't see much of a reason to remove it entirely, maybe add an option to disable it... I don't know.

The rest: okay, I still haven't read your mammoth post..... :sob:
Features / Re: Language revs
« on March 13th, 10:30 PM »
(Used 'squash' for the first time on github, looks like it's working fine... Your commit is directly in Wedge, without an extra merge commit. Hopefully it doesn't break your own repo...?)
Features / Re: Language revs
« on March 13th, 10:29 PM »
[Commit revision d920738]
Author: C3realGuy
Date: Mon, 13 Mar 2017 22:29:14 +0100
Stats: 1 file changed; +1 (insertion), -0 (deletion)

  • Update Notifications.german.php (#33)
Features / Re: New revs
« on March 13th, 10:27 PM »
[Commit revision 113d4e4]
Author: C3realGuy
Date: Sat, 11 Mar 2017 16:59:35 +0100
Stats: 6 files changed; +17 (insertions), -10 (deletions)

  • Allow setting the max length a subject should have.
  • If subject is too long, yield an error.
  • Introduced $settings['max_subjectLength'].
  • Introduced $txt['error_subject_too_long'] in Errors.english.php
  • Introduced $txt['max_subjectLength'] and $txt['max_subjectLength_zero']
  •  in ManagePosts.english.php
  • Also using vsprintf for errors now to support more than one argument.
  • Before the limit for subject size was inconsistent. For editor it was
  •  80, for Post/Post2.php it was 100. We now use the same limit for all.
  • (ManagePosts.php, Post.php, Post2.php, Post.template.php, Errors.english.php, ManagePosts.english.php)

[Commit revision 2999165]
Author: C3realGuy
Date: Sun, 12 Mar 2017 17:04:11 +0100
Stats: 1 file changed; +1 (insertion), -1 (deletion)

  • Subject => subject

[Commit revision dc72afe]
Author: Nao
Date: Mon, 13 Mar 2017 22:27:11 +0100
Stats: 6 files changed; +17 (insertions), -10 (deletions)

  • Merge pull request #59 from C3realGuy/dev_max_subject_length
  • Allow setting the max length a subject should have.
Features / Re: New revs
« on March 11th, 11:32 AM »
[Commit revision 1fcd685]
Author: Nao
Date: Sat, 11 Mar 2017 11:22:15 +0100
Stats: 2 files changed; +5 (insertions), -5 (deletions)

  • Updated $can_filter to include Firefox 35+ and Android KitKat browser, and $can_sticky to include Chrome 56+ (AT LAST!) and remove the small hack in my 'follow me' implementation. (common.css, sections.css)
  • I'm also considering removing the entire follow_me function from topic.js... Its main problem is that it makes it hard (if not impossible?) to change the layout of avatar boxes. The only browser that need it now are IE 8 and above. I wanna say I don't care about them... I don't know.

[Commit revision ded9e47]
Author: Nao
Date: Sat, 11 Mar 2017 11:32:23 +0100
Stats: 1 file changed; +14 (insertions), -0 (deletion)

  • Not sure this'll work 100% because I neither have opcache nor APC installed on my current test server, but apparently it's a good thing to invalidate stuff. Needs testing. (Subs-Cache.php)
Bug reports / Re: Looks in IE and Edge.
« on March 7th, 12:41 AM »
Edge has so many features that aren't implemented yet ( that I don't consider them on the same level as Chrome or Firefox. In fact I'm pretty sure many people at Microsoft were considering switching IE to Webkit/Blink, but the W3C would really rather have as many different HTML rendering engines as possible (they were already quite pissed off that Opera gave up on Presto...)

Plus Edge doesn't really have the usage stats it's purported to have.

Opera Chromium + Sidewise extension are really the best for a power user.

PS: I don't remember having to use something else than Chromium to open a site in the last 3-4 years.
Features / Re: New revs
« on March 6th, 10:40 PM »
[Commit revision 3c2eb2f]
Author: Nao
Date: Mon, 06 Mar 2017 22:40:06 +0100
Stats: 3 files changed; +7 (insertions), -7 (deletions)

  • I'm reverting an old commit from September 16, 2014 that 'fixed' IE11 not being able to load compressed CSS/JS. The problem seems to be linked to the server, I need to test it more. I may re-revert this later, I don't know yet. Needs some testing from other parties. (Class-Editor.php, Subs-BBC.php, Subs-Cache.php)