bfarber

It may be a situation where extra permissions were requested that are not needed now. Unfortunately, we would need Facebook to chime in as to why you received such a notice. As Matt pointed out, we haven't so it's difficult to comment on it from this end.

You didn't see spam posts - you looked in the database and found them. The very nature of allowing guests to post prior to registration can open up spammers to try to submit content, however unless they actually complete registration those posts are never displayed and will be appropriately pruned. In other words, the topic here is a bit hyperbolic. 😉 There is no need to clean these posts up, the software will do it automatically.

I have nothing to add. I recommend using the default spacing option.

I would recommend responding to Facebook and asking for more details about what the issue is and how to solve it.

max_input_time can be a limiting factor if the user's upload speed is very slow, or (again) it could be a limit set in your server software. I can't give you a blanket answer I'm afraid - there are plenty of causes. If your user is at all technically inclined they may be able to open the developer tools in their browser when performing an upload to capture the actual response from the server. This will probably help identify what is causing an error.

I'll go ahead and open a bug report to get that second point checked into. No need to submit a ticket right now, but please note if we can reproduce it probably won't be until 4.5 that the issue is fixed based on current dev projections.

The -200 error shows up generally when a PHP error we are unable to capture (such as "out of memory" or "max execution time exceeded") has occurred. PHP ends up exiting and printing out the core PHP error, and the uploader (which is a general open source uploader - we didn't write it) shows the "-200" error as a result. @Mr 13 this can happen with large animated gifs when using ImageMagick but not GD simply because ImageMagick supports manipulating animated gifs (i.e. to create a thumbnail) and GD does not. Thus, what is probably happening is that ImageMagick is causing an "out of memory" error (manipulating large images is extremely memory intensive), while GD just skips trying to create a thumbnail altogether because it cannot retain animation. We are happy to investigate if you submit a ticket, but 99% of the time the only real solution is to increase the resources available (remove memory limits, max execution times, etc. - sometimes there are limits in upstream software like Apache or nginx that need to be adjusted as well).

What would you hope to achieve through this change? Google (currently at least) treats sponsored/ugc the same as specifying nofollow from an SEO standpoint.

What makes you say there shouldn't be a range? Some pages we may have to rebuild sidebar blocks because a cache has become out of date, and some pages we may be able to pull from cache. Some page loads we may have to update the session, while some page loads we may not. There are definitely going to be various factors that affect the page load time, and absent evidence of a specific issue, the statements here are a bit broad to act on. Hence why I recommended submitting a ticket.

All but one of those screenshots show a TTFB below 500ms, which is an acceptable range. The software does have to process things after all - we're not working with static HTML files where Apache can simply spit the file contents out to the browser. The 600ms TTFB seems to be an outlier. That said, ALL of these are below 1 second (1000ms), so the Theme.php code would not be relevant. The response would have to be longer than one second for the sleep call you highlighted to have possibly been hit.

I added debug logging to our company forums here, and another employee added it to his personal live site. In both cases, we are not seeing this area of code you reference (the sleep() call in Theme.php) hit unless we actually intentionally clear the datastore (i.e. run the support tool). The sleep() call here is only hit if templates need to be rebuilt, and they are actively being rebuilt by another request - i.e. you have cleared the datastore and two users are hitting the page at the exact same time. The sleep is purely designed to let the second request that comes in wait a second (up to 5 seconds) for the rebuild initiated by the first request to complete. It should effectively never be hit regularly on a site. I would recommend submitting a ticket if you believe this is being hit regularly on your installation. It's possible the code is a red herring and was simply identified by your host during a code sweep looking for the problem, or it's possible you're using some sort of customization that is clearing your caches routinely which is leading to this problem. I can't really say from here right now, just that I am not seeing problems with this sleep call both here and with another site we added logging to.

We have an open report internally to review this feature for an upcoming maintenance release.

I've made a note for us to review this area of code for 4.5.

No, it's a very central template used by every single text input. It would be core > global > forms > text.

From an HTML perspective it's easy, you just add placeholder="Whatever you want" The problem is that custom fields use very very central generic HTML templates, so you can't simply edit a template to make it show the value you want. You could probably do something like {{if $name == 'core_pfield_123'}} placeholder="First Name" {{elseif $name == 'core_pfield_456'}} placeholder="Last Name" {{endif}} Or perhaps create a plugin that has a small javascript mixin which does this, but I don't think I'd bother personally.

The standard wasn't published until after we implemented our own solution, and I'm certain in due course we will switch over to it.

We use a custom lazy loading solution, rather than the new built in lazy loading option Chrome provides. As time goes on and and the behavior is more widely adopted by other user agents, we will explore switching to the native option.

We use FontAwesome for the icons, and even version 5 (which we aren't using yet) doesn't have a TikTok icon yet. We would probably need to wait for Font Awesome to add support first.

Yeah, I mean the reality is Google will just get the info from a different site if you don't supply it. Your strategy isn't going to help your site overall. I, for one, will say that while I browse the snippets Google shows like anyone else, I almost always also click into the site if the information seems relevant. The short snippet in a search result is rarely enough to answer whatever it is I'm searching for.

Thanks for pointing that out, I've raised this internally for discussion.

If you are talking about direct remote video URLs, that functionality will be available in 4.5. Otherwise, if you link to a specific tweet on Twitter, it will automatically embed (including any video in the tweet).

Yes, it's impossible to tell you how big it "should" be. There are several factors: How long you cache guest pages for (you already said 30 seconds). How big your site is - is there a lot to cache? How much guest traffic you get - if you don't allow guests to access your site, that page will stay small by the nature of your traffic patterns. If you don't get much activity in general and aren't using cron, the task that clears the table may not be running enough. You get the idea. Note that you can also store guest cached pages in Redis or in a remote MySQL database, or turn the feature off entirely. That said, it can improve performance quite dramatically for sites with any significant amount of guest traffic, especially during "surges" in traffic.

Actually, looking back - the Blog version prior to 4.0.0 used TEXT column type. It appears that you changed this to MEDIUMTEXT yourself, and the upgrade routine is naturally not aware of this and expects it to still be TEXT at this point (incidentally, we changed the column size to MEDIUMTEXT in a 4.x release later on). To that end, you're going to need to customize your upgrade routine - it's not something we can account for, since the issue is based on a customization you previously implemented.

If you look at that error message, it's trying to change entry to entry_content with a column type of "TEXT". I can see in the older upgrade routines why this is happening and will submit a fix. In the mean time, you would need to edit applications/blog/setup/upg_40000/queries.json to change "17": { "method": "changeColumn", "params": [ "blog_entries", "entry", { "name": "entry_content", "type": "TEXT", to "17": { "method": "changeColumn", "params": [ "blog_entries", "entry", { "name": "entry_content", "type": "MEDIUMTEXT",

No, we didn't. I think you might have paginated from page 1 using AJAX and ended up looking at the canonical tag that was initially loaded, or simply made a mistake. 😛