Jump to content

design-a-point

Members
  • Posts

    6
  • Joined

  • Last visited

Everything posted by design-a-point

  1. Hi, could this be related to permissions? We currently encounter problems with frontend editing of repeater fields, too: in our case it's simply not possible to frontend-edit repeater fields for users with a specific role, although these users are able to edit the respective repeater fields in the regular backend page editor. Superusers are able to frontend-edit repeater fields as expected. @DarsVaeda this is an example of how we included frontend-editing which works (apart from the problem described above): <?php /** @var RepeaterPageArray $attributes */ foreach ($attributes as $attribute): ?> <div class="attribute"> <?php $image = $attribute->get('image'); ?> <div class="attribute__image" edit="<?php echo $attribute->id; ?>.image"> <img src="<?php echo $image->url; ?>" alt="<?php echo $image->description; ?>"> </div> <div class="attribute__body"> <?php echo $attribute->edit('body'); ?> </div> </div> <?php endforeach; ?> Cheers, Alex
  2. Hi Mike, thanks for your answer! I once tried to use PW's build in class loader but wasn't sure where to call addNamespace... What do you mean by If the main module file resides directly in the module's folder, it should be like this? <?php namespace ACME; $this->classLoader->addNamespace('ACME', __DIR__); use ProcessWire\Process; /** * ProcessNamespaceTest/ProcessNamespaceTest.module */ class ProcessNamespaceTest extends Process { ... This is not working... I'm also not sure what $this refers to in this context
  3. Thanks for that hint, but the warning still persists... It's also worth to mention that everything works fine if the namespace is initially set to ProcessWire. If the namespace is changed back to ACME later, the module still works without problems. It's only the page editor for the admin page where the warning occurs.
  4. Hi there, I just tried to implement a process module for a PW3 (3.0.32 devns) installation with a custom namespace and found that there's an issue with assigning the new Process to the newly created admin page. ( ! ) Warning: class_parents(): Class ProcessWire\ProcessNamespaceTest does not exist and could not be loaded in /var/www/public/pw3/wire/core/Functions.php on line 721 It looks like the custom namespace is ignored... The demo module looks like this: <?php namespace ACME; use ProcessWire\Process; /** * ProcessNamespaceTest/ProcessNamespaceTest.module */ class ProcessNamespaceTest extends Process { ... I also added the appropriate settings for autoloading in the composer.json file and did a composer dump-autoload: "autoload": { "files": [ "wire/core/ProcessWire.php" ], "psr-4": { "ACME\\": [ "site/modules/ProcessNamespaceTest" ] } } Does anyone have an idea if I missed something? Thanks Alex
  5. Hi, a while ago, we redesigned the corporate identity for the event- and catering agency p.events Event & Catering oHG based in Germany. Along with the new corporate design we also developed a new website based on ProcessWire 2.7: http://www.p-events.de The website's current focus is the presentation of p.event's services and therefore makes use of many images. It is planned to extend the website with a blog and a more sophisticated inquiry form in the future. The website is fully responsive (including images with srcset), uses free-flow image sliders and some CSS3 features like animations. We're looking forward to your feedback Cheers Alex
  6. Hi, I once had this issue too, where the styles did not appear at all. For me it helped to clear the browser cache and clearing the session. Once I logged in again and did a complete page reload, it worked again... Currently I'm experiencing another issue related to custom CKEditor styles: I have two textarea fields with CKEditor as inputfield type and both have the JS styleset option set (to the same value). When editing a page which uses this template, the custom styleset only works for the first CKEditor instance. The following ones only show the default style options. Changing the order of fields in the template won't work, so it's really related to the order in which the fields are added in the template. It's without exception only the first field where it works properly... Can anyone reproduce this issue? I'm using PW 3.0.21. Edit: Hm... just upgraded to PW 3.0.23 and now everything works properly Cheers Alex
×
×
  • Create New...