No articles appearing, no reason why not

Destry · 2016-10-07 17:58:40

Strange problem.

I have local site with a production sister.

The local was 4.6 beta, I updated to 4.6.1 and all is okay otherwise but the articles don’t appear anywhere on the site. This isn’t due to 4.6.1, however, because it was like that to begin with. I thought it was just skeleton content for dev purposes (it’s been a long time since I looked at it) and didn’t realize the full extent until afterward.

But once I realized and poked around, I couldn’t figure out what the problem was.

So then I thought I’d update the local with the production database, which is looking and running fine with 4.5.7. (Both local and prod are running MySQL 5.7.13). This was a dumb move on my part because I had had already fixed the pesky zeros in the DB tables on local and had to run through this entire process again, then edit the _to_4.6.0.php again. Ugh.

But that didn’t fix the article problem. I’ve run out of ideas what to check. The site uses only one plugin… rvm_maintenance, and that’s off.

.htaccess file contents: 
------------------------
# BEGIN Textpattern
#DirectoryIndex index.php index.html

#Options +FollowSymLinks
#Options -Indexes
#ErrorDocument 403 default

<IfModule mod_rewrite.c>
    RewriteEngine On
    #RewriteBase /relative/web/path/

    RewriteCond %{REQUEST_FILENAME} -f [OR]
    RewriteCond %{REQUEST_FILENAME} -d
    RewriteRule ^(.+) - [PT,L]

    RewriteCond %{REQUEST_URI} !=/favicon.ico
    RewriteRule ^(.*) index.php

    RewriteCond %{HTTP:Authorization}  !^$
    RewriteRule .* - [E=REMOTE_USER:%{HTTP:Authorization}]
</IfModule>

#php_value register_globals 0

<IfModule mod_mime.c>
    AddType image/svg+xml  svg svgz
    AddEncoding gzip       svgz
</IfModule>
# END Textpattern

p.

Bloke · 2016-10-07 19:47:45

Any use? Especially take note of etc’s response in which a mis-closed tag now trips up the parser. Previous parser instances were more lax in their parsing of tags.

wet · 2016-10-08 02:29:12

Are the dates in the ‘Articles’ tab list grey or black?

Destry · 2016-10-08 09:37:50

wet wrote #302028:

Are the dates in the ‘Articles’ tab list grey or black?

Black.

Bloke wrote #302025:

Any use? Especially take note of etc’s response in which a mis-closed tag now trips up the parser. Previous parser instances were more lax in their parsing of tags.

Not sure yet, but Pete’s post there did make me double-check “debug” mode again, and I came across a couple errors. I didn’t see them the first time because they only appeared on one section page:

<txp:article form="" id=""> Complained about the id. I changed that tag to an article_custom and the error went away on that on (though I’m not sure yet that meant proper use of an article_custom tag), but none of my site articles have reappeared yet.

The other error seems to be one of those “out of article context” situations when using conditional tags. I don’t know why after more than a decade, but conditional combos still confuse me.

Here’s the error:

Tag error: <txp:if_article_id id=“14”> -> Textpattern Notice: Article tags cannot be used outside an article context. while parsing form None on page Boutique

textpattern/lib/txplib_misc.php:5926 trigger_error()
textpattern/publish/taghandlers.php:1895 assert_article()
if_article_id()
textpattern/vendors/Textpattern/Tag/Registry.php:83 call_user_func()
textpattern/lib/txplib_publish.php:514 Textpattern\Tag\Registry->process()
textpattern/lib/txplib_publish.php:463 processTags()
textpattern/lib/txplib_misc.php:4476 parse()
textpattern/publish.php:562 parse_page()
index.php:105 textpattern()

And here’s the relevant page markup:

<txp:if_article_id id="14">

    <txp:hide> Display "Merci" article </txp:hide>
    <txp:article_custom form="shop-article" id="14" />

 <txp:else />

    <txp:if_article_id id="11">
      <txp:hide> Display "Pas prêt ?" article </txp:hide>
      <txp:article_custom form="shop-article" id="11" />
    </txp:if_article_id>

 <txp:else />

    <txp:hide> Display default "Boutique" article </txp:hide>
    <txp:article form="shop-article" status="sticky" />

</txp:if_article_id>

But even if this is the problem, that markup on an isolated section is enough to wipe out all articles on the entire site? I guess that’s good, because it means one is really forced to check the integrity of their tag architecture. But I suspect there will be a lot of troubleshooting posts coming. ;)

etc · 2016-10-08 10:23:35

Hi Destry,

your second <txp:else /> seems misplaced and might confuse the parser.

jakob · 2016-10-08 10:45:18

That might be the reason. Where is that code appearing?

If this on an individual article page and if I have understood your code correctly, all articles are output with the same form but articles 11 and 14 are “live” articles while other boutique pages are sticky. If that’s the case, you can probably simplify it massively to:

<txp:if_individual_article>
    <txp:article form="shop-article" />
    <txp:article form="shop-article" status="sticky" />
</txp:if_individual_article>

If you’re using that in an article list somewhere on a page to respond to an article id, it would need to be looping through a list of article ids (i.e. from a wrapping txp:article or txp:article_custom) to test against. But then you’re nesting article_custom tags inside another article(_custom) tag to output one or the other live articles or else a sticky article. Unfortunately a wrapping txp:article_custom and txp:article tags can’t do live and sticky at the same time (years ago they could), so your sticky articles won’t show.

You could perhaps do the outer loop with rah_repeat and a list of article ids, and then use either smd_if to test if rah_repeat_value is 11 or 14 or alternatively place <txp:variable name="loop_article_id"><txp:rah_repeat_value /></txp:variable> in a variable and then do <txp:if_variable name="loop_article_id" value="11"> … etc. instead of the txp:if_article_id.

Then again, maybe I’ve misunderstood what you’re trying to do…

Destry · 2016-10-08 11:51:21

I had to familiarize myself with the site again, but that code is the main content for the page in a “Boutique” section:

The sticky article contains two article lists for tools and wire products that connect with a simple PayPal cart.
Article 14 is the “thank you” article URL that PayPal returns a buyer to.
Article 11 is a “Maybe next time” article URL that PayPal returns a potential buyer to if they abandon ship.

Otherwise you’re just supposed to see the products grid (sticky article).

I tried changing to this, based on etc’s hint, but that just added another error:

<txp:if_article_id id="14">

    <txp:hide> Display "Merci" article </txp:hide>
    <txp:article_custom form="shop-article" id="14" />

 <txp:else />

    <txp:if_article_id id="11">
        <txp:hide> Display "Pas prêt ?" article </txp:hide>
        <txp:article_custom form="shop-article" id="11" />

    <txp:else />

        <txp:hide> Display default "Boutique" article </txp:hide>
        <txp:article form="shop-article" status="sticky" />
    </txp:if_article_id>

</txp:if_article_id>

Destry · 2016-10-08 12:00:56

As I said, the whole article-context-in-relation-to-conditionals thing has always escaped me. I’ll keep rearranging the conditionals until I land on the right combo.

@Jakob: I’m sure you’re giving me the answer with your response there, but I’m not grasping what I should be doing.

All I can think of doing at this point is create a new section for the PayPal ‘return to site’ articles and use a simpler conditional on that page for one or the other articles, leaving the Boutique alone with a single article. But adding another section for that seems sloppy at best. Plus we may be going with MLP on this at some point to add English, and I want to keep sections/pages to a minimum when possible.

Last edited by Destry (2016-10-08 13:23:28)

jakob · 2016-10-08 14:27:00

I think I’m getting it now. The articles 11 and 14 are called directly by their page name so they are individual articles. You have them as live-status articles.

What I can’t see is if the boutique is one article with the 7 items written into the body field, or does each item have an article of its own? This, or these, article(s) have sticky-status. I’m guessing it’s the former.

With your current setup, this should work:

<txp:if_individual_article>
    <txp:article form="shop-article" />
<txp:else />
    <txp:article form="shop-article" status="sticky" />
</txp:if_individual_article>

Then what happens is:

merci page = individual article, status=“live” (the default) -> shows the page from the url. You don’t need to test if it is 11 or 14 because that’s already specified by the url
maybe-later page = individual article, status=“live” as above
boutique page = landing page, shows the sticky article / up to 10 sticky articles.

— —

Assuming your boutique page is one article, you could simplify it further if you:

give all your articles live status
make boutique the most recent article chronologically

Then just use:

<txp:article form="shop-article" limit="1" />

That will always show one live article. On the landing page it will automatically start with the most recent article, the boutique page.

— —

If, for arguments sake, your shop were to expand to 25 items (i.e. gets hard to manage as a single article), you could make each boutique item an article of its own and then output the 25 articles on the landing page. In this case, I would reverse the logic you have now and make the “merci” page and “maybe-later” page the sticky articles – because it takes these special pages out of the normal list flow – and make each boutique product article a live article. Then you would do this:

<txp:article form="shop-article" status="sticky" />
<txp:article form="shop-article" limit="99" />

Then what happens is:

merci / maybe-later page = individual article, status=“sticky” -> first tag applies, second tag doesn’t
maybe-later page = individual article, status=“sticky” -> same story
boutique page = landing page -> these are live articles, so the first tag doesn’t apply, but the second does. It shows up to 99 articles of status=“live” (default), skipping the merci and maybe-later pages.

I’m pretty sure you know this – you wrote that great txp logic article all those years ago – so forgive me if I’m stating the obvious.

Destry · 2016-10-09 10:10:25

I wasn’t as clear as I could be, sorry. All articles in question are assigned to the Boutique section, which uses a single page. The sticky is being used as the default landing article. All other articles are ‘live’ status. In the body of the sticky article are two article lists that output the respective tool and wire products. (The ability to use article tags in a body field like this has saved my bacon many times. I hope that has not changed.)

Regarding the “logic” article, you might be thinking about Jeff Soo’s thesis on context, which I should probably read again. I wrote the “building block” articles, which didn’t really cover context. Btw, does anyone know of a concise tutorial about tag context in relation to articles, notably in relation to conditionals and nesting tags? I think some kind of page like that needs to go in the docs under the tag section.

As for your other notes, Jakob, I’ll see if I can rebraid the yarn. :)

jakob · 2016-10-09 12:27:03

Destry wrote #302051:

I wasn’t as clear as I could be, sorry. All articles in question are assigned to the Boutique section, which uses a single page. The sticky is being used as the default landing article. All other articles are ‘live’ status. In the body of the sticky article are two article lists that output the respective tool and wire products. (The ability to use article tags in a body field like this has saved my bacon many times. I hope that has not changed.)

Okay, so that’s a hybrid way. That is also the reason why I guess you were testing for article 11 or 14 in the individual article view, to prevent the individual products being callable individually. Perhaps this, then, would work for you:

<txp:if_individual_article>
  <txp:if_article_id id="11,14">
    <txp:article form="shop-article" />
  <txp:else />
    <txp:article_custom id="4" form="shop-article" status="sticky" />
  </txp:if_article_id>
<txp:else />
    <txp:article form="shop-article" status="sticky" />
</txp:if_individual_article>

where “4” is the article-id of the boutique article. That should act as my suggestion above, but additionally show the boutique if any of the other boutique product articles are called up individually.

It’s a bit of a workaround: you need to make sure your canonical url is then also the base “/boutique” url and/or better prevent search machines indexing the products. Alternatively – probably better – would be to put a redirect back to the landing “/boutique” page instead of the article_custom tag.

Regarding the “logic” article, you might be thinking about Jeff Soo’s thesis on context,

Ah, right you are!

Destry · 2016-10-09 16:38:19

Again, I forgot to mention that each tool and wire product is an individual article in the boutique section, but I guess you figured that part out now. ;)

It never occurred to me to put both of the paypal response articles in the same tag (id="11,14"). That’s good. I’m still a little puzzled by the double instance of the sticky article in the conditional, but your structure does make the errors go away. Yeah!

However, articles still aren’t showing up on the front side in any section. So while we’ve cleaned up my tag architecture (and I’m grateful for learning that trick, thank you), that doesn’t seem to be what was causing the original problem.

Back to square one.

Destry · 2016-10-09 17:04:21

Bloke wrote #302025:

Any use? Especially take note of etc’s response in which a mis-closed tag now trips up the parser. Previous parser instances were more lax in their parsing of tags.

Wouldn’t a mis-closed tag show up as a tag error? I don’t see anymore errors.
If not, then that could still be the problem… And hard to find.

jakob · 2016-10-09 19:09:17

Destry wrote #302058:

I’m still a little puzzled by the double instance of the sticky article in the conditional, but your structure does make the errors go away. Yeah!

In pseudo-code, it does

Is this an individual article
- -> yes
  - Is it article 11 or 14?
    - -> yes: show the current single live article according to the current url
    - -> no: this must be another boutique product article. As we don’t people to be able to call up this article individually, show them the boutique landing page article. (using article_custom with id="4" status="sticky" to override context). This is where I think a redirect would probably be a better idea…
- -> no (i.e. this is an article list = section landing page)
  - Show boutique landing page article

However, articles still aren’t showing up on the front side in any section.

Hmm. It’s about now that I start checking:

the page source: is it there but just not showing? (-> css or invalid html)
the tag trace in the page source: how far has it got with the page rendering? Is it sidestepping the logic somewhere else?
And if there’s no tag trace at all, then check the server logs (php/apache/mysql) for any hints of relevant errors (e.g. htaccess or some deprecated php function).

Then, once you can start narrowing down the problem, I txp:hide out code in the template to simplify things, or I txp:hide out a whole section, and replace it with a simplified version until it works. Once it’s working again, I start reintroducing the complexity.

Destry · 2016-10-10 00:06:46

By a stroke of bizarre luck, I seem to have stumbled over a symptom of the problem early (and a tedious fix), but not the cause.

For whatever reason, I have to ~~put a blank line in the first line of the body field, save the article — which then makes the content for that article appear again, then I can remove the blank line and~~ save [articles] again ~~and the article’s content remains in~~ [to] view [them] on front side.

I seem to have to do this individually for each article in the entire site, every section. I’ve never seen that before.

Unfortunately I don’t remember when this problem first appeared, but it must have been during one of the 4.6 beta releases.

The only reason I discovered this odd behavior, and so early, is because the body field for the homepage article (where I started poking around first) begins with a div tag. It was indented, of course, but for no reason at all I decided to throw in a blank line, thinking maybe there was a Textile conflict because of a div on first line or something, and low and behold that revealed the article content after saving content. I then tried another article (no html on the line)… Same thing, which meant it had nothing to do with Textile. I then went back and removed a blank line and saved… Content was still there are front side. Yay! /Relief!/

Fortunately there are not hundreds of articles, so it’s not too bad to fix. I just hope they stay put now.

——

Edit: After some more experimentation, I’ve found it doesn’t rely on a blank line in the body field at all. If I just click the Save button for each article again, that’s enough to make the content reappear again. I needed to do this for each article. Note this was still the case _after I uploaded the production database (which works fine as 4.5.7) to local._

Last edited by Destry (2016-10-10 06:13:50)

Textpattern CMS

Textpattern CMS support forum

#1 2016-10-07 17:58:40