The future of prosilver (phpBB 4)

[Mikolaj Kowalczyk]

the majority of the community would much rather see the minority do the work and reap the benefits rather than pitch in to help

The proof is when people say there's a bug or something wrong here or there and can't even be bothered to spend 2 minutes to open a ticket, much less fix the issue.

It's strange how people get on to the phpBB teams and develop attitude problems, politeness and courtesy are free.

Just like 5 years ago, some big ideas have been floated across and then nothing, no development.


The things I find wrong with your post are:

Assumption 1:
"the majority of the community would much rather see the minority do the work"

I've been using phpBB since 2010 ish and I have always found that members of this very forum have always been happy to help and input their ideas.

The problem is a lot of them get shut down and they don't bother offering again - one of the reasons for that is there are members on this forum who post with a bad attitude towards other posters - and it is allowed.

There is no need for someone to talk down to someone else just because they have a different idea.



Assumption 2:
"The proof is when people say there's a bug or something wrong here or there and can't even be bothered to spend 2 minutes to open a ticket, much less fix the issue."

Filing bug reports is a longish process, there's too many drop-downs and half the time it is better to do it by 'opening in a new tab' because half the pop up does not load.

Perhaps that is one of the reasons why when people point out bugs on this forum - others don't bother filing a report either - because the process is longggg.

Even when bugs are reported, people then reply trying to imply it is not a bug, because if they have not seen it - it doesn't exist, you tell them how to replicate it and they are not that interested.

Some people file a bug and put the fix in with it - it takes forever for it to actually get implemented - even for the most simple of things.

Perhaps there are so many bugs filed that the development team have got lost with them all?

If bugs were reported on the community first, other members could confirm it is a bug, others could suggest a fix - and then it could be put into the bug tracker.

This would solve the problem of the bug tracker being crowded with reported bugs that not actually bugs.



Assumption 3:
Like the old dev, Hanakin, you and others suggest that prosilver is so bad and needs huge work etc etc but in it's current state prosilver can be made fully responsive and style designers have been making it look fully modern for years.

The main problem with prosilver is that some html is still being served with php, there are many examples of it but the only one I can think of from the top of my head is the log in the MCP, I know that some of these instances were remove a year or two ago.




My suggestions:

1) Communication,
Some of the most talented coders have autism and communication problems, perhaps having a community team who can politely communicate without developing an inferiority complex would help, get some polite people involved and then the people with communication problems can sit back and code while the community team do the communicating side of things.


2) Actually ask people if they would like to get involved,
Just because you say and you assume people do not want to help - does not make it true.
Pop up a post asking and see if anyone responds. You may get proven wrong but being proven wrong happens to everyone at some point in life.

Having experience of working with people special needs etc, I know that there are so many people out there with communication difficulties who don't know how to ask for help - these often go under the radar until their friends and family step in.


3) Development plan,
A - Perhaps making a list of all the instances of php serving HTML into the templates and working through it to eradicate it.
B - Making a list of all the bugs on a forum post, then people can step forward if they know how to solve them and as mentioned above filing.


One other point that I would like to ask you and would have liked to ask Hanakin.

Prosilver has over 100 HTML templates - Do you know what they are all for?? and do you know where they are all located on the forum??

Anyone involved in updating prosilver or developing a new style should at the least have an understanding of how prosilver actually works.



The bottom line is, for phpBB to move forward, communication is vital, why should such a good project get ruined after all these years just because people can't communicate properly and put together a proper plan of development.

At this rate by the time someone with communication skills gets the project plan sorted - all the ageing people that have put hours into developing the back end of the software over the years will have moved on.... then the wheels will come off because some of the newer people joining up have been to ignorant to learn and get an understanding of how the software works first - before trying to modernise it.

[Steve]

Do you think Twig could strip the HTML from prosilver and just reveal template variables? Skeleton of prosilver?

TBH I hadn't even thought of that, and am not sure how it would work. What did you have in mind?

Basically, use twig to strip HTML and leave just template variables and statements... Kasimi's twig convertor extension is possibly a good start to write a script to strip prosilver to its skeleton...

//Edit

Code: Select all

<!DOCTYPE html>
<html lang='en'>
<head>
<title>Basic HTML5 document</title>
<meta charset='utf-8'>
<style>
</style>
<script>
</script>
</head>
<body>
</body>
</html>

retain a basic HTML structure for the template?

[Meis2M]

The project isn't closed.

Look, I get that people are frustrated with the progress of things but the hard to swallow pill is the majority of the community would much rather see the minority do the work and reap the benefits rather than pitch in to help. The proof is when people say there's a bug or something wrong here or there and can't even be bothered to spend 2 minutes to open a ticket, much less fix the issue.

If I was getting paid I'd drop everything and spend my entire day working on Neptune but as I'm a volunteer (as with everyone else), I have to prioritise other things that actually make me money. I don't mind volunteering on phpBB work, it's why I'm here but it does mean progress is not going to be anywhere near as fast as people would like.

phpbb is free and you are speak about money? the is not any PR in neptune github after 3 month ! and you say i have no time i have no money ! so why you volunteer for handling this project?

you know why we are speaking about that? bcs we love phpbb ! bcs phpBB 4 is underdeveloping from 2012 and we are in 2025 ! 13 year for a version ! it is not to long for a project? maybe some guys like you in phpbb team is bcs of that!
most of my persian users moved to xenforo !

i dont like your words with people !

[Gumboots]

TBH I hadn't even thought of that, and am not sure how it would work. What did you have in mind?

Basically, use twig to strip HTML and leave just template variables and statements... Kasimi's twig convertor extension is possibly a good start to write a script to strip prosilver to its skeleton...

//Edit

Code: Select all

<!DOCTYPE html>
<html lang='en'>
<head>
<title>Basic HTML5 document</title>
<meta charset='utf-8'>
<style>
</style>
<script>
</script>
</head>
<body>
</body>
</html>

retain a basic HTML structure for the template?

There's the catch. People are going to need HTML to get the thing to render in a usable form, so you need to provide all of that too.

I get what you are thinking: that style authors could do all their own HTML. Frankly, in reality, most of them couldn't. That's why most styles are minor presentation revisions on top of default markup.

[Steve]

I'm not thinking style author's, more getting rid of the HTML to save manually opening each file in notepad++ , to build a new style from scratch.

[Gumboots]

Ok, you have completely lost me. Can you clarify?

Are you suggesting locking up all the markup in the back end somewhere?

I would be strongly opposed to that concept.

[Steve]

Look...

this:

Code: Select all

{% INCLUDE 'overall_header.html' %}

<h2 class="faq-title">{{ lang('FAQ_TITLE') }}</h2>


<div class="panel bg1" id="faqlinks">
	<div class="inner">
		<div class="column1">
		{% for faq_block in loops.faq_block %}
			{% if faq_block.SWITCH_COLUMN or (SWITCH_COLUMN_MANUALLY and faq_block.S_ROW_COUNT == 4) %}
				</div>

				<div class="column2">
			{% endif %}

			<dl class="faq">
				<dt><strong>{{ faq_block.BLOCK_TITLE }}</strong></dt>
				{% for faq_row in faq_block.faq_row %}
					<dd><a href="#f{{ faq_block.S_ROW_COUNT }}r{{ faq_row.S_ROW_COUNT }}">{{ faq_row.FAQ_QUESTION }}</a></dd>
				{% endfor %}
			</dl>
		{% endfor %}
		</div>
	</div>
</div>

{% for faq_block in loops.faq_block %}
	<div class="panel {% if faq_block.S_ROW_COUNT is odd %}bg1{% else %}bg2{% endif %}">
		<div class="inner">

		<div class="content">
			<h2 class="faq-title">{{ faq_block.BLOCK_TITLE }}</h2>
			{% for faq_row in faq_block.faq_row %}
				<dl class="faq">
					<dt id="f{{ faq_block.S_ROW_COUNT }}r{{ faq_row.S_ROW_COUNT }}"><strong>{{ faq_row.FAQ_QUESTION }}</strong></dt>
					<dd>{{ faq_row.FAQ_ANSWER }}</dd>
				</dl>
				<a href="#faqlinks" class="top">
					<i class="icon fa-chevron-circle-up fa-fw icon-gray" aria-hidden="true"></i><span>{{ lang('BACK_TO_TOP') }}</span>
				</a>
				{% if not faq_row.S_LAST_ROW %}<hr class="dashed" />{% endif %}
			{% endfor %}
		</div>

		</div>
	</div>
{% endfor %}

{% INCLUDE 'jumpbox.html' %}
{% INCLUDE 'overall_footer.html' %}

to this:

Code: Select all

{% INCLUDE 'overall_header.html' %}

{{ lang('FAQ_TITLE') }}


<id="faqlinks">

{% for faq_block in loops.faq_block %}

{% if faq_block.SWITCH_COLUMN or (SWITCH_COLUMN_MANUALLY and faq_block.S_ROW_COUNT == 4) %}
{% endif %}

{{ faq_block.BLOCK_TITLE }}
{% for faq_row in faq_block.faq_row %}
<a href="#f{{ faq_block.S_ROW_COUNT }}r{{ faq_row.S_ROW_COUNT }}">{{ faq_row.FAQ_QUESTION }}</a>
{% endfor %}

{% endfor %}


{% for faq_block in loops.faq_block %}
{% if faq_block.S_ROW_COUNT is odd %}bg1{% else %}bg2{% endif %}

{{ faq_block.BLOCK_TITLE }}

{% for faq_row in faq_block.faq_row %}

<id="f{{ faq_block.S_ROW_COUNT }}r{{ faq_row.S_ROW_COUNT }}">{{ faq_row.FAQ_QUESTION }}
{{ faq_row.FAQ_ANSWER }}

<a href="#faqlinks">{{ lang('BACK_TO_TOP') }}</a>
{% if not faq_row.S_LAST_ROW %}{% endif %}
{% endfor %}

{% endfor %}

{% INCLUDE 'jumpbox.html' %}
{% INCLUDE 'overall_footer.html' %}

[Gumboots]

Some idle thoughts I have had while messing with custom style ideas...

Prosilver is fragmented. I'm sure it doesn't have to be this fragmented. I mean I get the reasoning: that having as many templates as possible makes things more modular, which can ease customisation, and can potentially improve performance by not loading stuff you don't need to load. Fair enough.
But, things can be modular just by having associated bits as functions that get called wherever you want them in that template, or don't get called at all when you don't want them.

The thing is that the more you fragment stuff the more confusing it will be for anyone who wants to customise it. Keeping track of it all can be a nightmare, particularly when there is no consistent indentation across templates (one of my pet hates) and when opening and closing tags can have no obvious connection to anything else.

This also applies to CSS. Yes, I do get that separating colours from other presentation is the easiest way of doing multicolour styles. It will also help if people just want to edit colours on any existing style. But, all of the other fragmentation of the CSS seems to be done on the basis of element tag rather than where it is used.

For example: if there are some things specific to the editor, and if most sites won't allow guest posting, then serving up editor CSS to guests is pointless. In performance terms it's a good candidate for its own file, regardless of the element tags. Ditto for most of the UCP and MCP stuff.

It also makes sense from a human perspective, because a human will think to look in the editor file for editor stuff instead of having to back track through half a dozen files that sort things by tag.

[Gumboots]

Look...

this:

Code: Select all

{% INCLUDE 'overall_header.html' %}

<h2 class="faq-title">{{ lang('FAQ_TITLE') }}</h2>


<div class="panel bg1" id="faqlinks">
	<div class="inner">
		<div class="column1">
		{% for faq_block in loops.faq_block %}
			{% if faq_block.SWITCH_COLUMN or (SWITCH_COLUMN_MANUALLY and faq_block.S_ROW_COUNT == 4) %}
				</div>

				<div class="column2">
			{% endif %}

			<dl class="faq">
				<dt><strong>{{ faq_block.BLOCK_TITLE }}</strong></dt>
				{% for faq_row in faq_block.faq_row %}
					<dd><a href="#f{{ faq_block.S_ROW_COUNT }}r{{ faq_row.S_ROW_COUNT }}">{{ faq_row.FAQ_QUESTION }}</a></dd>
				{% endfor %}
			</dl>
		{% endfor %}
		</div>
	</div>
</div>

{% for faq_block in loops.faq_block %}
	<div class="panel {% if faq_block.S_ROW_COUNT is odd %}bg1{% else %}bg2{% endif %}">
		<div class="inner">

		<div class="content">
			<h2 class="faq-title">{{ faq_block.BLOCK_TITLE }}</h2>
			{% for faq_row in faq_block.faq_row %}
				<dl class="faq">
					<dt id="f{{ faq_block.S_ROW_COUNT }}r{{ faq_row.S_ROW_COUNT }}"><strong>{{ faq_row.FAQ_QUESTION }}</strong></dt>
					<dd>{{ faq_row.FAQ_ANSWER }}</dd>
				</dl>
				<a href="#faqlinks" class="top">
					<i class="icon fa-chevron-circle-up fa-fw icon-gray" aria-hidden="true"></i><span>{{ lang('BACK_TO_TOP') }}</span>
				</a>
				{% if not faq_row.S_LAST_ROW %}<hr class="dashed" />{% endif %}
			{% endfor %}
		</div>

		</div>
	</div>
{% endfor %}

{% INCLUDE 'jumpbox.html' %}
{% INCLUDE 'overall_footer.html' %}

to this:

Code: Select all

{% INCLUDE 'overall_header.html' %}

{{ lang('FAQ_TITLE') }}


<id="faqlinks">

{% for faq_block in loops.faq_block %}

{% if faq_block.SWITCH_COLUMN or (SWITCH_COLUMN_MANUALLY and faq_block.S_ROW_COUNT == 4) %}
{% endif %}

{{ faq_block.BLOCK_TITLE }}
{% for faq_row in faq_block.faq_row %}
<a href="#f{{ faq_block.S_ROW_COUNT }}r{{ faq_row.S_ROW_COUNT }}">{{ faq_row.FAQ_QUESTION }}</a>
{% endfor %}

{% endfor %}


{% for faq_block in loops.faq_block %}
{% if faq_block.S_ROW_COUNT is odd %}bg1{% else %}bg2{% endif %}

{{ faq_block.BLOCK_TITLE }}

{% for faq_row in faq_block.faq_row %}

<id="f{{ faq_block.S_ROW_COUNT }}r{{ faq_row.S_ROW_COUNT }}">{{ faq_row.FAQ_QUESTION }}
{{ faq_row.FAQ_ANSWER }}

<a href="#faqlinks">{{ lang('BACK_TO_TOP') }}</a>
{% if not faq_row.S_LAST_ROW %}{% endif %}
{% endfor %}

{% endfor %}

{% INCLUDE 'jumpbox.html' %}
{% INCLUDE 'overall_footer.html' %}

Ok, so you want to take markup out of the HTML files and hide it in the PHP files. Not sure that is going to be useful or popular.

[Steve]

Ok, so you want to take markup out of the HTML files and hide it in the PHP files. Not sure that is going to be useful or popular.

No, convert the files and download them, I may have the wrong person to ask here... I was told you knew how to use the twig template system.

The pu

[Gumboots]

I know how to use bits of Twig for some things. That's about my current limit.

[nou nou]

The project isn't closed.

Look, I get that people are frustrated with the progress of things but the hard to swallow pill is the majority of the community would much rather see the minority do the work and reap the benefits rather than pitch in to help. The proof is when people say there's a bug or something wrong here or there and can't even be bothered to spend 2 minutes to open a ticket, much less fix the issue.

If I was getting paid I'd drop everything and spend my entire day working on Neptune but as I'm a volunteer (as with everyone else), I have to prioritise other things that actually make me money. I don't mind volunteering on phpBB work, it's why I'm here but it does mean progress is not going to be anywhere near as fast as people would like.

phpbb is free and you are speak about money? the is not any PR in neptune github after 3 month ! and you say i have no time i have no money ! so why you volunteer for handling this project?

you know why we are speaking about that? bcs we love phpbb ! bcs phpBB 4 is underdeveloping from 2012 and we are in 2025 ! 13 year for a version ! it is not to long for a project? maybe some guys like you in phpbb team is bcs of that!
most of my persian users moved to xenforo !

i dont like your words with people !

That's what volunteering is, you do something for something other than money. Sheesh.

13 years for a version you say? Many people - including me - are of the opinion that once phpBB moved to extensions it should have been called 4.0 and not 3.1 - I would bet you there would be a lot less complaining about how phpBB development has stalled etc. It's nonsense, frankly, it's just a number. But people love numbers, what can you do?

If you like Xenforo better, just use Xenforo, goodbye already. It's 200 bucks for a self-hosted license, if you want proper search and a couple of other fairly basic features, double that. It's 100 bucks per year on top of that if you want updates (so that would be about 1200 on top if you would have bought in 2012). Oh yes you need a server with root level access. Oops difficult. Guess you want their Cloud service then.

Screenshot 2025-02-22 010741.png

Boom.

That's the cheap per year pricing, oh and add VAT of course.

And ultimately Xenforo really isn't better than phpBB. I haven't seen anything that's a reason for me to move platform as my own community hs been growing over a decade. I've tried (and I still keep myself informed about) a lot of forum solutions. I was most enchanted by Flarum for a while, then returned to phpBB. It really just works. Is it perfect? No, nothing is. It's most definitely not stagnant though.

OK, Xenforo has an API, that's neat.

Coincidentally the person whose "words you don't like" is also the same person giving that a go - you got it - for free. You're welcome.

Maybe try some humility before wanting to tear someone a new arsehole. Xenforo might not be why your users have moved.

[Steve]

https://www.phpbb.com/customise/db/style/cleansilver_2/

I vote this to be a good start?

[Gumboots]

Could do with a few changes, but it's not a bad start for a basic default. Part of the problem is that although the looks are simple (and can be easily changed) it's still all Prosilver behind the eye candy. But if you are talking about the basic look and layout then sure, something like that should be fine.

Re changes: get rid of the daft responsive-hide and responsive-show shiznit. There are easier ways of handling that without extra markup. And seriously, who wants board or topic stats on mobile anyway? It's just crud that gets in the way of more useful things. I'd rather have the last post staying on mobile instead of topic counts or whatever. At least I can use it.

Another point: I really do have to wonder about the usefulness of the little pages links for each topic on the topic index. I have never used them in my life, as far as I can recall. I usually only want the first post, or the first unread, or the last post. I rarely want to wrack my brains trying to remember which page of a 39 page thread had some post that I may want occasionally, and if I ever do the pages index inside the topic view itself is a much more convenient way of finding it, because you can use the dropdown to enter any page number instead of just the visible ones.

Really, getting rid of the little pages links for each topic on the topic index (and the associated non-functional icon) would save rendering a lot of crud, would clean up the presentation, and would make responsive much less hassle. People often get excited about what they can add. Let's also think about stuff we can ditch for extra sanity.

[Steve]

think about stuff we can ditch for extra sanity.

[I personally can not stand [what's this; what that lay-outs, statistics in your face! ]