Feedback to: Textpattern CMS 4.7.0 beta released

planeth · 2018-03-21 17:09:45

When using url pattern /title, accessing section “articles” –like: http://my-website/articles/– gives a 404

Last edited by planeth (2018-03-21 17:10:10)

Bloke · 2018-03-21 17:23:50

Dammit, thanks for the report.

Is this a themes thing? Or did we break it when we tweaked pretext here or here? Any ideas, Oleg?

4.6.2 still honoured /section (as long as it didn’t clash with an article title) even in /title mode.

Last edited by Bloke (2018-03-21 17:25:30)

planeth · 2018-03-21 17:52:55

Don’t think it’s a theme thing.
I tried with a new install.
And if you turn back the url pattern to /section/title it works

Bloke · 2018-03-21 17:57:39

I meant whether it’s something that broke due to the introduction of themes, as it might not be able to get the theme in use for the given Section landing page, so issues a 404. Or it may be the commits I mentioned above, or perhaps something further back.

We were about to go live with another beta, but I’ll hold off a little while (a few hours) to see if we can fix this first. Anyone with any ideas, shout now please!

EDIT: We should probably check that everything still works with other permlink schemes like day/month/year and messy too.

Last edited by Bloke (2018-03-21 17:58:59)

etc · 2018-03-21 18:57:01

Mea culpa, but the faulty commit is much older. I actually think that resolving /articles as Section='articles' if url_title='articles' does not exist was a bad idea. It suffices to create an article called “Articles” and /articles is no more the section articles link — bad thing SEO-wise. But /articles/ should link to section articles, will fix this.

And while we are on it, should we also consider /articles/title as an article link, even in title_only mode? In 4.6 it is resolved as Section='articles' unless url_title='articles' exists.

Other modes should be ok.

Bloke · 2018-03-21 19:51:14

etc wrote #310217:

resolving /articles as Section='articles' if url_title='articles' does not exist was a bad idea.

Probably. If we fix it, do you think it’ll impact a lot of users? I guess most are savvy enough to figure that you wouldn’t name an article after your Section, but it wouldn’t hurt to defend against it if we can.

But /articles/ should link to section articles

Yes that makes sense and is a great argument for the trailing slash acting like a “directory” (landing page). The absolute minority I expect to be hit by any change in URL handling behaviour then have a way out to restore operation by simply appending a slash to their URLs to make landing pages work again.

And while we are on it, should we also consider /articles/title as an article link, even in title_only mode? In 4.6 it is resolved as Section='articles' unless url_title='articles' exists.

Sure, why not. I can’t see anyone complaining if you supply too much info in the URL.

ISTR in days gone by that using /id in one or more of the non-id modes worked too, as long as the article itself wasn’t all numeric. Uhhh, maybe. Can’t remember. We might have got rid of that ages ago as I can’t make it do it now on my 4.7 test rig. It was arguably a bug anyway.

Thanks for looking at this and fixing it. Much obliged.

Last edited by Bloke (2018-03-21 19:51:57)

etc · 2018-03-21 20:04:07

Bloke wrote #310218:

ISTR in days gone by that using /id in one or more of the non-id modes worked too as long as the article itself wasn’t all numeric. We might have got rid of that ages ago as I can’t make it do it now on my 4.7. test rig. It was arguably a bug anyway.

Yes, in id_title mode /13/ was a link to Section 13 if ID=13 does not exist. But again, one day this becomes a link to Article 13. Worse, <txp: section link /> continues to produce /13/. This should be fixed too.

Thanks for looking at this and fixing it. Much obliged.

title_only should be fixed now, sorry for delaying beta 2. But I still don’t know how to resolve /13/ in id_title mode: article or section link? Technically, url_title can be empty…

CodeWalker · 2018-03-21 20:29:46

Forgive me if this is already on your radar, but I noticed something with the login page. Not if its “supposed” to do this or if its a beta wobble.

Visiting domain.com/textpattern gives me an unstyled page with just the word Textpattern in times new roman in big fat letters. visiting domain.com/textpattern/ shows me the login page.

Odd, these are technically the same page, shouldnt need the slash on the end I don’t think.

Worth sticking this on Github as an issue?

I’m running this locally on a mac (high sierra) on Laravel Valet (which i’m pretty sure is Nginx under the rug) & PHP 7.

Last edited by CodeWalker (2018-03-21 20:30:22)

gaekwad · 2018-03-21 20:43:45

CodeWalker wrote #310221:

I’m running this locally on a mac (high sierra) on Laravel Valet (which i’m pretty sure is Nginx under the rug) & PHP 7.

That’s possibly an Nginx directive snag at your end. Any chance you could pick through and find the Valet site config? I ask because I’m running a similar setup to you (Nginx + PHP7.0) and it’s correctly finding the /textpattern/ URL.

You might want to check for this in the Nginx directives, it’ll likely be snuck away in a Location block:

try_files $uri $uri/ /index.php?$args;

That translates to: try the URL, then the URL with a /, then /index.php with args, then throw an error.

CodeWalker · 2018-03-21 21:43:41

gaekwad wrote #310222:

That’s possibly an Nginx directive snag at your end. Any chance you could pick through and find the Valet site config? I ask because I’m running a similar setup to you (Nginx + PHP7.0) and it’s correctly finding the /textpattern/ URL.

You might want to check for this in the Nginx directives, it’ll likely be snuck away in a Location block:

try_files $uri $uri/ /index.php?$args;...

That translates to: try the URL, then the URL with a /, then /index.php with args, then throw an error.

I’ll see what I can find out.

It might be down to the driver. Valet uses a series of drivers to enable common cms systems to work.

As I understand it, this acts as a bridge between valet and nginx so you dont have to get your hands dirty with config files. Unfortunately I don’t know enough to write a Textpattern specific driver. Maybe the general purpose driver isnt quite doing what txp expects.

The Custom driver docs explain it if anyone feels like taking up the challenge.

Last edited by CodeWalker (2018-03-21 21:47:04)

CodeWalker · 2018-03-21 21:58:19

Ah ha! i found the default nginx config for valet…. anything wonky in here? I dont know what im looking at….

server {
    listen 80 default_server;
    root /;
    charset utf-8;
    client_max_body_size 128M;

    location /41c270e4-5535-4daa-b23e-c269744c2f45/ {
        internal;
        alias /;
        try_files $uri $uri/;
    }

    location / {
        rewrite ^ /Users/hashsalt/.composer/vendor/laravel/valet/server.php last;
    }

    access_log off;
    error_log /Users/hashsalt/.valet/Log/nginx-error.log;

    error_page 404 /Users/hashsalt/.composer/vendor/laravel/valet/server.php;

    location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass unix:/Users/hashsalt/.valet/valet.sock;
        fastcgi_index /Users/hashsalt/.composer/vendor/laravel/valet/server.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME /Users/hashsalt/.composer/vendor/laravel/valet/server.php;
    }

    location ~ /\.ht {
        deny all;
    }
}
```

Bloke · 2018-03-21 22:11:07

etc wrote #310219:

Worse, <txp: section link /> continues to produce /13/. This should be fixed too.

Ack. One day. Beta 3 maybe? If not, we’ll figure it out later…

title_only should be fixed now, sorry for delaying beta 2.

That’s perfect, thanks. No worries about the delay. I’d rather wait an extra few hours and get it working than rush something out that’s known faulty.

And on that note, I just noticed something else a little weird.

STR:

1. Set a Page template up with this in it somewhere:

<txp:if_individual_article>
  <txp:link_to_prev>&laquo; Previous article</txp:link_to_prev>
  <txp:link_to_next>Next article &raquo;</txp:link_to_next>
<txp:else />
  <txp:older>Olderino &raquo;</txp:older>
  <txp:newer>&laquo;Newerino</txp:newer>
</txp:if_individual_article>

2. Set that template to process any /section.
3. Set debugging mode on and URL scheme to /section/title.
4. Visit any article and note article renders fine.
5. Switch URL scheme to year/month/day/title.
6. Visit the same article at its proper Y/M/D/title URL.
7. Note the following error thrown:

Tag error: <txp:link_to_prev>&laquo; Previous article</txp:link_to_prev> ->  Notice: A non well formed numeric value encountered while parsing form None on page default

textpattern/lib/txplib_misc.php:5601 date()
textpattern/publish/taghandlers.php:1565 permlinkurl()
textpattern/publish/taghandlers.php:1603 link_to()
link_to_prev()
textpattern/vendors/Textpattern/Tag/Registry.php:116 call_user_func()
textpattern/lib/txplib_publish.php:596 Textpattern\Tag\Registry->process()
textpattern/lib/txplib_publish.php:520 processTags()
textpattern/publish/taghandlers.php:3694 parse()
if_individual_article()
textpattern/vendors/Textpattern/Tag/Registry.php:116 call_user_func()

Same error for <txp:link_to_next>. Both next/prev tags link to 1970/01/01.

Eeek!

Last edited by Bloke (2018-03-21 22:12:31)

Textpattern CMS

Textpattern CMS support forum

#109 2018-03-21 17:09:45

Re: Feedback to: Textpattern CMS 4.7.0 beta released

#110 2018-03-21 17:23:50

Re: Feedback to: Textpattern CMS 4.7.0 beta released

#111 2018-03-21 17:52:55

Re: Feedback to: Textpattern CMS 4.7.0 beta released

#112 2018-03-21 17:57:39

Re: Feedback to: Textpattern CMS 4.7.0 beta released

#113 2018-03-21 18:57:01

Re: Feedback to: Textpattern CMS 4.7.0 beta released

#114 2018-03-21 19:51:14

Re: Feedback to: Textpattern CMS 4.7.0 beta released

etc wrote #310217:

#115 2018-03-21 20:04:07

Re: Feedback to: Textpattern CMS 4.7.0 beta released

Bloke wrote #310218:

#116 2018-03-21 20:29:46

Re: Feedback to: Textpattern CMS 4.7.0 beta released

#117 2018-03-21 20:43:45

Re: Feedback to: Textpattern CMS 4.7.0 beta released

CodeWalker wrote #310221:

#118 2018-03-21 21:43:41

Re: Feedback to: Textpattern CMS 4.7.0 beta released

gaekwad wrote #310222:

#119 2018-03-21 21:58:19

Re: Feedback to: Textpattern CMS 4.7.0 beta released

#120 2018-03-21 22:11:07

Re: Feedback to: Textpattern CMS 4.7.0 beta released

etc wrote #310219:

Board footer