Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 11/11/2018 in all areas

  1. Hi @MarkE and welcome to PW and the forum ? I think PW is great for building what you described. But I'm "a little" biased as I build everything with PW from simple websites to complex custom CRM and Feedback Tools... Yes. Is it a sports club? Then you can have a look at mistelbach-mustangs.at's calendar or the team site. Sounds good to me. But I'd recommend starting in the backend first (more on that later). You'll get an idea of how everything works and you might be better off doing the frist part also in the backend. That's not a general statement, you'll just be able to do a better decision once you know how the system works and it might save you from building a custom frontend once you know how easy it is to build custom backends ? Not sure about this one. I guess your wording is just a bit different from the PW world. I guess you mean you want to want to modify your data objects, right? So in PW this would mean your objects are pages, and your properties are fields. Classes would be templates, so for example you could have a template (~class) "team", an instance of this class would be the object, in PW this would be a page "Team A", and to modify it you'd simply add/remove/edit such a page. And yes, you can control anything you want here easily. You can set permissions in the backend and you can even set permissions on a field level. If that still is not enough there are several helper modules out there: https://modules.processwire.com/categories/users-access/ And if that still is not enough control, it's really easy to attach hooks or for reusability and better code organization it's also dead simple to create custom modules. That does sound strange again. The PW backend is just an application built on top of the PW API to manage it's own data (crazy and genius). Just have a look at the page tree and find your admin's root page (page id = 2). Most of the pages there use the "admin" template, but not all, for example the permissions have their own "permission" template: Having an "admin" template just makes it possible to assign a ProcessModule to this page. That means visiting this page via its URL calls the selected process module: So, creating your own admin pages is really nothing else than creating a PW page with template "admin", creating a ProcessModule for it and assigning it to that page. Have fun ?
    3 points
  2. I’m fairly new to ProcessWire, so please excuse any dumb questions. As a test (but also for real) I built a simple static site very easily and really liked the way PW worked. Now I’d like to build a more complex site. A brief description of the proposed site first: It will be a site for a local club which has 100-200 members who subscribe (and pay) annually. There are a number of events during the year – mostly free to members, but some which require payment and some which are open to the public. Payments will either be off-system (cash, cheque or bank transfer) and recorded manually on the system by the Treasurer or via GoCardless (which seems to have a well-documented API). Stripe or Paypal may be added later, but not at first. I propose that emails will be drafted on the site (and linked to mailing lists) then sent via MailChimp (which again seems to have a good API). The site will also have static pages relating to the group’s activities. Users fall into two classes: 1. General members who will normally just view the site but will occasionally need access to (a) view their own details (and update certain fields), (b) book on events (if booking is required) or (c) setup/access their GoCardless account via redirect and the API. For these members, I do not want a user/password system, but rather just email them a one-time URL to carry out their requested task. 2. Admin members (with various roles, e.g. membership secretary, treasurer, event organiser) who will have normal user profiles with logon ids and passwords. I built a draft class diagram for the application. Then, after reading quite a few (like a lot!) of tutorials and forum posts, I felt that the best way forward would be to deal with (1) in the “front end” and (2) in the “back end”. In particular, I found https://processwire.com/docs/tutorials/using-custom-page-types-in-processwire/ and https://processwire.com/blog/posts/building-custom-admin-pages-with-process-modules/ to be very informative. There is still a lot I don’t understand, however, as PW is clearly a very powerful and complex (although very logical and well-designed) tool, so I am sure that I will have further questions as I get stuck into the detail. For now, my questions are fairly high-level: 1. Is PW suitable for the proposed application (pointers to any similar developments would be helpful)? 2. Is my proposal re using the front end for general members and the back end for admin members sensible? 3. In particular, is it feasible/sensible to implement a reasonably fine-grained permissions system in the back end for the admin functions that will create/read/update/delete class instances/pages? 4. Am I right in thinking that all admin pages need to use the same admin template? If so, what is the approach for achieving (3)? Any comments ranging from “you must be daft” to “this is how to do it” will be gratefully received!
    2 points
  3. Why not https://processwire.com/api/ref/wire-array/implode/ directly? Edit: … but you're right. Seems like WireArray::each really suffered from feature-creep. Reading the docs sounds like it's really inconsistant in what it does.
    2 points
  4. realfavicongenerater does offer a proper API for integration in other projects.
    2 points
  5. A pet hate of mine is when an editor uses a paragraph of bold text for what ought to be a heading. When I need to tidy up poorly formatted content like this I will quickly change such lines of text into the heading of the appropriate level, but that still results in markup like... <h2><strong>Some heading text</strong></h2> The <strong> has no business being there, but it's a bit of a hassle to remove it because you have to drag a selection around the exact text as opposed to just placing your cursor within the line. That gets tedious if you have a lot content to process. I figured there has to be an easier way so started looking into the ACF (Advanced Content Filter) features of CKEditor. What I wanted is a rule that says "strong tags are disallowed specifically when they are within a heading tag". (I guess there could occasionally be a use case where it would be reasonable to have a strong tag within a heading tag, but it's so rare that I'm not bothered about it). With the typical string format for allowedContent and disallowedContent there is no ability to disallow a specific tag only when it is within another specific tag - a tag is allowed everywhere or not at all. But I found there is an alternative object format for these rules that supports a callback function in the "match" property. So I was able to achieve my goal with the following in /site/modules/InputfieldCKEditor/config.js: CKEDITOR.editorConfig = function(config) { config.disallowedContent = { // Rule for the <strong> element strong: { // Use "match" callback to determine if the element should be disallowed or not match: function(element) { // Heading tag names var headings = ['h1', 'h2', 'h3', 'h4', 'h5', 'h6']; // The parent of the element (if any) var parent = element.parent; if(typeof parent !== 'undefined') { // If there is a parent, return true if its name is in the heading names array return headings.indexOf(parent.name.toLowerCase()) !== -1; } else { // There is no parent so the element is allowed return false; } } } } }; Another tip: if you want to debug your allowedContent or disallowedContent rules to make sure they are being parsed and applied successfully you can log the filter rules to the console. For convenience I used /site/modules/InputfieldCKEditor/config.js again. // Get the CKEditor instance you want to debug var editor = CKEDITOR.instances.Inputfield_body; editor.on('instanceReady', function() { // Log the disallowed content rules console.log(editor.filter.disallowedContent); });
    2 points
  6. Update... The above works okay but it seems that the match callback only fires when CKEditor loads, so to be sure that any disallowed content resulting from the current page edit is removed you have to save the page twice. After a bit more hunting I think I've found a better approach that uses CKEditor's DTD object. It's not quite as straightforward as you'd expect at first because element objects within the DTD object are not fully independent (e.g. CKEDITOR.dtd['h2'] seems to refer to the same object as CKEDITOR.dtd['p']). This SO post helped me find a solution. In /site/modules/InputfieldCKEditor/config.js: // For numbers 1 to 6 for(var i = 1; i <= 6; i++) { // Create the tag name from 'h' plus the number var tag = 'h' + i; // Create clone of DTD heading object so it can be modified individually CKEDITOR.dtd[tag] = Object.assign({}, CKEDITOR['dtd'][tag]); // Disallow strong element from being contained within heading element CKEDITOR.dtd[tag]['strong'] = 0; }
    2 points
  7. Most of what I've been working on this week is related to the new PW website. That's includes primarily continued copy writing and site development (about 50/50), and it's coming along very well, though a lot of work. I'm hoping to have it ready to post publicly for collaboration by the end of the year. I'll have screenshots to share well before that though. The content of the site (particularly documentation section) is so much improved from the current site that I'd like to get it online as soon as possible, even if design details and some features are still being worked on. In addition to continued work in the documentation section, this week I also worked on the sites directory. I'm going to keep working on that today rather than writing a longer blog post, so that's why I'm posting this update here in the forum instead. Next week I'll also have ProcessWire 3.0.119 ready. Though you can grab the current dev branch already to benefit from a couple of features that are already in it. These include two items from the processwire-requests GitHub repository, among some other minor updates. Here's a preview from next week's blog post about a couple of new features in 3.0.119: • Robin S. (@Toutouwai) suggested that collapsed file/image and CKEditor fields automatically open when a file is dragged into them. Toutouwai also wrote the code to make it happen. This addition is super convenient, and it works great. • @BitPoet suggested that our ajax file upload capture and write the uploaded file in ~8 megabyte chunks. This is preferable to loading all the file data into memory and then writing it, enabling it to support larger file uploads that might not have been possible before (depending on server memory). Presumably this also can help to reduce server load. Thanks to BitPoet for writing the code to make it happen. Also on the dev branch this week is a new WireArray::slices() method and support for created/modified page dates in pages export/import functions (I needed this to import the PW sites directory entries). I'll have more details on all of these updates and more, next week.
    1 point
  8. Thx for the hint! This calls for being built into a pw module ?
    1 point
  9. The current version of the module isn't creating any option pages when using the standard "title only" option for Select Options. The parent page is created but no child pages. Settings: Result:
    1 point
  10. Hi Adrian, I think it would be good to provide a dedicated field for setting the parent page title rather than setting it the same as the field title. An example: I'm creating a select field to choose a geographical region. Only one region may be selected, so the field title should be "Region". Each individual page represents a region and together they make up the set of regions, so it makes sense to me that the parent of those pages should be titled "Regions" and not "Region".
    1 point
×
×
  • Create New...