Jump to content

MarkE

Members
  • Posts

    921
  • Joined

  • Last visited

  • Days Won

    10

Everything posted by MarkE

  1. Needing to move on, I trashed and re-created the page. Weird dialog box when I trashed it: I clicked OK and it did go into trash though. So I think it's fixed, but I'm still pretty puzzled about what happened....
  2. This is probably something really stupid, but I have one page that cannot be edited - instead it just downloads the index.php file when I click on 'edit' in the page tree. Any ideas?
  3. Seems like the best fix for this is to add <IfModule mod_security.c> SecRuleEngine Off SecRequestBodyAccess Off </IfModule> to the .htaccess file. I wonder if this should be provided (commented out) in the default PW file?
  4. bodyFoot is just a (CKE) textarea field in a page with template=Availability. It holds a comma-separated list of hosts which are permitted to access the Availability page in site-admin. $host is the name of the site-web host. So all the select is doing is checking that $host is in the list of hosts. I realise that it might have been better to explode the list and then check array membership but, ignoring that for now, I am puzzled by your example - I get "Yes" for both too. Examining the (real) situation a bit more, I added some Tracy debugging to the code as follows: $host = $config->httpHost; bd($host, 'host'); bd(adminSite()->pages->get("template=Availability")->bodyFoot, 'bodyFoot'); $adminPage = adminSite()->pages->get("template=Availability, bodyFoot%=$host"); // bodyFoot holds permitted hosts list for PW sites bd($adminPage, 'admin page in Prices'); $availabilityTable = $adminPage->runtime_markup_availability; This is the output with the real data (in 3.0.184): Replacing the %= by *= in the code results in the following: In version 3.0.165, the *= yielded the same result as %=
  5. I did wonder if that might be the case. I need to use the setting in both sites, having just set it in site-web, and I thought setting() achieves that whereas adminSite() is not available to the other site. However, it seems I am wrong and that the adminSite() function is available in site-admin when that instance is called from site-web. So I removed the extra line and everything seems to work, thanks! bodyFoot was "<p>myText, some more text, ... </p>" and $host was "myText" so your explanantion is spot on and in line with the docs. However, *= worked in 3.0.165 with exactly the same values so it looks like something changed... No worries, it all works now, but I wonder if there might be a problem lurking for others if indeed there was a change.
  6. MarkE

    Hanna Code

    The more I look at this, the more it seems to me to be a bug. The current method has the effect of not only removing the namespace, but also failing to add: if(!defined("PROCESSWIRE")) die("no direct access"); to the Hanna code. In my case, I have dozens of Hanna codes all just calling one hannaCode() function, so that I can maintain the codes in my IDE rather than the PW UI (much less time-consuming!). The upgrade seems to require me to edit every single Hanna code, which surely ought not to be the intention. I have therefore hacked my TextFormatterHannaCode.module to include the following in getPHP(): $php = '<' . '?php'; $openPHP = $php; $openPHPNS = "$php namespace ProcessWire;"; $firstLine = 'if(!defined("PROCESSWIRE")) die("no direct access");'; if(strpos($code, 'namespace') && preg_match('/(namespace\s+ProcessWire(?:;|\s*;))/', $code, $matches)) { $openPHP = $openPHPNS; $code = str_replace($matches[1], '', $code); } if(strpos($code, $openPHP) !== 0 && strpos($code, $php) !== 0) { // prepend open PHP tag to code if not already present $code = "$openPHPNS\n$firstLine\n$code"; } else { // otherwise insert our $firstLine security check $code = str_replace($php, "$openPHPNS\n$firstLine\n", $code); } This automatically adds the namespace and the 'die' to all Hanna codes and works (so far) for me. Perhaps others ( @adrian, @ryan?) might suggest a better fix or tell me that I've got it all wrong ? EDIT: I have raised an issue on GitHub for this
  7. MarkE

    Hanna Code

    I am confused by this. Surely it should not be necessary to both add the namespace in the Hanna code AND call the function \ProcessWire\myFunction()? So I looked at the TextFormatterHannaCode.module - getPHP() method and found this: $php = '<' . '?php'; $openPHP = $php; $openPHPNS = "$php namespace ProcessWire;"; $firstLine = 'if(!defined("PROCESSWIRE")) die("no direct access");'; if(strpos($code, 'namespace') && preg_match('/(namespace\s+ProcessWire(?:;|\s*;))/', $code, $matches)) { $openPHP = $openPHPNS; $code = str_replace($matches[1], '', $code); } if(strpos($code, $openPHP) !== 0 && strpos($code, $php) !== 0) { // prepend open PHP tag to code if not already present $code = "$openPHP\n$firstLine\n$code"; } else { // otherwise insert our $firstLine security check $code = str_replace($openPHP, "$openPHP\n$firstLine\n", $code); } It seems that the method is removing "namespace ProcessWire;" from the Hanna code. Looking at the cached files shows this to be the case. In other words, adding "namespace ProcessWire;" to the Hanna code is pointless as \ProcessWire\myfunction() is still going to be needed. I really don't know why the above code has been added or what it is trying to achieve?
  8. I used setting() because I needed to access the object in site-admin* as well as site-web. So I used your code and added: if (!setting('admin_site')) setting('admin_site', adminSite()); Both sites are in the same installation so use the exact same version Done that. Everything works except for the cross-site referencing as reported - I'm still getting a null page returned. (The code reversion problem seems to have been temporary). *Note: I need to access the object in site-admin because the availability page is running in site-web - called by $availabilityTable = $adminPage->runtime_markup_availability; (where $adminPage is the one that is currently being returned as null) but the runtime_markup code is in site-admin and needs to use the site-admin instance of wire(), not the site-web one. (Why is the runtime_markup code in site-admin? Because there can be multiple public websites which may or may not be PW sites and I want them all to use the same code to render the availability table which is defined in the admin site). Sorry if it's a bit complicated, but it was all working so well in 3.0.165! EDIT: The above is probably all irrelevant! The problem seems to be to do with the selector bodyFoot*=$host which is finding the correct page in 3.0.165 but not in 3.0.184. Using just "template=Availability" works fine and the found pages have field bodyFoot with the text $host. So I changed *= to %= and now it works! I guess at sometime the selector method got changed very slightly, so I will check for other instances of that. Anyway I'll keep the changes you suggested @ryan as they are an improvement anyway ?
  9. Just trying to update a multi-instance site to 3.0.184 from 3.0.165 but the cross-linking between the two sites no longer works. The two sites are /site/ - essentially the admin site for property bookings - and /site-web/ for the public website and which publishes availability from /site/. In /site-web/templates/_init.php I have: setting('admin_site', new ProcessWire($config->paths->root . 'site/')); and in /site-web/templates/prices.php I have: $adminPage = setting('admin_site')->pages->get("template=Availability, bodyFoot*=$host"); // bodyFoot holds permitted hosts list for PW sites bd($adminPage, 'admin page in Prices'); In 3.0.165 $adminPage is the correct Availability page. In 3.0.184 it is a null page. I have tried clearing FileCompiler from cache in both sites, but still get the same result. I also did a dump of setting('admin_site') in both versions and it looks identical. Is there anything in 3.0.184 that might have changed to cause this? Any other ideas? Thanks. EDIT: Another really weird thing. If I try and edit site-web/templates/_init.php to add debugging then it keeps reverting when reloading - like PW is editing my php file! This only happens with 3.0.184, not 3.0.165. Think I'm losing my mind!
  10. For the benefit of anyone else wanting their module to be comptible with earlier versions of PW, I suggest you use: $tab1 = $this->wire(new InputfieldWrapper()); not $tab1 = $modules->get('InputfieldWrapper'); Also, do not use plain $tab1 = new InputfieldWrapper(); as the column widths of the contained inputfields will not work properly. Per the PW coding style guide:
  11. Ta. The site is on 3.0.165. @Robin S's module is on 170. Hopefully a new core is out soon and I will move to that. However, I am using this in my ProcessDbMigrate module (full alpha release shortly.... ?) and I have tried to make that compatible with 3.0.148 (even pre page class days). I'm not sure what the best policy is regarding the backwards compatibility of new modules.
  12. Yes. If I put the same code as the above into the Tracy console on my system, it returns null.
  13. InputfieldWrapper is not a module AFAIK - at least in my v 3.0.165 new InputfieldWrapper() works ok though.
  14. If you find a solution to a question you ask, the best thing is to post the answer for the benefit of others and add SOLVED to the title.
  15. If I split the path into its segments then PW gets it just fine: Odd!
  16. I'm trying to make my ProcessDbMigrate module operate in pre-PW3.0.152 versions, but I've hit a really weird issue which is best illustrated in the following: As you can see, I obtain the path of the current page in the Tracy console, then attempt to find it in $pages->get() but it yields a null page. The same code works fine in the parent page and in a similar page PW3.0.165. Any ideas what might be causing this?
  17. It can really help to use Tracy Debugger to debug issues like this
  18. Is your echo showing the file? I would have used: $directory = $config->paths->assets . "files/1048/"; // files uploaded here via ftp or maybe wire()->config ... depending on context Is 'file' the name of your files field?
  19. Why not just use the browser features with @media print in the css?
  20. I didn’t realise star counts were used in this way. anyway, now 699 ? Good idea.
  21. Depending on what you are trying to achieve, one approach is to have a page ref field in the category template to ref back to the recipes, then use the ConnectPageFields module to keep them in sync. That then gives you lots of options for viewing and updating.
  22. The approach I actually use for a web app is to start with a class diagram. The classes, properties and methods then become the templates, fields and methods (roughly speaking) in PW, where the methods are added to the TemplatenamePage class. For many<->many relationships which don’t hold data, I often use ConnectPageFields by @Robin S - it’s a really useful module. Looking at the app, I see that of the approximately 50 templates, around 30 have associated Page Classes, so I don’t think that number could be reduced much. I could probably have got away with fewer fields by more intelligent re-use or if I had purchased ProFields. No. I wasn’t aware of it when I built that app. I did spot it later and looking at it again now, I realise that it may have wider application than I first thought. I’m not sure it would have saved a lot for the app in question, though.
×
×
  • Create New...