Hello, I was just exploring Frappe, when I found there is something called WebPage and Page.
Can anyone help me know what is the difference between WebPage and Page.
Hi @Abhiraj_Tulsyan:
Page is visible inside desk (mean once user is logged in).
Webpage is visible without login.
Hope this helps.
Hello @avc
But can’t we customize webpage to be visible also once user is logged in and once user is not logged in as both?
Then what is the difference between Pages and Portal Pages?
Portal pages are the ones which we add in www directory. Pages are the things which gets added in pages directory.
But then what is the difference between Portal Pages and Pages then?
Pages are the Desk, they are for the enterprises staff and these users need to authenticate.
Web pages aka Portal pages generally are for clients or other types of visitors.
Okay so you mean to say, WebPages and PortalPages are both same?
Well, this is AFAIK and generally speaking. If you look closer, there are different kinds of objects and their locations, you can customize things, including permissions, so the differences might blur.
In the doc, for instance, you find Pages, Web Pages, and Web View Pages.
The terminology has several levels or POV, and also a project historical aspect to it, as well as technical, of course.
I really can’t find in the Frappe Docs anywhere about Pages and what are they basically. Only found Pages API docs. Nothing in details what exactly Pages are.
And to be honest, after reading Frappe Docs from past 4 days, there are many important things which are not covered in detail or clearly and many small/valuable things are not even mentioned
Yes. I was reading docs, forum and code past 2 years, and still discovering new things everyday.
It’s great
We need to keep Docs up to date.
In this regard, Frappe is too behind maintaining docs (For eg, check Laravel docs once, they literally cover everything what is possible from the documentation)
There is a price of Freedom well worth paying, which is learning to live responsibly, truthfully, generously implicated in all sorts of communities, without masters, central authorities and the like. That’s how anyone really grows up, and then grows. Power generally breeds corruption and abuse, exceptions might exist, that would be extremely exceptionally humble and virtuous people, but these normally don’t want power anyway, precisely because they are virtuous, e.g. loving, caring, integrating persons, not bullies or hopelessly raging / raking people).
So that’s very, very different from asking “what do I need to do” and then being handed some (real, oral or virtual) paper of duties.
Exploring oneself what’s best to do, guided by one’s own conscience, is what really enables creativity, flexibility, adaptability e.g. integration. And love is what drives it, provides energy, and makes it coherent in the community, because love is what makes people care.
Learning how to find one’s position, where to contribute usefully, etc., that’s kind of a challenge and may take a bit more time and experimentation than simply being handed a shovel, an order and starting to dig.
The interactions of free, growing, loving people are so much more interesting, productive and rewarding, with happiness of creation, useful exchanges and necessary direction corrections and other kinds of success.
If you see the videos (training and conferences recent and older ones), listen closely to the personal stories which shine here and there in the technical talks, and understand how frappe came about, everything becomes clear and also very logical from a human point of view at the people involved: Some people started something on a base of dedication, joy and quality, and it grew, others become interested, joined and learned to build together, and that’s how it become what it is today. And as you rightly said, the growing “We” is what makes it stick.
I really get your point. To explore only we need clear, better,detailed documentation. Nothing more I asked
True.
The thing is, a highly qualified dev who knows the project’s in’s and out’s has a lot to do already to build and also tackle the stream of feature requests, bug reports, pull requests and so on of the product handed out freely.
So what do neo-devs, who also are users, would want them to do?
That’s a very non-trivial question, and there is only so much one person can do.
Write documentation instead?
Or teach others, who also need to learn a very lot – but from what?
Without power and pushing, these chicken-and-egg conundrums play out naturally, and we know that it helps quality more than organizing things top-down-wise.
So it happens like “some of this, much of that, some of even other stuff” according to talents, situation, events, etc.
Maybe funding could help, but transfering knowledge of sophisticated machinery while continuing to build it, so that it changes agilely often, looks like something not exactly straightforward to solve.
So, to a certain degree, everyone is partly on one’s own digging into it with dedication and shovels of “grep”, “find”, “reading, testing, asking, retesting, heureka” loops. Growth experienced.
Yup, I never ever said that the devs should focus on documentation. My only concern was that documentation is poor. I by no means said it in wrong intention but in a way if we can come up with something which can help in better documentation.
I agree with you.
Please don’t take it as a personal injunction or so.
It’s meant as some hints for any people reading in the forum, not you in particular.
I remember how I grew up, and many things I didn’t learn from anybody. In hindsight, it’s painful not to have learned things just because nobody told you, and many things one even has no idea can be asked. On the other hand, I also remember certain things which totally stuck, for many decades, from random strangers talking some tiny, tiny bit of wisdom. We all need to give some wisdom, or give “back” (to anybody), even if clumsily at times (please bear with me), for this world to become good, healthy, free, productive, caring and loving – in short: happy.
I guess sometimes I come across as somewhat preachy. Improving that is a task, too, for me. I may be reminding / preaching to myself at times, but anyway hoping that it’s useful for some others as well, at some time. My intention is never to divide, but to integrate, bring people together, build bridges, encourage personal growth.
Since personal goodness is the base of freedom generally, as well as in free software particularly, fundamental virtues like freedom, responsibility, love, etc., must be taught more, everywhere, and not only mere words – but still words too (!) --, but authentically, which is a challenge in itself for anybody who wants to grow.
Read the frappe blog, there is a lot to learn about this inner dimension of the project, said/expressed somewhat differently, maybe more discreetly so, and maybe not even intentionally, but I’m very happy to have found such a project, such a group of people with an obvious drive, authenticity, and evident success going forward. It’s inspiring!
Why would anybody not want to become part of a good project, shared freely, with everybody?
So I consider that there is a kind of inner living jewel of the project which is worth to be understood, taught, and propagated.
As I once exclaimed to Rushab: “In fact, it’s a people growing company!”
Due to the freedom and caring: that’s how people grow.
Wishing happy progress to all of us in our endeavors!
Best!
You’re not alone in feeling this way. I asked about Pages a year ago, but never got a proper explanation.
The official documentation is poor and incomplete. The naming conventions are confusing.
I will share what I understand (or at least, what I -think- I understand)
1. Portal Pages
- Portal Pages
- These are static, server-rendered HTML web pages (not Single Page Applications)
- You write all the HTML, CSS, and JS manually.
- There is a clever “Context” feature that allows for easy integration of Python code files.
- The documentation is wrong: not all Frappe Apps have a
'www'
directory by default.
Why Use them?
- You need a static web page that plays nicely with Search Engine Optimization (SEO).
2. “Web Pages”
- These are a DocType. You can find them here: http://127.0.0.1:8000/app/web-page
- As far as I can tell, these are -almost- identical to Portal Pages (?)
- The difference is that to create a Portal Page, you must edit source code files on your Linux device. However, “Web Pages” can be configured via the Frappe web UI.
- I don’t see documentation for these anymore. Maybe deprecated?
Why Use them?
- Because you don’t have access to Linux, but you still need to create a static web page. Frappe Cloud users, perhaps.
3. Portal Settings
- A DocType found in the “Website” module (http://127.0.0.1:8000/app/portal-settings)
- “Portal Settings” defines the contents of a sidebar located at: http://127.0.0.1:8000/me
- Note that “Portal Settings” are completely unrelated to “Portals” or “Portal Pages”
- Strangely, this data is stored in a SQL table with a different name, versus the DocType name:
SELECT * FROM `tabPortal Menu Item` ORDER BY idx;
Why Use them?
- Because you need to modify the contents of that particular sidebar.
4. Web Forms
- Used to create web pages that interact with DocType-based Documents, but without using the standard DocType web page UI.
- Access: Both authenticated and public (non-authenticated) users.
- The documentation does not completely explain how routing works, and I don’t understand it either.
Why use them?
- Because you need web pages for non-authenticated users. For example, collect information from anonymous visitors.
- Because you don’t have access/permission to modify the actual Frappe code hosted on the Linux device. For example, Frappe Cloud subscribers, or non-developer employees at on-premise installations.
- Because the standard DocType UI isn’t friendly enough for your requirements.
- Because creating “Pages” from scratch is painful (see below)
5. Page
Specifically, I’m referring to these Pages documented here.
- Not these ones.
- Not these ones either.
The “Pages” I’m referring to are when you need to perform Frontend Development at a very low level. Not quite entirely building from scratch, like building a brand-new React or Vue app. But close to this.
“Pages” give you total control and freedom to create whatever web page(s) you desire. You can have whatever design or layouts you want. Any styling, any behavior, any use-case. You can choose to interact with out-of-the-box Frappe framework code and DocTypes. Or ignore them completely, and do your own thing.
Use Cases:
- Build your own Point Of Sale, like POS Awesome.
- The standard DocType UI doesn’t meet your requirements. You need a web page for working with DocType Documents, but with your own special Data Grid or page design.
The catch? Working with “Pages” is low-level Frontend Development. You’re responsible for all the HTML, CSS, JavaScript, data interaction via APIs, etc. The official documentation barely explains Pages. So, if you want to add data grids, drop-down selections, dialogs, buttons, wizards, animation, spinners, forms? That’s all possible…
…but you must teach yourself how to do this. It is not easy (perhaps if you’re already an experienced Frontend dev, it might be). You must understand JQuery, “wrappers”, a bunch of undocumented Frappe classes and widgets, and how it all integrates together.
There are a few examples of Pages in the out-of-the-box Frappe and ERPNext code. (here’s a link to the built-in POS “Page”). However, there is no inline documentation. So it’s difficult for many people to read and understand.
Hopefully the above helps.
X. Web View Pages
Here is doc for these “Web View Pages” which I mentioned above:
https://frappeframework.com/docs/user/en/tutorial/portal-pages
It’s almost the same link as for “Portal Pages” (added “tutorial” in the URL), but I’m not sure if it’s the same technicalities but only with another name (kind if naming by tutorial, so to speak), anyway, the description doesn’t match what you say under “1. Portal Pages”.
It also contains some additional information about routing, but without spelling out where exactly the described elements need to reside in the folder hierarchy. Because routing also can mean “fall-back”, “default location”, and whatnot. Which had me have some respectful disagreements with an instructor, who denied it working although at my end it worked, but well, this incident is not yet fully elucidated.
Regarding the “naming conventions”, maybe calling them “naming dispersions” would be more appropriate, but who even knows? “convenir” means “coming together”, so here it’s like “coming together and agreeing to denominate things in a common way in order to understand each other”. But if something evolves, acquiring mutations via agiloactivity, gets additional legs and arms, becoming evolved by the developers-creators into different beings, differentiates into different forms, can we call the envolving entity even a “thing” or an “it”? Isn’t it linked to it’s creator(s) by the very fact of living in the ecosystem of creation-creatures interacting in many different ways?
So here I’m again musing amused, philosophying about what we actually talk about when we talk about this creation, having some fun, exercising my brain, feeling somehow going forward, maybe just meandering, with my beautiful, sweet and helpful fellows and co-discoverers of the miracle of this creation of us.
Maybe any documentation many of us so long for is just another intermediate step between the still-somewhat-hapless onlooker and The Source, created by some intercessing individual trying to help until we regard, amazed and with awe, directly, with our own eyes, at The Source, becoming enlightened in our path to The Knowledge about The Thing which continues to amaze and fascinate many of us while slowly evolving under the very Gaze of Us being vivified by It’s Emanations of Embracing Changing Stability.
Hello @brian_pond
Regarding Portal Settings, I can’t find even an option from the Desk to add anything on it.
Can it be done only via hooks ? (portal_menu_items)
And my question was regarding this specific Pages which you mentioned in the 5th point.
How can we include python file for the Pages (5th Option) which you told and how to include some common CSS for it which can be used across all Pages?
Any help on it?
This is a well-crafted explanation. I wish Frappe’s documentation was as clear as yours. Thank you so much for putting the time into writing this.
I don’t know where it fits and if it’s replacing any, but I would add to the list: the new Frappe UI
Yet another option to consider before deciding on your path