I am working on an EpiServer project and the team we are working on it with updated the code in the repository, but has not sent us an updated version of the database. As a result I am not able to load any pages, when I try to do so I get 'TypeMismatchException'. I have tried converting the page types via 'Admin -> Content Type -> Convert Page' but this does not work. Doing 'Root -> New Page' also only gives me the option to use corrupt page types.
What I'd like to do is to create a page programmatically as a child of root but when I call
PageReference parent = PageReference.RootPage;
It tells me the 'ProviderName = null' because I have no page context.
So instead of determining the root page based on the page I'm currently on, I'd like to do the opposite, I'd like to reference the site I'm currently on, and given the site I should be able to reference the root page of that site.
Does anyone know if this is possible?
Related
My editors want to know the end page url for publishing in social media.
Is there any way to get the page URL as when it will be published before actually publishing it (scheduled publishing)?
slug_url should give you what you need:
https://docs.wagtail.org/en/latest/topics/writing_templates.html?highlight=slugurl#slugurl-tag
Note that slugurl might provide a relative link, so if it does, then you would have to prepend the domain name to the relative url in order to create the final url for the user. See the test_slugurl_tag() routine in the tests for an example of how to use slugurl in Python code.
Note also that if the location of the page in the page tree is changed or the slug (as defined in the Promote tab) is changed, then the url that you retrieved with slugurl prior to any such change will no longer be valid. However, if you are using Wagtail 2.16+, then this problem can be handled automatically if you use the wagtail.contrib.redirects app.
Here a code snippet that takes in account when the slug changes or the page is moved in the tree (you will need to subclass the Page model somehow and add a new field published_url):
def save_revision(self, user=None, submitted_for_moderation=False, approved_go_live_at=None, changed=True,
log_action=False, previous_revision=None, clean=True):
old_record = Page.objects.get(id=self.id)
if old_record.slug != self.slug:
kwargs = {'update_fields': ['slug']}
Page.save(self, kwargs)
self.published_url = self.get_full_url()
return Page.save_revision(self, user, submitted_for_moderation, approved_go_live_at, changed,
log_action, previous_revision, clean)
Please i need to understand the idea of wagtail root[depth=0] page. Because for me homepages must be on the root level but currently all homepages are on depth=1 level, why and what is the idea to have root level page.
I checked docs etc, but didnt find clear info of this idea.
Also why homepages[depth=1] related to site object and not root[depth=0]?
It's mostly an implementation detail to make Wagtail's internal logic simpler. For example, the Page model has copy and move methods, which take the new parent page as a parameter. Having a fixed, non-editable page at the root level means that there's always a meaningful value we can pass as the parent - if the root node wasn't there, we'd have to implement separate code paths for "move a page to a new parent" versus "move a page to the top level".
However, there's also one place where the root page is directly meaningful to the site admin: it's possible to assign permissions to that page (through the Settings -> Groups area). Since permissions propagate down the page tree, this means that the permission will apply to all pages across all sites. For example, if you want to give a (non-superuser) group the ability to create new homepages, you can do that by giving them 'add' permission on the root page.
I've been using wagtail-modeladmin to create custom lists of certain page types. That gives me the ability to edit those pages. But I'd also like to be able to click through somehow to the "normal" admin explorer version of those pages, and be able to view/add child pages to them.
essentially giving myself a column with the little arrows in on the right, just like in the normal wagtail admin page explorer...
OK I know it's bad form to answer your own question, but I've got this working by using a custom method on the model admin object that reverse wagtails admin urls:
class MySpecialPageModelAdmin(ModelAdmin):
def view_children(self, obj):
url = reverse('wagtailadmin_explore', args=[obj.id])
return format_html(f'View Children')
list_display = ('title', 'live', 'view_children')
but actually, I think I'm not going to end up using this, just replacing this particular modeladmin with a direct link to the right place in the explorer.
I'm working on a CMS and would like to configure cake to automatically find the proper page to use based upon the URL. I don't want to have to manually set this and want it to automatically work if I create new pages (based upon slugs).
Let's say I have the following "page layout":
News
-Local
-World
-article1
Products
-Product1
-details
-photos
etc
So: mysite.com/local/world/article1 would load "Article1". If I added a page under article1 titled "photos", then: mysite.com/local/world/article1/photos would work. Also, mysite.com/products/product1/details would work, etc. Any page I add to the site should be available (it should use a parent/child method). Any tips on making this happen with CakePHP?
I have a custom module in DNN 7 that has a data structure where items belong to categories (called "sections", not DNN taxonomy, just a simple list of section names). The module edit screens work so that on the view control you may click on an edit link on each category, which loads the category edit screen (passing the category id). This works great, and when you save I use Globals.NavigateURL() to return to the view screen. This all works as intended.
On each category edit screen I also have a list of the items within that category, each with an edit link. Clicking the edit link opens the item edit screen, passing the correct item id, and allowing me to edit that item. This all works great, until you save. The save works properly, but when I want to send the user back to the edit screen for the category it doesn't work. When I use:
Response.Redirect(EditUrl("SectionId", sectionid.ToString(), "EditSections"), true);
...nothing happens. It simply doesn't redirect anywhere. This is exactly the same URL I'm using to get to the category edit page in the first place:
EditUrl("SectionId", Eval("SectionId").ToString(), "EditSections")
And then I use a similar URL to get to the item edit page:
EditUrl("ItemId", Eval("ItemId").ToString(), "EditItems")
I don't understand why using the same URL to navigate to the same page I already navigated to would simply not do anything. For now I am sending them all the way back to the view, but it's painful if you need to add several items to the same category to have to navigate back into the category and add another item, only to be sent back to the view.
Anyone see anything like this before?
Have you tried to use the overload of NavigateUrl instead of EditUrl?
Globals.NavigateURL(TabId, "EditSections", "mid", ModuleId.ToString(), "SectionId", Eval("SectionId").ToString())
I haven't seen that myself but I would have to assume that somehow the context is being lost with EditURL and you're not getting sent to the proper location due to that.
I would suggest you try one of two things (or both).
Debug the URL that EditURL is returning and see if you can find the
difference.
Use NavigateURL for all your links and pass in MID=## for your
moduleid as a querystring parameter, to ensure that the proper
values are being passed.
UPDATE: If you're trying to have multiple edit views, and move between them, you might look at using a "loader" instead of having separate module definitions for the edit controls. Basically have a single Edit.ascx file defined, and it loads other ASCX files within it, injecting into a Panel. The View control on this module http://dnnsimplearticle.codeplex.com/ does that, but I haven't tried it with an edit control before.