Recently Browsing 0 members
- No registered users viewing this page.
I am using the "PageTable" Module (also called "ProFields: Page Table") and the built in "Language" Module (also called "Languages Support").
With the help of PageTable I was able to create several content elements which should usually be displayed in German(default language) and English.
However some Content Elements should only be shown in German and NOT in English.
Well sounds easy, right? Not so fast. I really love this CMS, but I have not found a solution for this problem yet.
As you can see in the screenshots attached I tried to uncheck the "active" Checkbox for the english language to completely hide the content element for english users.
However no matter what I do the german text shows on the english page.
If I leave the "content-should-not-be-shown-in-english"(see Screenshot Number 2) blank and save the page, the page will inherit the german page url "content-element-with-simple-text-which-should-only-be-shown-in-german".
My question therefore is:
How can I hide a specific content-element for only one language?
I´m using the latest processwire & module versions.
The code which I use to render the content elements looks like this:
//Info: contentelements is a field of type "ProFields: Page Table" <?php foreach ($page->contentelements as $element): echo($element->render()); endforeach; ?> filename: basic-page.php
I would really appreciate your help since I haven´t found a solution after reading through quite a lot of forum posts.
All the best,
Announcing the current status, planned release, roadmap and preview of Padloper 2.
Finish work on admin/backend. Work on installer and uninstaller (including configurable availability of some features). Work on UI/UX improvements. Start work on documentation with special focus on technical documentation. Continue work on Padloper API and data/model component. Roadmap
Please note that these ARE NOT hard and fast targets. The roadmap may have to be adjusted to accommodate technical and non-technical constraints.
Inbuilt support for (latest) PayPal (full rewrite, no external modules required). Additional work on Padloper API. Invite a limited number of early alpha testers (fully-priced product). Soft and closed release of Padloper 2.
Start work on relaunch of Padloper website. Inbuilt support for Stripe (no external modules required). Future Plans
Support for more Payment Gateways. Support for order, customers, etc imports and exports. Support for AdminThemeReno and AdminThemeDefault. Separate fully-featured frontend shop module. Consider support for multiple currencies. FAQ
1. Have you abandoned this project?
2. When will Padloper 2 be released?
First early alpha release is scheduled for Q1 2021. This target may change depending on circumstances! Access will be by invite only for this first release.
3. What is the pricing model of Padloper 2?
Three licences: Single Site, Developer and Agency licences (12 months’ updates and VIP support).
4. How much will Padloper 2 Cost?
No price has been set yet. It will cost more than Padloper 1.
5. Can we upgrade from Padloper 1?
6. Will existing users of Padloper 1 get a discount for Padloper 2?
No, this will not be possible. Apologies for the earlier announcement. It was unrealistic and unworkable.
7. Can we pay for Padloper 2 in advance?
8. Does Padloper 2 render markup/templates in the frontend?
No. Access to all data you need to build your shop’s frontend is via the Padloper API.
9. Can we keep sending you ‘Are we there yet’ messages?
Here is a video preview of the current state of the backend/admin of Padloper 2. Please note the following:
This is early alpha. There are bugs! It even includes WIP/notes!! FOUC, misaligned things, etc. The video shows the near-raw implementation of Vuetify UI. The UI/UX improvements work is yet to start. What you see here is the development version. Some of the incomplete features may not be available in the early releases. Most of the features you see will be optional to install.
I opened a new wishlist topic on the PW forum for this and in the meantime I ask to the community looking for a reasonable solution.
Using the PageTable field, is there a way to un-restrict the creation of pages under a given parent template page (or as page children if no parent for items is selected)? That is, is there a way to allow the selection of the parent page dynamically / on the fly during page creation via the PageTable field?
I'm using the PW PageTable field extensively and I think an improvement to it could be made regarding the ability to choose the page parent where the page created via PageTable will reside.
Say you have a PageTable field set like this:
Edit Field: page_table_field > Details >
Select one or more templates for items
Select a parent for items
Actually, you can only create pages under the parent_template page (or as page child if no parent for items is selected).
BTW I am looking for reasons about this limitation.
What about allowing to choose on the fly where the pages created via PageTable will reside? that is, having the possibility to choose dynamically under which parent page to create the pages?
Actually, one could overcome to this by creating multiple appropriately set PageTable fields, one PageTable field per PageTable parent for items, but this is unsustainable (?) when you want to create a lot using PageTable…
By allowing to choose dynamically / on the fly the parent page during page creation via the PageTable field would open up a wider usage of PageTable.
What do you think about?
@ryan @Robin S
So I ran into a very strange issue today. I have a template with a pagetable and I went to add an item to it, when I went to select an image (for an image field) the page instantly threw up an error
"ProcessPageSearchLive: No search specified"
The page's content also switched to the image attached. This all worked perfectly last week (local mamp box). Has anyone experienced this before, and how did you solve it?