Jump to content

kongondo

PW-Moderators
  • Posts

    7,529
  • Joined

  • Last visited

  • Days Won

    160

Everything posted by kongondo

  1. If you want to have the settings on one page trigger some other change in some other page then generally you need a hook, probably in an autoload module that will listen to your pages where the initial change is occurring (basically an 'event') and then dynamically/automatically effect changes in a different page(s). I am not all that with hooks (yet) but others here should be able to guide you . Maybe describe your situation further, e.g. a step-by-step sequence of events as well as exactly what needs changing, e.g. fields need to be populated, pages need to be published, etc...Hope this makes sense
  2. I see now that according to your first post, you have CKEditor version 1.2.0? No wonder it doesn't work ...I am on PW 2.5 with CKEditor 4.4.3. CKEditor is now the default editor in PW. I think your version is the old one from the modules directory. I urge you to upgrade to PW 2.5 . The extra allowed content in PW 2.5 is a textarea. The code I posted above should be entered just as I have shown. One line of code per line. When you upgrade you will also be able to see the 'Beautify....' settings...
  3. Add the following to your Extra Allowed Content (Input tab when editing your field) table[class](*) tr[class](*) td[class](*) tbody[class](*) em[class](*) br[class](*) What the above mean is that those tags will be allowed and they will also be allowed to have 'classes'. Have a read from here downwards for some quirks with HTML5 Also see the setting Beautify Markup Toggles: helps remove empty <p></p> tags and Btw, why do you need the <em> again? You already have that with CKEditor...Also inbuilt lists work just fine for me...No extra <p> added.
  4. In addition to what Craig said, remember that PW 'users' are also pages that use templates. Those templates can be extended to contain other fields if that's part of the issue here.
  5. Password Fieldtype values are hashed and salted. I am curious, why would you want to find pages using their passwords anyway?
  6. Only other thing I can think of is have you double checked that you have defined $header_image in your _init.php as you stated in you OP? If you haven't, it will fail silently - similar to what you are seeing (or to be precise, not seeing!).
  7. Well I am stumped on this one. Clutching at straws now. Have you tried with a different image? Temporarily deleting all code in your _main.php and echoing the following (or putting it at the very top of the file) : echo "<img src='{$page->header_image->url}' alt='{$page->header_image->description}' />"; exit; Do you see the image? Btw, Adrian's code is for when you have an array of items.
  8. Uh? I get a 'site not installed' message when attempting to view your site. Don't know if you've seen it but there's a guide on how to implement CKEditor or TinyMCE in the frontend https://processwire.com/talk/topic/7366-frontend-form-with-tinymce-or-ckeditor-module/
  9. OK, an output of 1 means there is an image there. I have tested your exact code on a fresh test PW site at lightning.pw using the default site profile - intermediate version (aka 'delayed output version') and the image is output correctly. There must be some other funkiness going on on your install. Can you provide a screenshot of your Fields > Edit Field: header_image Details Tab similar to mine below? I have a feeling you have selected the 'wrong' formatted value on that page. What you describe would happen, for instance, if you selected the 'Rendered string of text (that you provide)' option but didn't provide a string... In addition, the HTML output that you've shown in your OP, for the <img> tag, is that the exact output or do you have something similar to the code below? Or, more precisely, if no image is output and you view the source in FireFox Firebug, the code will be like what you've posted above but if viewed in Chrome, it will be like below (but it adds the " " for the attributes when copied): <img src alt> Screen: header_image Details Tab when editing the field
  10. Hi joebaich, Welcome to the forums! Have you tried it with PW 2.5 yet? Here's a note from Ryan (module author) dated April 2014 in the first post
  11. @Charles, this looks awesome! I like the SEO resources idea (the videos, etc.)
  12. The question is is your header_image field set to accept multiple images or only a single image? Anyway, if it was set to accept multiple images, Adrian's code should have worked. Have you confirmed the image field is actually called header_image? Have you confirmed there is actually an image on that page you are trying to output? If you use the code below in your main template file and view the page with header_image, what do you get? echo count($page->header_image); exit;
  13. There's this old demo...
  14. @Mel, Unfortunately sometimes some posts get buried in the forums. It is not an issue of unwillingness on our part to provide a response . Hopefully by bumping this, you will get a response soon . My opinion is that the 'level of knowledge assumed' varies. For newbies, in many responses, the expectation is that they at least know their HTML. To use PW effectively, one should also know or be willing to learn at least some very basic PHP. Of course, one would also be expected to be willing to learn how to use the basic PW API - $page, $pages and selectors and also search the forums for similar topics. I am sorry that this has been your experience. I've always felt that those 'clever contributors' know when my skills run out of road and they are always willing to chip in. The caveat here is that I also need to show some willingness to learn. I am not saying that you are not willing to learn! Just saying that forum members are always willing to help Anyway, let's hope this gets picked up and answered...
  15. Hi Salles Welcome to the forums. You can easily create categories and tags using PW pages and page fields. That's how many normally approach this. This tutorial might also be helpful.
  16. At the moment no. You would have to use CSS to hide the page navs I am afraid.. I tested in the multi-language site profile and saw something similar. I will raise the issue with Ryan to try resolve this. I don't know what is causing the problem but it is definitely only happening on the multi-language site profile and not the others.
  17. @Steve, Just to answer my own question about how the search for the 'indexed key' would work [database side of things] - this could either work the way PW handles repeater fields - data stored as comma separated integers (1234, 5688), i.e. $size,$variation ID pages respectively as you suggested, or why not store them as PW multiple page fields - i.e. a row for each addition, consisting of page id (integers) i.e. E.g. assuming Red = ID 1124, small = 2545 and medium = 2745 $variation $size $amount 1124 2545 $20 1124 2745 $10 On the inputfield side of things, the user will still be able to see a table similar to the one I posted above that would grow both vertically and horizontally with each new addition of size and variation...Of course horizontal growth could get very messy very quickly...
  18. Was having some fun with this already....nothing concrete atm..customising Ryan's FieldtypeEvents
  19. @Steve, Good point. I was thinking along those lines (the indexed key) but wasn't sure how search would work (i.e. grab 'red small' t-shirts) using PW API and related performance issues. Back then, I was thinking storing the pairs using json like syntax $size:$variation - something similar to yours.
  20. Hey @justb3a, Welcome to the forums! Awesome first post! Thanks Edit: Tested this. Works like a charm!
  21. Me again... Will your product sizes be fixed, i.e, always S, M, L? If yes, can your matrix be like this instead? | S | M | L | –––––------------------------ Red | | | | –––––------------------------ Blue | | | | –––––------------------------ Green | | | | –––––------------------------ Black | | | | –––––------------------------ meaning....only add rows with new variants but columns will be fixed...
  22. Hmmm... Creating the matrix is the easy part. The problem is deciding where and how that data will be stored. At the end of the day you want to be able (preferably) to easily query your data using PW API, say find the price of 'small red' t shirts.... The problems with my solution are, e.g. where do you store the price of a 'Large Blue' t-shirt? If you had a fixed number of variations, fine, but in your case they are dynamic. A 'pink' variant can be added later and you want to be able to accommodate that...hmm... Maybe the fieldtype route is the way to go . I am not sure how Martijn's FieldtypeJson works but it seems to be able to accommodate any number of columns. If you want to go down that route, then you can adjust that Fieldtype to suit your use case. It's a matter of rewriting the code and renaming the module class. Of course, you need to know what you are doing... . There's also Ryan's event fieldtype that could be modified to do what you are after...
  23. OK, let me wade in as well @Charger, I don't think there is a module like that. Does this have to be a fieldtype or would a ProcessModule do? i.e. a custom view/page within the admin. The table cells would be input fields that contain any data you want. This is a similar idea to what Adrian mentioned above. The ProcessModule would just be a means of easily entering your data but these would be stored within the fields of your pages themselves. The advantage with this approach is that you could have a table of all your products, then clicking on an edit button/link would bring up the matrix. This would be built on the fly based on the number of your 'child pages'...Anyway, just thinking out loud here...
×
×
  • Create New...