Jump to content

theoretic

Members
  • Posts

    115
  • Joined

  • Last visited

Recent Profile Visitors

3,629 profile views

theoretic's Achievements

Sr. Member

Sr. Member (5/6)

57

Reputation

  1. Hi friends! And thanks for Processwire ) It appears I've found an interesting issue concerning repeaters. I have a repeater called details holding a filled called colors which is a page reference. The code for retrieving pages for colors field is stored in a php hook. It's important that this hook retrieves the pages which are actually repeater items stored inside some other pages (let's call them "holder pages"). This works, but there's a problem whith the colors field value labels. I use the following format: {parent.title} {title} I supposed that {parent.title} should be retrieved the page holding the colors repeater items. Wrong guess! This {parent.title} is actually retrieved from the dedicated repeater page title inside the "admin" entry in the pages tree. Let's take a look at what I'm talking about: Could be acceptable... but there's something strange with the titles of repeater pages (skytex, skytex-1 etc). It appears that: Their TITLES are copies of the NAMES of the corresponding "holder pages"; When a "holder page" title or name is changed, there's NO CHANGE is the title of the corresponding repeater page. I tried to rename some of repeater pages manually, giving them the same titles as "holder pages" have. It works but it requires some time and effort. And, in plus, I don't see the logic behind. Why should repeater pages have the titles different from the correspondent "holder pages"? Why there's no change in that titles if the titles of the "holder pages" change? Not a bug report, rather suggestion. I understand that this is a rare case... but if this could be made easier, why not? 😉
  2. Many thanks @bernhard ! Setting "theme name" to "original" in AdminThemeUikit removed the problem. It's always a pleasure to be a part of such a friendly community!
  3. Thank You for this brilliant admin theme! Unfortunately, it appears that the latest Processwire 3.0.248 creates some conflicts with AdminThemeBoss. This theme gets a somewhat broken look with grey backgrounds, broken switches etc. Guess it's because of UIKit updates included into 3.0.248 . If there's still someone who maintains the AdminThemeBoss, please pay attention to this. I think AdminTemeBoss is much better than default UIKit theme, and it's worth being maintained properly.
  4. Hi friends! And thanks for Processwire! I got a very specific issue while working on a Processwire-based project. I have an "images" datafield there. This is a multiple images field, and during the local development it works as intended. The problem arises in staging / production environment. If I'm trying to upload several images at once, only the info about the last of them is stored in the field_images DB table. It's still possible to upload images one by one, it works fine, but uploading multiple files at once could be more convenient. Some details: Development and production environments are different. Windows 11/php 8.4.4 for dev, Ubuntu/php 8.4.3 for production. The list of php extensions is also slightly different. But I don't think this may cause the problem. Multiple images upload does not fail. There's no error during upload, the files successfully "land" in their dedicated directories. But the images_field stores only the info about the last upload in the bunch. Processwire version for both dev and prod is 3.0.247 . I also tried some older versions but had the same issue with multiupload. There's no such issue with my "files" field. I can upload several files at once, and all of them will be mentioned in my field_files table. I have at least on hook firing after images upload, but disabling it does not change the situation. Will be grateful for any advice how to cure this disease )
  5. Hi friends! And thanks for Processwire 😉 I have a specific question about PW admin. There's a typical situation when content editors need access to the public page tree only. Ideally, such users should not have the top PW admin menu (Pages, Setup etc.) at all, same for the Admin branch in page tree. Developer users should have everything concerning development (Setup, Modules, maybe Access...) but the public page tree can be limited/restricted for them. It's pretty like how the Admin Restrict Branch module works. But different. Admin Restrict Branch only allows to select a single branch which will be available for certain users. And I'm not sure the ARB will affect the top menu. Is there an existing solution for my request? Or maybe it's time to think about extending the ARB functionality? Many thanks for any possible advice.
  6. Thanks for your interest friends! After some attempts I decided to this the hard way. Here's my working code: $wire->addHookAfter("Pages::cloned", function($event) { $clonePage = $event->arguments(1); $clonePage->of(false); $languages = \ProcessWire\wire('languages'); $emptyLanguageValues = []; foreach($languages as $language) $emptyLanguageValues[$language->name] = ''; foreach( $clonePage->fields as $field ){ switch(true){ case $field->type instanceof \ProcessWire\FieldtypePageTitleLanguage: case $field->type instanceof \ProcessWire\FieldtypeTextLanguage: case $field->type instanceof \ProcessWire\FieldtypeTextareaLanguage: $clonePage->{$field->name}->setLanguageValues($emptyLanguageValues); break; case $field->type instanceof \ProcessWire\FieldtypeInteger: case $field->type instanceof \ProcessWire\FieldtypeFloat: $clonePage->{$field->name} = NULL; break; case $field->type instanceof \ProcessWire\FieldtypeFile: case $field->type instanceof \ProcessWire\FieldtypeImage: $clonePage->$field->deleteAll(); break; case $field->type instanceof \ProcessWire\FieldtypePage: $clonePage->{$field->name}->removeAll(); break; } } $clonePage->save(); $clonePage->of(true); }); This example covers the most used types of data fields. It was enough for me, and it can be extended to include more data fields. By the way, I suppose that it could be a good idea to have a possibility to turn data copy on/off while cloning. But it's in PW core so I don't dare to change this.
  7. Hi friends! And thanks for ProcessWire! Content managers I work with like to create new pages by cloning the old ones. No bad in general, but they frequently forget to check and clean up all the content they copy, especially the multilanguage fields. So I decided to make a hook which should wipe all data fields of a recently created clone immediately after it has been created. Hooking such event is a piece of cake (thanks Processwire!) but cleaning all data fields appears to be a tricky business. Of course I've read this topic but it appears to be irrelevant in my case. My hook is basically like this: $wire->addHookAfter("Pages::cloned", function($event) { $clonePage = $event->arguments(1); $clonePage->of(false); //$clonePage->fields = $clonePage->fields->makeNew(); //fails // ...some more tricks including iterating through all data fields... $clonePage->of(true); $clonePage->save(); } Will be grateful for any possible advice )
  8. Thank You @ryan! Maybe I was slightly wrong. Of course PW is not about "returning html by default". It's a site profile thing, not a core thing. Making an API-dedicated site profile is a perfect idea. Or even an "API + headless CMS" profile. I have seen some API-dedicated PW modules, but, considering the PW architecture, it could be better to have API functionality at site profile level.
  9. I took a look at StaticWire. It's truely a basic SSG, but IMO it's rather a local tool not intended for use in hosting environment. It's okay if You have some hundreds of pages, but what if there's 1000+ of them?.. Generating a lot of static files at once can take too much memory and time, so personally I opted for a lazy static pages generation. Here's my module doing exactly this: https://github.com/theoretic/StaticPages It's open source, and it's free.
  10. Hi friends! And thanks for ProcessWire! Maybe I'm a bit late to the party, but I'd also like to bring some ideas here. Processwire is a great CMS having many brilliant ideas inside. But there's always some space for further improvements. JAMStack paradigm It's about static html pages which have some javascript-driven parts interacting with some APIs and changing their look and feel depending on what users do and which data API provides. Sometimes there's just a single static html page which behaves as a multipage web application, sometimes there are just small dynamic chunks. This approach has many advantages: There's no need to generate pages each time they are requested from server. They can be generated just once. Returning static pages drastically reduces the server loading. Static pages are safe by nature. There's nothing to hack there. And even if someone hacks into the server, there will be only some static html files there. APIs return pure data, no html at all. The most typical API data format is JSON which is pretty compact and human readable already, and there are others (bson etc.) which are even more compact. Processwire vs JAMStack The current ProcessWire is pretty far from JAMStack paradigm: By default, PW is about generating pages on each server request. And, being fair, lots of such pages could be static (generated only once). If someone will take a closer look to how the actual PW admin works, he/she will find that there are ajax-driven things there. But in these cases PW generally returns the chunks of html markup, not pure data. There's no native PW tools providing an easy way to build an API over PW. There are some 3rd part modules, and it's not a rocket science to build a PW-based API from scratch, but no native support out of the box. Processwire as "headless CMS" Headless CMS is a CMS which can only return data, not html. This approach is an important part of JAMStack approach, and there's plenty of such CMSs on the market. PW can be a perfect headless CMS, but it's not by default. You need to build an API on the top of PW to make it "headless". I did this in some of my projects, and I'm quite happy with the result. But, come on, give me a reason why this functionality doesn't deserve to be in the PW core? ) Processwire as "static site generator" (SSG) SSGs are another important part of JAMStack world. They are tools allowing You to make static html files based on the data and the templates You have. Contrary to headless CMSs, SSGs are generally the tools used locally, and the result (static pages) is later uploaded to server. It's quite interesting that PW can be a server-based SSG! I also did this, and I was quite satisfied again. But AFAIK there's no core-level or even 3rd party tools to do this using PW. Bringing the pieces together PW can make a big step from the ol' good paradigm of server-side page rendering to the modern JAMStack. Two things are missing: Native tools for building an API on top of PW. Again, it's doable, but it's not native. A PW-compatible (maybe even PW-based) SSG which won't be a headache. Both things are not rocket science, and they potentially could bring much more attention to PW, make it interesting for younger devels. I had a lot of talk like "ahhh You're that guy from 90ties, still writing php code and making server-rendered pages? You're the past already, man!". Hope this will worth a good discussion ?
  11. Great answer @BitPoet, thanks! Personally I also avoid pasting from Word because the result is, umm, not very well predictable. But my clients ask for that time up to time, so I just wanted to be sure I'm not idiot, and all that copypaste problems are not my problems only.
  12. Hi friends! And thanks for Processwire! Maybe I'm asking a noob question but I couldn't find any clear answer here. Is it possible to paste content from a doc / docx / odt file to a wysiwyg textarea field and to have all images automatically saved to a dedicated image field? Did some experiments, it appears that this may work somehow on MacOS with docx files. But it's definintely not working on Windows, any wysiwyg, any browser. Guess I'm not the only one having this question. Any advice is welcome )
  13. Hi @bartelsmedia! I wrote to You already. I think I have specific skills which can be useful for Your project )
  14. Hi friends! Many thanks for this brilliant module! It appears I've found a heavy issue concerning php 8.3.7 . In brief: Fluency crashes, giving multiple errors of this kind: Uncaught Error: Undefined constant "Fluency\Engines\DeepL\CURLOPT_CONNECTTIMEOUT" in site/modules/Fluency/app/Engines/DeepL/DeepLEngine.php:220 Digging inside reveals the following code sample: $requestConfig = [ CURLOPT_CONNECTTIMEOUT => 5, ... CURLOPT_CONNECTTIMEOUT looks here like a constant, however it's not. PHP 8.3.4 can however handle this kind of arrays, and Fluency works like a charm. But it's not the case for PHP 8.3.7 . I think it's worth taking this into consideration during further development. I've also created an issue on the Github module page. Hope this will help to make this module even better ?
  15. I've found the solution. Hope this will be helpful to someone ) //options for AsmSelect should be (int)key=>value pairs $options = [ 1=>'A value', 15=>'Another value', 200=>'And even more', ]; //default values should be array of keys, not values $defaultValues = [ 15, 200, ]; //options can also be an array of (int)keys $otherOptions = [ 25, 35, 45 ]; ... $config = [ [ 'name' => 'myField', 'type' => 'AsmSelect', 'label' => $this->_('My field'), 'options' => $options, 'value' => $defaultValues, ], ... ];
×
×
  • Create New...