Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

14 Good

About rash

  • Rank
    Jr. Member

Profile Information

  • Location
    Stuttgart, Germany

Recent Profile Visitors

705 profile views
  1. Thanks a lot, arjen and Robin S. At least my ignorance of the notes in the settings tabs is undoubtedly a bit embarrasing. But good to understand it for now and the future.
  2. Hi guys, I’m writing on a brief editor’s manual what reminds me of a topic I repeatedly stumble upon: What are the exact differences between unpublished, hidden and locked pages? Just to make it clear: There is no problem with checking or setting the status and using the result for whatever. The only thing I don’t really understand is the editor’s view: What is happening with the states beside their usage in my templates? Surprisingly, the otherwise excellent PW docs don’t reveal too much about.
  3. @Mike Rockett Fine, thank you. Just a question for future generations: As I presume that there are (or will be) several different images field types, wouldn’t it be better to keep the check more generic? The way I’ve suggested is working for me, but has the big drawback that every single field type must be explicitely listed – and you might never catch all of them. So is there a syntax for (in plain words) find('type=fields that are somehow managing images')?
  4. @Mike Rockett Thanks for your fast reply. It looks as if we’re getting closer: my images are of fieldtype CroppableImage3, resulting from the popular module with the same name. Do you think I could just change the field type where the check happens? Or extend the range of possible field types? I’m no big fan of module hacks, but in this case I could live with it. Would you mind to reveal the exact check location? Update: I’ve got the job done now – much easier than expected. Just in case somebody faces the same problem: in /site/modules/MarkupSitemap/MarkupSitemapConfig.php in line 90 I changed if ($imageFields = $this->fields->find('type=FieldtypeImage') and $imageFields->count) { to if ($imageFields = $this->fields->find('type=FieldtypeImage|FieldtypeCroppableImage3') and $imageFields->count) { to extend the range of considered field types. The option select appeared and everything works perfectly now. Another thanks for your help.
  5. @Mike Rockett This is the way I would have assumed to go, unfortunately I can't find an option like the one you describe. On the module’s config page there are the following sections: Module information Templates with sitemap options Templates without sitemap options ISO code for default languages Stylesheet Support Development Deinstall Either I’m suffering from vision defects, or the mentioned option is missing. (Or carefully hidden.)
  6. @Mike Rockett It seems as if I'm unable to include images in the sitemap. Besides that, the module is working just fine. I can find the option to exclude images (page-based) but neither the one to include them, nor do they get included automatically. I'm using only one images field in my template and the page is multilingual. Any hints what I'm doing wrong? Thanks.
  7. @Sergio A late Bingo! After a few hours of sleep I picked up your hint once more, although I still don’t understand what's going on with the hyphens. So I simply deleted the _strings.php of the translater and re-imported it. The number of hyphens appeared reduced and everything works now as expected. Another big thank you – the day is suddenly showing a much sunnier face as this little evil is defeated.
  8. @Robin S Thanks for your recommendation. I installed TracyDebugger and spontaneously I'm a bit overwhelmed (it's long after midnight here and the fights did weaken me). Anyway, it's definitely a highly interesting tool that I will examine in detail soon. @Sergio You do lot of work to help me, that’s very friendly. Your secont hint could lead into the near of a solution, as I assume a problem with paths. Unfortunately I don’t understand the relation of the path in the function and the number of hyphens the translator produces. Regarding my settings: before I tried the _strings.php method, I travelled the exhausting road of translating with __('term') file by file. That worked just fine, I only found it a bit too exhausting on the long run and started looking for a faster way (haha). So there might be something wrong with the settings, but it must be very subtile then.
  9. Hi guys, after hours of trying and reading several threads I suppose tears will start running soon. I work with the widely spread and documented method of a _strings.php file and a t() function. Everything seeems to run fine, the translator finds the _strings file, all phrases are translated properly and no error messages are showing up. Except that no translatiions are shown at all, no matter what I do: It's like a hopeless struggle with deceitful demons. My _init.php: include_once("./_func.php"); include_once("./_strings.php"); (in this order). Then in _func.php: function _t($text, $context, $textdomain = "/site/templates/_strings.php") { return _x($text, $context, $textdomain); } and in _strings.php: <?php namespace ProcessWire; /* _x('Home', 'generic'); _x('/en/', 'generic'); _x('Contact', 'footer'); _x('/en/contact/', 'footer'); _x('Other projects', 'footer'); */ ?> Trying to call the translations for example in the footer template like this: <li><a href='<?php echo _t('/en/contact/', 'footer'); ?>'><?php echo _t('Contact', 'footer'); ?></a></li> leads to this result , no matter what language is active. <li><a href='/en/contact/'>Contact</a></li> The translator has everything it needs: { "file": "site\/\/templates\/_strings.php", "textdomain": "site----templates--_strings-php", "translations": { "33fa1c21648d73e1ac14e0db66b4fa9e": { "text": "Start" }, "2f73c44cbb8a98616f8aeca67192aec6": { "text": "\/de\/" }, "77eb6543a21ba5c45f9c11f899136eee": { "text": "Kontakt" }, "68780987fca9c3f52fb511f87cd43262": { "text": "\/de\/kontakt\/" }, "184cf75de619c2e3a02a40f163c81c5e": { "text": "Weitere Projekte" } } } Obviously there seems to be a connection problem between the _func and the _strings file. Instead of $textdomain = '/site/templates/_strings.php' I can fill in whatever I want without any recognizable difference. Any hints what else I could try? Cheers Ralf
  10. Hi Zeka, BINGO, that’s it, problem solved! The easyness and logic of your solution is probably a bit embarrasing for me, but sometimes I don’t see the most obvious things. So thanks a lot, you saved a lot of my time and nervs. Ralf
  11. Hi guys, I’m struggling with an annoying problem which I guess where it comes from, but can‘t find a way to get rid of it. When I try to preview hidden oder unpublished posts in the /kompendium/ category, I'll receive a 404 error, when I do the same thing with posts of other catgegories, everything works as expected. The only difference is an url thing I’ve bulit to shorten urls like /kompendium/entry to /entry/, while others are formed completely like /category/entry/. To enable this, I use the following code in my home template: <?php if (strlen($input->urlSegment2)) { // 2 segments => 404 throw new Wire404Exception(); } else if (strlen($input->urlSegment1)) { // 1 segment, check whether it exists in /kompendium/ $name = $sanitizer->pageName($input->urlSegment1); $post = $pages->get("/kompendium/")->child("name=$name"); // if so render /kompendium/name/ if($post->id) { echo $post->render(); } // else 404 else { throw new Wire404Exception(); } $render_homepage = "no"; } if ($render_homepage != "no") { // render normal home content } ?> and in _init.php there is the following hook to ensure lists are generated in the wanted manner (all entries in /kompendium/ and only those work with template pg_entry) <?php ProcessWire\wire()->addHookBefore('Page::path', function($event) { $page = $event->object; if($page->template == 'pg_entry') { $event->replace = true; $event->return = "/$page->name/"; } }); ?> So everything is fine beside the preview/404 problem with hidden/unpublished posts. As some of them show quite complex content, the preview funtion is important. Any hints, why it doesn’t work? Thanks Ralf
  12. Problem solved. After mailing the provider, everything mysteriously started to work as it should. I fear, I don’t really understand what exactly caused the problems – some weird combination of »properties« and »permissions«, his explanations were not to detailed. So thanks again Horst and Robin for your help. Ralf
  13. Okay, now I set all files on the server to owner 'User'. Still no image is shown, not in frontend, not in backend. Sad, but true. I’ll better try to cry myself into sleep now, this day definetely was’nt mine.
  14. Thanks Horst for pointing to the right direction – after inspecting how to solve the problem concretely, I found a provider’s ReadMe telling me bascially the same. The offered options are exactly two: owner is either 'User' (Me) or 'PHP-User', named '33'. When I set the owner of /site/assets/ to 'User' (recursively), nobody will see not even a single image. Chosing the second option 'PHP-User', I receive the completety irritating require_once error (and nobody will see anything else at all). As there is no third option available I don’t see the right method to get it done.
  15. Hi guys, bad day today. I first updated PW to 3.0.42, everything went fine without any problem. Then I changed the PHP version of my (shared) server and the weirdness started: 1. I switched from PHP 5.5 (Apache module) to 7.1 in CGI mode. There were a few minor issues with too less function parameters that I got fixed in minutes. The only real strange thing was that no images were shown anymore, neither in frontend nor in backend. Trying to call an image directly by it’s URL led to a 403 message, telling me I don’t have access to the site/assets directory. 2. To find out whether the problem is specific to PHP 7.1, I »downgraded« to 7.0 and 5.6 in CGI mode, both didn’t change anything. 3. I finally »reset« everything to the 5.5 version as Apache mode again, now everything seems to be broken. In frontend I get Compile Error: require_once(): Failed opening required '~/site/modules/TextformatterTextile/src/Parser.php' (include_path='~/wire/modules/Markup/MarkupHTMLPurifier/htmlpurifier/standalone:.:/usr/share/php:..') (line 39 of ~/site/modules/TextformatterTextile/TextformatterTextileField.module) (The file is definitely there). In the backend I receive DirectoryIterator::__construct(~ /site/assets/files/1148/): failed to open dir: Permission denied The process returned no content. when I try to edit a page. There seems to be a serious permission problem, but I don’t know where to start. If nothing helps, I will ask my provider for a yesterday’s server backup, but I would prefer to understand at least the basics of what is going on. UPDATE: Meanwhile I returned to the PHP 7.1. update. At least this situation hasn’t changed: all is working well except the images are still missing, in frond- and backend as described above. The require_once errors are gone, so my ideal solution would be to stay with PHP 7.1. but with correctly displayed images.
  • Create New...