Retiring ports.php

[Ryan Schmidt]

On Aug 15, 2019, at 09:06, Mojca Miklavec wrote:

> On Thu, 15 Aug 2019 at 15:27, Joshua Root wrote:
>> 
>> I think ports.macports.org is already clearly superior to ports.php, so
>> we should change the Available Ports link to point there. However, we
>> should not remove ports.php so as not to break existing links. I think
>> we should make ports.php queries redirect to the corresponding p.m.o URL
>> when possible (it won't always be possible since ports.php lets you
>> search more fields).
> 
> What about specifying what is still missing and adding that
> functionality to the new app?
> 
>> Thoughts?
> 
> I would definitely like to get a clear visible link to the main
> website, as well as some post to macports-users and macports-announce.
> Potentially we could even keep both sites for a little while. But what
> would also be nice to do is some ability to back-link to the main
> website from ports. Do we have someone with clear suggestions about
> the landing page of ports.macports.org?
> 
>    https://github.com/macports/macports-webapp/issues/47
> 
> ports.php is simply part of the main page, so it's easy to keep
> navigating to other parts of the site; we would need to add something
> to the new app as well. Some kind of top / global menu, and definitely
> improving the landing page.

> At the same time it would also be nice to revive the discussion about
> improving the overall design.
>    https://github.com/constantin-p/macports-site/issues/1
>    https://constantin-p.github.io/macports-site/
> and converge to the design & content that we "all" want :)

I am pleased that a better ports web app and main web site are being worked on, but I have not been following their development and won't be doing so due to spending time on other interests.

The new web site looks great. I haven't examined it in detail so I don't know how it compares to our current site in terms of content: what it has, what it doesn't yet have that it later will, what it doesn't have from the old site that has been decided is unnecessary.

The ports web app looks pretty good too, and certainly better than ports.php.

I agree that once the new ports web app is thought to be ready, old ports.php links should be redirected to the new web app, (rather than serving effectively duplicate content, or answering with a 404 not found), where the new app provides the same functionality as the old. We can do the redirects by editing ports.php (which might be easier to start with, especially while we want to redirect some links but not others) or by creating web server rules (which we may want to move to once all links are redirects, since we may want to get rid of the php engine entirely at that point, if we move to GitHub Pages hosting for the rest of the site.) I agree that some of the old ports.php functionality needn't be preserved. For example, ports.php search expressions can use MySQL syntax [1], which I would just as soon not expose to users going forward.

My hope is that all of our web pages adopt a unified navigation header. Some time ago I tried to think about what such a navigation header would contain, but it is difficult to encompass all of our sites in a way that makes sense, is not too wide, and is not overwhelming to casual users. I thought it might be worth thinking about classifying links as either "for users" or "for developers", so that casual users needn't encounter developer links unless they visit a developer-centric site like the buildbot, but it's not always easy to draw the line (e.g. Trac is for both users and developers).

Note that the ports web app needn't be a separate hostname. If we want it to be at www.macports.org/ports, for example, we can do that by adding web server rules in the CDN interface. We already do this to map /news/ to GitHub Pages while the rest goes to Apache on Braeburn.


[1] for example https://www.macports.org/ports.php?by=name&substr=mysql%25server