It looks like you're new here. If you want to get involved, click one of these buttons!
I have a large number of pages where I serve up the content from a database, and I use the model for data entry typically with many entries (think news items) per page. There are a few things that should logically be page variables with the user having some way to edit them. I don't see this in the documentation, and it looks like if the pages are editable as using Fuel's pages, I lose the ability to use my custom code.
Is there any way to give the user access to editing the handful of things that are logically page variables? For instance, page title? Right now I am setting the variables in the view file, and the user has no access for editing them.
You can create a page in the CMS with a location ending with
/:anyif you want it to handle multiple pages and pass in the last URI segment as a variable. For example
news/:any. Or you can also setup a controller and use
Obviously not connecting.
What I am trying to do is let a user create code blocks and then assign those code blocks to pages that I have otherwise created via opt-in controller style code.
I have about 50 opt-in controllers, and. those use site-variables which I set (I could change those to page variables, but either way, I set them, hard coded in my opt-in php code per the documentation in https://docs.getfuelcms.com/general/opt-in-controllers. The other page shows to to access the page varibles but not how to let a logged-in user edit them.
Let's say I a have a page. The body is generated by a simple module with a view that gets the content from a database table. Right now, I use "fuel_set_var('key', 'somevalue');" in my code. The user cannot edit the content of that key-value pair. Ditto, a user cannot edit the equivalent page variable (which is what I need).
I can do this in pages created with pages in the Admin-- I can create page variables that are editable. I do get page variables. But if I want to have the body be my code, I don't see a way to do that -- what I see in the fuel-generated page is a text box for the page content, not something that I can set to be my generated opt-in page. Is there some way I should be accessing my body from within the pages body page variable? I don't see that in the documentation, or maybe I don't understand the documentation.
When I tried to use the site variables feature in the Fuel Admin, I did not get page variables (I got site variables). I attempted to get there setting the scope, and hoping that that might get me a page variable. But that did not work. I always get a site variable which must be unique.
I might be dense, but I see the documentation you reference describing what I have now. I don't see a way either to use the pages feature to include my model/view content into the body or a way for a user to set page variables outside of that page edit feature.
I am contemplating treating the fuel_pages table like any other table, not letting the USER edit the body, and reading those page variables into my custom pages. But somehow, I think there must be a way for this to be done within Fuel. If it exists in either of the documentation pages you reference, I don't see it.
I'm hoping you can clarify.
I'm not quite sure I'm following so bare with me. It sounds like you may be wanting a page in the CMS in which the "body" variable is essentially a dropdown list of your predefined views you set up? If so, you can modify the layout variables to be whatever input you want (it doesn't need to be a WYSIWYG input):
Also, opt in page variables created in code are not editable by users. For the variables to be editable they need to be fields in the CMS (either a field under a page or a simple module, depending on how the page is constructed).
Lastly, not sure if this will fit your need, but you can have simple modules that automatically generate pages too:
Thank you - You've given me some ideas.
My problem is that I have people who do not know html, css, or php who want to be able to edit nearly everything that they can see. And I do not want them to have an opportunity to break the site.
Well, I'm already full of simple models that do not-so-simple things, but some of what you say in that first paragraph is giving me some ideas.
For those "static" WYSIWYG pages, I already have the page-variables that I want users to be able to edit as fields in the pages table, and they are well behaved page variables.
I'm thinking that maybe I could add a page variable that is at least conceptually a drop-down of my dynamically created views (which are typically blog-like), and keep the body variable as it is. I'd have my layouts load whichever is set, or even both.
That sounds like a good way to manage it.