Jump to content

hdesigns

Members
  • Posts

    52
  • Joined

  • Last visited

Posts posted by hdesigns

  1. If you only want to be a web developer my advise would be to look for a web developer job.

    People tend to forget about the most important part of being a freelancer: networking!

    You have to be good in communicating with people. That means being open, talk to people (getting to know them, etc.), especially in the beginning when you're not a big deal yet.

    And as pwired already mentioned probably the most dificult task as a web designer is to find out what the client wants even though the client doesn't know that himself (or just isn't able to tell it).

    The coding/designing part is in fact the easiest! At least, that's what I experienced...

    • Like 5
  2. I actually went now with:

    jQuery('a[href*="/assets/files/"]:has(img)').fancybox();
    

    because I didn't like the idea of altering the dom only to apply another javascript.

    So in the end, it is like I wrote in my initial posting

    I'm pretty sure this is also possible without any id or class.

    But the different-thinking-approach led me there, great work Martijn!

    I'm still thinking about adding a static class to every image inserted with CKEditor so I could identify these images and change their appearance with CSS. For this I now have Nicos solution, just perfect!

    • Like 2
  3. I stumbled upon a (really small) problem while I was trying something relatively simple (as I thought):

    I was adding a resized image with CKEditor (same thing goes for TinyMCE) and checked the option to add a link to the full-sized version. So far so good. The next step for me was to make the full-sized version popping up if someone is clicking on the image (on the front-end of course). So I used fancybox to make this happen. But then I got stuck because as it looks like the anchor-tag has to have some css-class or id to indicate the fancybox-script that this image has to be fancyboxed.

    I'm pretty sure this is also possible without any id or class. But this is not my point. My point is that it should be possible to add a class to every image that was included with the ProcessPageEditImageSelect (which is used by both CKEditor and TinyMCE to insert an image).

    This module is already configurable. I suggest to add another configuration-item named somewhat link-class that would be empty by default.

    But if someone, like me, wants to add a css-class to every linked image, he/she could simply set a class name...

    What do you think about it? I know, it's a really small change, but maybe some people could benefit on that.

    I was thinking of editing the ProcessPageEditImageSelect so it behaves like I said, but I'm feeling a bit uncomfortable hacking on core modules (problems on updates and so on)... What is your opinion on that?

  4. Today I've created a really simple little module that is configurable and attaches to hooks.

    So it has more or less everything of a real world module in it.

    I thought processwire beginners would be interested in reading how to create such a module so I added some comments to the source code in a way the module should explain itself...

    Here it is:

    /**
     * BackgroundChanger module for demonstration purposes
     *
     * Demonstrates the Module interface and how to add hooks in a more real world manner...
     * 
     * ProcessWire 2.x 
     * Copyright (C) 2014 by Domenic Helfenstein
     *
     */
    
    class BackgroundChanger extends WireData implements Module, ConfigurableModule {
        public static function getModuleInfo() {
            return array(
                /*
                 * the __("text") methods are used for multilanguage support
                 * see: https://processwire.com/api/multi-language-support/code-i18n/
                 */
                'title' => __('BackgroundChanger'),
                'summary' => __('This is a simple real world module that can change the background color.'),
                'version' => 105,
                /*
                 * autoload must be true if the module depends on hooks
                 * see: http://wiki.processwire.com/index.php/Module_Creation#Details_of_what_the_.22autoload.22_property_means
                 */
                'autoload' => true,
                /*
                 * it is wise to run modules in singular mode when using hooks
                 * see: http://wiki.processwire.com/index.php/Module_Creation#Details_of_what_the_.22singular.22_property_means
                 */
                'singular' => true,
            );
        }
        
        public function __construct() {
            //set default values
            $this->backgroundColor = 'yellow';
            /*
             * !!! the value in the db will be automatically injected into this var 
             * because it is named equal to the value of $field->name in 
             * getModuleConfigInputfields !!!
             */
        }
        
        public function init() {
            // add a hook after each page is rendered and modify the output
    	$this->addHookAfter('Page::render', $this, 'changeBackground');
        }
        
        public function changeBackground($event) {
            $page = $event->object;
    
            //do only modify non-admin pages
            if($page->template == 'admin') return;
            
            $extension = <<< _OUT
                <style>
                    body {background-color:{$this->backgroundColor};}
                </style>
    _OUT;
            $event->return = str_replace("</head>", $extension."</head>", $event->return); 
        }
        
        public static function getModuleConfigInputfields(array $data) {
            //create a fieldset
            $inputfields = new InputfieldWrapper(); 
     
            //create field for background color
            $field = wire('modules')->get('InputfieldText');
            $field->name = 'backgroundColor';
            $field->label = __("Enter the hex-code or name of the desired background color. (visit colorpicker.com)");
            
            //if there is already a value stored, set this value to the field
            if(isset($data['backgroundColor'])) $field->value = $data['backgroundColor'];
            
            //add the field to the fieldset
            $inputfields->add($field);
     
            //return the fieldset to display
            return $inputfields; 
        }
    }
    

    I hope this helps others creating their own modules!

    BackgroundChanger.module

    • Like 18
  5. I open this topic because in another one (http://processwire.com/talk/topic/1732-shop-for-processwire-apeisa/) there was a discussion going on that -in my point of view- went off-topic.

    Here's what it's all about:

    Say you want to create a module that needs some additional scripts/stylesheets what is the best way to accomplish that?

    Right now I only know three ways (which all have their weaknesses):

    First: Just edit the head.inc and include those scripts in the head-tag.

    OK, this is pretty easy but it has two drawbacks:

    - The scripts are now on every page (in the front-end)

    - You have to edit the head.inc*

    Second: Include

    <?php foreach($config->scripts->unique() as $file) echo "\n\t<script type='text/javascript' src='$file'></script>"; ?>
    

    in your head.inc and add the scripts from your module with

    $this->config->scripts->add($this->config->urls->PaymentExample . "script.js");
    

    This seems pretty neat because the scripts will only be included where they are needed, but:

    - It is not very flexible. What about in-site scripts?

    - You have to edit the head.inc*

    Third: Use the hooking- mechanism of PW by adding

    $this->addHookAfter('Page::render', $this, 'addScripts');
    

    to the init- function of your module.

    This is the addScripts function:

    public function addScripts($event) {
    		$page = $event->object; 
    
    		// don't add this to the admin pages
    		if($page->template == 'admin') return;
    
                   //other mechanisms to ensure the script only loads when this module was called in the front-end
          
          $additionalHeadScripts = '[myScripts...]';
    
    		$event->return = str_replace("</head>", $additionalHeadScripts.'</head>', $event->return); 
    	}
    

    Of course this approach also has its drawbacks:

    - It is a bit difficult

    - It probably makes your PW installation run a bit slower because the addScripts- Methods gets called on every page request.

    *Why is it a bad thing to edit the head.inc to provide scripts/stylesheets for your module?

    I personally think if you want to distribute a module the admin that wants to integrate this module should just hit the install button and do some configurations and that's it. This is called usability and I believe in it.

    In my opinion it is not user/admin friendly if you have to pack a readme file to the module that says "but first you have to alter your
    template file to make that module work"...

    That said, if

    <?php foreach($config->scripts->unique() as $file) echo "\n\t<script type='text/javascript' src='$file'></script>"; ?>
    

    was already in the default template head.inc file I would not hesitate one second to use the second approach for my module. Because if an admin creates his/her own template and it is not based on the default template it's his/her fault...

    So, what do you think? Which is the best approach for you and why?

    Or do you have another approach?

    Maybe it would also be a good thing if there was something in the API that we could use for this need. A more standardized approach?

    • Like 3
  6. What you mean by "you have to integrate that code line in the template header" ? Why is this bad?

    If you want to distribute a module the admin that wants to integrate this module should just hit the install button and do some configuration. It's called usability...

    In my opinion it is not user/admin friendly if you have to pack a readme file to the module that says "but first you have to alter your template file to make that module work"...

    I understand you, my approach definitely has it's weaknesses:

    - If everyone would do it the way I did PW would risk to get (much) slower

    - It needs some (minor) adjustments on the main shop module. So if apeisa decides to keep the code as it is I can't distribute the module either.

    Maybe we're a bit off-topic now because this is a whole different problem and has not necesserily to do with apeisas shopping module.

    Maybe we should open a new thread to discuss what is the best approach for inserting scripts from a module...

    [Edit:]

    I've created a new topic for that: http://processwire.com/talk/topic/4472-how-to-insert-scripts-and-stylesheets-from-your-module/

  7. I've read a lot about this approach but I don't like because -as you mentioned- you have to integrate that code line in the template header.

    Here's what I've done:

    public function addScripts($event) {
    		$page = $event->object; 
    
    		// don't add this to the admin pages
    		if($page->template == 'admin') return;
          
          //only add it if we are in the payment section of the shoppingCheckout module
          if(!$this->modules) return;
          $checkoutModule = $this->modules->get('ShoppingCheckout');
          if(!$checkoutModule) return;
          if($this->input->urlSegment1 != $checkoutModule->paymentUrlSegment) return;
          
          $additionalHeadScripts = '[myScripts...]';
    
    		$event->return = str_replace("</head>", $additionalHeadScripts.'</head>', $event->return); 
    	}
    
  8. Hi Soma

    Here's the deal: In my payment module I need to include some js and css in the head of the html.

    I'm totally new to PW so maybe there is a simpler approach (beside just editing the template because I don't want everyone to edit his/her template only to make my module running). If there is one I'm happy to hear.

    As far as I understand you I could just create another module only for the script inclution. While this works for sure I'm not happy with the idea. For me it just doesn't make sense to create another module because the payment module could not run without the "render hook module"...

    btw: I don't think this problem occurs only in my payment module. Many credit card gateways demands you to include some kind of js in your page to make their process work.

  9. While creating my own payment module I made an interesting discovery:

    It is not possible to add a page render hook to the payment module because it will result in an internal server error (500).

    Checking the error log:

    Error:  Call to a member function getModuleConfigData() on a non-object (line 14 of [...]\site\modules\Shop-for-ProcessWire-master\PaymentAbstract.php)
    

    [edit:]

    The problem is if you want the page render hook to work you have to set autoload to true. This results loading the module with every page requests. As soon as PW loads the custom payment module it also loads PaymentAbstract because the custom payment module inherits from
    PaymentAbstract. So the PaymentAbstract constructor gets called but because it is in the wrong context (because maybe the user is request a page from the backend or so) some objects are missing...

    [edit-end]

    So I altered the PaymentAbstract.php constructor checking first if $this->modules exists:

    if($this->modules) {
             $data = $this->modules->getModuleConfigData('ShoppingCheckout');
             if (!isset($data['completedUrlSegment'])) {
                $module = $this->modules->get('ShoppingCheckout');
                $data = $module::getDefaultData();
             }
             $page = $this->page;
             $this->currentUrl = $page->url . $data['paymentUrlSegment'] . '/';
             $this->completedUrl = $page->url . $data['completedUrlSegment'] . '/';
          }
    

    I'm not sure if this is the best solution but it works for me.

    @apeisa: If you think this is a good solution it might be a good idea to fix it in the github as well...

    • Like 1
  10. Thank you Soma

    It works perfect for me (and makes absolutely sense). This little tweak should definitely be integrated in the github- trunk.

    It's such a great pleasure to see members in a support forum that really know what they are talking about. The last three years I've worked with joomla and it was horrible because 95% of all the answers from "experienced" admins where about clicking something and installing another module...

    Thanks again!

    • Like 3
  11. First of all, great work from everyone who contributed to this module so far.

    I'm totally new to ProcessWire but I instantly fell in love with the system...

    Now I have two questions.

    First:

    @Luis: Is it correct that http://besser-landen.de/shop/ is from you and based upon the Shop-for-ProcessWire module?

    If so, would it be possible to share the paypal checkout module and maybe even the whole template?

    I saw you posted a template already but as far as I can tell it is not the same version you're now running...

    Second:

    @apaisa

    I set up the webshop as you described it at https://github.com/apeisa/Shop-for-ProcessWire (in the ReadMe).

    I recognized an odd behavior:

    I can add products to the cart and if I go to the cart they are listed,

    $modules->get('ShoppingCart')->getNumberOfItems();
    

    also gives me the right amount of different products added to the cart. But as soon as I proceed to the checkout page it gives me an error "Your shopping cart is empty." and the code posted above also returns 0.

    Totally strange, isn't it? What could be the reason and how can I avoid it?

×
×
  • Create New...