TYPO3:如何计算带有扩展名的每个页面的页面展示次数

发布于 2024-09-29 13:26:21 字数 258 浏览 9 评论 0原文

我需要将 TYPO3 网站上每个页面的页面印象数计入数据库。 所以我认为我需要一个在每个页面印象上调用的扩展,并在特定页面的数据库中增加一个“印象”列。

我是typo3 的新手,也是扩展开发的新手。有没有办法在每个页面上包含 extbase 扩展,以便调用一些 php 脚本?

(更新)
我想添加更多信息: 我不需要一个计算所有 PI 的计数器。计数器需要与页面相关。因此从 Typo3 扩展页表是有意义的。另一个需求是扩展应该使用 extbase 来完成。

I need to count the page impressions of every page on a TYPO3 site into the db.
So I think I need an extension which is called on every page impression and increase a column 'impressions' in the db of the specific page.

I'm new to typo3 and new to extension development as well. Is there a way to include an extbase-extension on every page so some php-script get called?

(Update)
I want to add more information:
I don't need a counter which counts all PIs. The counter needs to be page-related. So it make sense to extend the pages-table from Typo3. Another need is that the extension should be done with extbase.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

黄昏下泛黄的笔记 2024-10-06 13:26:21

我是typo3的新手,也是扩展开发的新手。有没有办法在每个页面上包含 extbase 扩展名,以便调用一些 php 脚本?

配置好插件后,您可以将其包含在 page.1234 <任何页面上的plugin.tx_yourextension_pi11234 决定了您页面上的位置。
该脚本应该是 USER_INT,因此不会被缓存(请注意,这将消耗性能负载,如 @norwebian 先前所述)。

由于您不想输出任何内容,因此请确保控制器也保持为空。

I'm new to typo3 and new to extension development as well. Is there a way to include an extbase-extension on every page so some php-script get called?

Once your plugin is configured you can include it with page.1234 < plugin.tx_yourextension_pi1 on any page. 1234 determines the position on your page.
The script should be USER_INT, so it's not being cached (mind you, this will cost loads of performance as previously stated by @norwebian)

As you don't want to output anything, make sure the controller stays empty as well.

九厘米的零° 2024-10-06 13:26:21

您是否在扩展存储库中进行了快速搜索?尝试搜索“page counter”揭示了四个相关的扩展。

“Sys_stat”是最接近“官方”解决方案的东西,它实际上只是启用一些已经存在的设置。据报道,数据库中的数据过多。

我相信“通用访客计数器”将是我的最爱(如果我真的想要页面计数器),它最近更新并且看起来足够简单。

不过,您确实应该考虑适当的统计扩展。 ics_awstats 和 ke_stats 都已在我的工具集中。

YMMV。请注意,如果您的网站很受欢迎,统计数据收集很快就会失控。另一方面,如果您选择简单的计数器,则包含未缓存的扩展会降低性能。

Did you do a quick search in the extension repository? Trying a search for "page counter" reveals four relevant extensions.

"Sys_stat" is the closest thing to an "official" solution, it is really just enabling a few settings already existent. It has been reported to fill up the database with too much data, though.

"Generic Visitor Counter" would be my favourite, I believe (if I was going for a page counter at all), it is recently updated and seems simple enough.

You should really consider a proper stats extension, though. Both ics_awstats and ke_stats have been in my toolset.

YMMV. Be aware that if your site is popular, stats gathering quickly gets out of hand. On the other hand, if you go for a simple counter, including uncached extensions will cost performance.

诗酒趁年少 2024-10-06 13:26:21

我不确定我是否真正理解你想要什么和需要什么。毕竟,页面印象数与页面浏览量不同。不过,我现在不知道“页面上”的区别。那么我假设您指的是页面浏览量是否正确?

如果是:我会采取以下方法:

一个单独的、自治的扩展,其中包含用于异步调用 API 的 JavaScript 和用于存储页面浏览量/页面展示次数的表。

每个页面全局绑定一个初始化自身的 JavaScript。

  • 一旦 DOM 准备就绪,它就会向 AJAX API 端点发送调用,并将页面的 URL 作为参数。
  • 端点仅采用 URL。
  • 对于每个唯一的 URL,将创建或更新包含计数器的记录。

扩展页面的表格对我来说没有意义。您正在使用一个由新闻概述、新闻详细信息、新闻和博客部分、经销商搜索以及包含产品页面的商店组成的网站做什么?

我会将统计表保持独立。

如果您稍微扩展表格并添加日期和时间 - 不是简单的点击增加 - 您甚至可以识别一周、一个月等最热门的页面。

-

我的方法不会增加/延迟页面加载时间太多,如果有的话,即使对请求量很大的网站也不会产生明显的影响。

有了 AJAX 端点,您就可以决定如何部署它以及要加载多少 CMS 框架。

I am not sure if I really understood what you want and need. After all, page impressions are not the same as page views. I wouldn't know the difference "onpage" right now though. So am I right in assuming that you mean page views?

If yes: I would take the following approach:

A separate, autonomous extension with a JavaScript for asynchronous calling of an API and a table for storing page views / page impressions.

Each page globally binds a JavaScript that initializes itself.

  • Once the DOM is ready, it sends a call to an AJAX API endpoint with the URL of the page as a parameter.
  • The endpoint takes only the URL.
  • For each unique URL, a record including counter is created or updated.

Extending the table for the pages doesn't make sense to me. What are you doing with a website that consists of news overviews, news details, press and blog sections, a dealer search and a store with product pages?

I would keep the statistics table standalone.

If you expand the table a bit and add date and time - no simple increment of hits - you can even identify the hottest pages of the week, the month, etc.

--

My approach won't increase/delay page load time much, if at all, and will have little noticeable impact even on heavily requested websites.

With the AJAX endpoint, it's then up to you how you deploy it and how much of the CMS framework you want to load.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文