面向插件的网站(如 WordPress)的文件夹结构
我只是想了解一个网站的文件和文件夹结构,该网站是一个面向插件的网站,如 wordpress 或 joomla。 我的要求是开发一个网站,并希望通过插件或类似功能添加更多功能。
我需要的只是添加附加信息或功能会话,例如 wordpress 我们可以使用多合一SEO包它将绕过标题和其他一些信息。 或一些其他功能(例如相关文章)显示在特定文章正文的底部。 我正在谈论 wordpress 的结构。
有人有想法吗请与我分享。 希望大家也能理解我的问题。 谢谢。
i just want to know about the files and folder structure for a site which is a plugin oriented like wordpress or joomla.
my requirement is to develop a site and want to add more functions via plugin or something like features.
what i need is to just add and additional information or functional sessions like in wordpress
we can use All in one SEO packages it will bypass the title and some other information.
or some other features like Related articles are shown at the bottom of a particular article body.
aam talking about a structure of wordpress.
does any one have an Idea please share with me.
hope every one understood my qustion as well.
thank you.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我认为有很多可能的解决方案。
这可能取决于:
您可以选择:
www.domain.xyz/plugins/some_module/
但是如果插件怎么办不是插件但后来成为系统的默认部分?
然后,按照它们的样子来称呼它们会更合乎逻辑:
www.domain.xyz/some_module/
但是,您可能会遇到插件名称(例如现有系统文件夹)的问题。 因此,您需要一些“保留”的文件夹名称列表来防止这种情况发生。
您也可以选择:
some_module.domain.xyz/
但这需要您的网络管理员或网络服务器支持一个网站的多个别名,另一方面,这种架构将带来可扩展性,因为您可以移动稍后将模块移植到其他网络主机。 但它的开发工作也更加昂贵+很难使其成为“用户/开发人员控制”,因为这种情况可能会增长。
您也可以看看 Facebook 如何处理应用程序。 这也是一个插件接口。 缓慢,但已落实。
I think there are many possible solutions.
It might depend on:
You could go for:
www.domain.xyz/plugins/some_module/
But what if the plugins arent plugins but becomes default part of the system afterwards?
Then it would be more logical to call them what they are like:
www.domain.xyz/some_module/
But then you might get into problems with plugins name like exisiting system folders. Therefore you would need some "reserved" list of foldernames to prevent that.
You could also go for:
some_module.domain.xyz/
But that would requiere your webadmin or webserver to support multiple aliases for one website on the other hand, this arhictecture would bring scalability, because you could move the modules to other webhosts later on. But its also more expensive work in the development + its hard to make it "user/developer controlled" as this could grow.
You could have a look at how FaceBook is handling Applications too. Thats a plugin interface too. Slow, but implemented.