Recherche avancée

Médias (91)

Autres articles (51)

  • Publier sur MédiaSpip

    13 juin 2013

    Puis-je poster des contenus à partir d’une tablette Ipad ?
    Oui, si votre Médiaspip installé est à la version 0.2 ou supérieure. Contacter au besoin l’administrateur de votre MédiaSpip pour le savoir

  • Les autorisations surchargées par les plugins

    27 avril 2010, par

    Mediaspip core
    autoriser_auteur_modifier() afin que les visiteurs soient capables de modifier leurs informations sur la page d’auteurs

  • D’autres logiciels intéressants

    12 avril 2011, par

    On ne revendique pas d’être les seuls à faire ce que l’on fait ... et on ne revendique surtout pas d’être les meilleurs non plus ... Ce que l’on fait, on essaie juste de le faire bien, et de mieux en mieux...
    La liste suivante correspond à des logiciels qui tendent peu ou prou à faire comme MediaSPIP ou que MediaSPIP tente peu ou prou à faire pareil, peu importe ...
    On ne les connais pas, on ne les a pas essayé, mais vous pouvez peut être y jeter un coup d’oeil.
    Videopress
    Site Internet : (...)

Sur d’autres sites (7490)

  • file : Add an avoption for disabling truncating existing files on open

    9 septembre 2012, par Martin Storsjö

    file : Add an avoption for disabling truncating existing files on open

  • Working on images asynchronously

    15 décembre 2013, par Mikko Koppanen — Imagick, PHP stuff

    To get my quota on buzzwords for the day we are going to look at using ZeroMQ and Imagick to create a simple asynchronous image processing system. Why asynchronous ? First of all, separating the image handling from a interactive PHP scripts allows us to scale the image processing separately from the web heads. For example we could do the image processing on separate servers, which have SSDs attached and more memory. In this example making the images available to all worker nodes is left to the reader.

    Secondly, separating the image processing from a web script can provide more responsive experience to the user. This doesn’t necessarily mean faster, but let’s say in a multiple image upload scenario this method allows the user to do something else on the site while we process the images in the background. This can be beneficial especially in cases where users upload hundreds of images at a time. To achieve a simple distributed image processing infrastructure we are going to use ZeroMQ for communicating between different components and Imagick to work on the images.

    The first part we are going to create is a simple “Worker” -process skeleton. Naturally for a live environment you would like to have more error handling and possibly use pcntl for process control, but for the sake of brewity the example is barebones :

    1. < ?php
    2.  
    3. define (’THUMBNAIL_ADDR’, ’tcp ://127.0.0.1:5000’) ;
    4. define (’COLLECTOR_ADDR’, ’tcp ://127.0.0.1:5001’) ;
    5.  
    6. class Worker {
    7.  
    8.   private $in ;
    9.   private $out ;
    10.  
    11.   public function __construct ($in_addr, $out_addr)
    12.   {
    13.     $context = new ZMQContext () ;
    14.  
    15.     $this->in = new ZMQSocket ($context, ZMQ: :SOCKET_PULL) ;
    16.     $this->in->bind ($in_addr) ;
    17.  
    18.     $this->out = new ZMQSocket ($context, ZMQ: :SOCKET_PUSH) ;
    19.     $this->out->connect ($out_addr) ;
    20.   }
    21.  
    22.   public function work () {
    23.     while ($command = $this->in->recvMulti ()) {
    24.       if (isset ($this->commands [$command [0]])) {
    25.         echo "Received work" . PHP_EOL ;
    26.  
    27.         $callback = $this->commands [$command [0]] ;
    28.  
    29.         array_shift ($command) ;
    30.         $response = call_user_func_array ($callback, $command) ;
    31.  
    32.         if (is_array ($response))
    33.           $this->out->sendMulti ($response) ;
    34.         else
    35.           $this->out->send ($response) ;
    36.       }
    37.       else {
    38.         error_log ("There is no registered worker for $command [0]") ;
    39.       }
    40.     }
    41.   }
    42.  
    43.   public function register ($command, $callback)
    44.   {
    45.     $this->commands [$command] = $callback ;
    46.   }
    47. }
    48.  ?>

    The Worker class allows us to register commands with callbacks associated with them. In our case the Worker class doesn’t actually care or know about the parameters being passed to the actual callback, it just blindly passes them on. We are using two separate sockets in this example, one for incoming work requests and one for passing the results onwards. This allows us to create a simple pipeline by adding more workers in the mix. For example we could first have a watermark worker, which takes the original image and composites a watermark on it, passes the file onwards to thumbnail worker, which then creates different sizes of thumbnails and passes the final results to event collector.

    The next part we are going to create a is a simple worker script that does the actual thumbnailing of the images :

    1. < ?php
    2. include __DIR__ . ’/common.php’ ;
    3.  
    4. // Create worker class and bind the inbound address to ’THUMBNAIL_ADDR’ and connect outbound to ’COLLECTOR_ADDR’
    5. $worker = new Worker (THUMBNAIL_ADDR, COLLECTOR_ADDR) ;
    6.  
    7. // Register our thumbnail callback, nothing special here
    8. $worker->register (’thumbnail’, function ($filename, $width, $height) {
    9.                   $info = pathinfo ($filename) ;
    10.  
    11.                   $out = sprintf ("%s/%s_%dx%d.%s",
    12.                           $info [’dirname’],
    13.                           $info [’filename’],
    14.                           $width,
    15.                           $height,
    16.                           $info [’extension’]) ;
    17.  
    18.                   $status = 1 ;
    19.                   $message = ’’ ;
    20.  
    21.                   try {
    22.                     $im = new Imagick ($filename) ;
    23.                     $im->thumbnailImage ($width, $height) ;
    24.                     $im->writeImage ($out) ;
    25.                   }
    26.                   catch (Exception $e) {
    27.                     $status = 0 ;
    28.                     $message = $e->getMessage () ;
    29.                   }
    30.  
    31.                   return array (
    32.                         ’status’  => $status,
    33.                         ’filename’ => $filename,
    34.                         ’thumbnail’ => $out,
    35.                         ’message’ => $message,
    36.                     ) ;
    37.                 }) ;
    38.  
    39. // Run the worker, will block
    40. echo "Running thumbnail worker.." . PHP_EOL ;
    41. $worker->work () ;

    As you can see from the code the thumbnail worker registers a callback for ‘thumbnail’ command. The callback does the thumbnailing based on input and returns the status, original filename and the thumbnail filename. We have connected our Workers “outbound” socket to event collector, which will receive the results from the thumbnail worker and do something with them. What the “something” is depends on you. For example you could push the response into a websocket to show immediate feeedback to the user or store the results into a database.

    Our example event collector will just do a var_dump on every event it receives from the thumbnailer :

    1. < ?php
    2. include __DIR__ . ’/common.php’ ;
    3.  
    4. $socket = new ZMQSocket (new ZMQContext (), ZMQ: :SOCKET_PULL) ;
    5. $socket->bind (COLLECTOR_ADDR) ;
    6.  
    7. echo "Waiting for events.." . PHP_EOL ;
    8. while (($message = $socket->recvMulti ())) {
    9.   var_dump ($message) ;
    10. }
    11.  ?>

    The final piece of the puzzle is the client that pumps messages into the pipeline. The client connects to the thumbnail worker, passes on filename and desired dimensions :

    1. < ?php
    2. include __DIR__ . ’/common.php’ ;
    3.  
    4. $socket = new ZMQSocket (new ZMQContext (), ZMQ: :SOCKET_PUSH) ;
    5. $socket->connect (THUMBNAIL_ADDR) ;
    6.  
    7. $socket->sendMulti (
    8.       array (
    9.         ’thumbnail’,
    10.         realpath (’./test.jpg’),
    11.         50,
    12.         50,
    13.       )
    14. ) ;
    15. echo "Sent request" . PHP_EOL ;
    16.  ?>

    After this our processing pipeline will look like this :

    simple-pipeline

    Now, if we notice that thumbnail workers or the event collectors can’t keep up with the rate of images we are pushing through we can start scaling the pipeline by adding more processes on each layer. ZeroMQ PUSH socket will automatically round-robin between all connected nodes, which makes adding more workers and event collectors simple. After adding more workers our pipeline will look like this :

    scaling-pipeline

    Using ZeroMQ also allows us to create more flexible architectures by adding forwarding devices in the middle, adding request-reply workers etc. So, the last thing to do is to run our pipeline and see the results :

    Let’s create our test image first :

    $ convert magick:rose test.jpg
    

    From the command-line run the thumbnail script :

    $ php thumbnail.php 
    Running thumbnail worker..
    

    In a separate terminal window run the event collector :

    $ php collector.php 
    Waiting for events..
    

    And finally run the client to send the thumbnail request :

    $ php client.php 
    Sent request
    $
    

    If everything went according to the plan you should now see the following output in the event collector window :

    array(4) 
      [0]=>
      string(1) "1"
      [1]=>
      string(56) "/test.jpg"
      [2]=>
      string(62) "/test_50x50.jpg"
      [3]=>
      string(0) ""
    
    

    Happy hacking !

  • Consent Mode v2 : Everything You Need to Know

    7 mai 2024, par Alex — Analytics Tips

    Confused about Consent Mode v2 and its impact on your website analytics ? You’re not the only one. 

    Google’s latest update has left many scratching their heads about data privacy and tracking. 

    In this blog, we’re getting straight to the point. We’ll break down what Consent Mode v2 is, how it works, and the impact it has.

    What is Consent Mode ?

    What exaclty is Google Consent Mode and why is there so much buzz surrounding it ? This question has been frustrating analysts and marketers worldwide since the beginning of this year. 

    Consent Mode is the solution from Google designed to manage data collection on websites in accordance with user privacy requirements.

    This mode enables website owners to customise how Google tags respond to users’ consent status for cookie usage. At its core, Consent Mode adheres to privacy regulations such as GDPR in Europe and CCPA in California, without significant loss of analytical data.

    Diagram displaying how consent mode works

    How does Consent Mode work ?

    Consent Mode operates by adjusting the behaviour of tags on a website depending on whether consent for cookie usage is provided or not. If a user does not consent to the use of analytical or advertising cookies, Google tags automatically switch to collecting a limited amount of data, ensuring privacy compliance.

    This approach allows for continued valuable insights into website traffic and user behavior, even if users opt out of most tracking cookies.

    What types of consent are available in Consent Mode ?

    As of 6 March 2024, Consent Mode v2 has become the current standard (and in terms of utilising Google Advertising Services, practically mandatory), indicating the incorporation of four consent types :

    1. ad_storage : allows for the collection and storage of data necessary for delivering personalised ads based on user actions.
    2. ad_user_data : pertains to the collection and usage of data that can be associated with the user for ad customisation and optimisation.
    3. ad_personalization : permits the use of user data for ad personalisation and providing more relevant content.
    4. analytics_storage : relates to the collection and storage of data for analytics, enabling websites to analyse user behaviour and enhance user experience.

    Additionally, in Consent Mode v2, there are two modes :

    1. Basic Consent Mode : in which Google tags are not used for personalised advertising and measurements if consent is not obtained.
    2. Advanced Consent Mode : allows Google tags to utilise anonymised data for personalised advertising campaigns and measurements, even if consent is not obtained.

    What is Consent Mode v2 ? (And how does it differ from Consent Mode v1 ?)

    Consent Mode v2 is an improved version of the original Consent Mode, offering enhanced customisation capabilities and better compliance with privacy requirements. 

    The new version introduces additional consent configuration parameters, allowing for even more precise control over which data is collected and how it’s used. The key difference between Consent Mode v2 and Consent Mode v1 lies in more granular consent management, making this tool even more flexible and powerful in safeguarding personal data.

    In Consent Mode v2, the existing markers (ad_storage and analytics_storage) are accompanied by two new markers :

    1. ad_user_data – does the user agree to their personal data being utilized for advertising purposes ?
    2. ad_personalization – does the user agree to their data being employed for remarketing ?

    In contrast to ad_storage and analytics_storage, these markers don’t directly affect how the tags operate on the site itself. 

    They serve as additional directives sent alongside the pings to Google services, indicating how user data can be utilised for advertising purposes.

    While ad_storage and analytics_storage serve as upstream qualifiers for data (determining which identifiers are sent with the pings), ad_user_data and ad_personalization serve as downstream instructions for Google services regarding data processing.

    How is the implementation of Consent Mode v2 going ?

    The implementation of Consent Mode v2 is encountering some issues and bugs (as expected). The most important thing to understand :

    1. Advanced Consent Mode v2 is essential if you have traffic and campaigns with Google Ads in the European Union.
    2. If you don’t have substantially large traffic, enabling Advanced Consent Mode v2 will likely result in a traffic drop in GA4 – because this version of consent mode (unlike the basic one) applies behavioural modelling to users who haven’t accepted the use of cookies. And modelling the behaviour requires time.

    The aspect of behavioural modelling in Consent Mode v2 implies the following : the data of users who have declined tracking options begin to be modelled using machine learning. 

    However, training the model requires a suitable data volume. As the Google’s documentation states :

    The property should collect at least 1,000 events per day with analytics_storage=’denied’ for at least 7 days. The property should have at least 1,000 daily users submitting events with analytics_storage=’granted’ for at least 7 of the previous 28 days.

    Largely due to this, the market’s response to the Consent Mode v2 implementation was mixed : many reported a significant drop in traffic in their GA4 and Google Ads reports upon enabling the Advanced mode. Essentially, a portion of the data was lost because Google’s models lacked enough data for training. 

    And from the very beginning of implementation, users regularly report about a few examples of that scenario. If your website doesn’t have enough traffic for behaviour modelling, after Consent Mode v2 switching you will face significant drop in your traffic in Google Ads and GA4 reports. There are a lot of cases of observing 90-95% drop in metrics of users and sessions.

    In a nutshell, you should be prepared for significant data losses if you are planning to switch to Google Consent Mode v2.

    How does Consent Mode v2 impact web analytics ? 

    The transition to Consent Mode v2 alters the methods of user data collection and processing. The main concerns arise from the potential loss of accuracy and completeness of analytical data due to restrictions on the use of cookies and other identifiers when user consent is absent. 

    With Google Consent Mode v2, the data of visitors who have not agreed to tracking will be modelled and may not accurately reflect your actual visitors’ behaviours and actions. So as an analyst or marketer, you will not have true insights into these visitors and the data acquired will be more generalised and less accurate.

    Google Consent Mode v2 appears to be a kind of compromise band-aid solution. 

    It tries to solve these issues by using data modelling and anonymised data collection. However, it’s critical to note that there are specific limitations inherent to the modelling mechanism.

    This complicates the analysis of visitor behavior, advertising campaigns, and website optimisation, ultimately impacting decision-making and resulting in poor website performance and marketing outcomes.

    Wrap up

    Consent Mode v2 is a mechanism of managing Google tag operations based on user consent settings. 

    It’s mandatory if you’re using Google’s advertising services, and optional (at least for Advanced mode) if you don’t advertise on Google Ads. 

    There are particular indications that this technology is unreliable from a GDPR perspective. 

    Using Google Consent Mode will inevitably lead to data losses and inaccuracies in its analysis. 

    In other words, it in some sense jeopardises your business.