Checking Requirements of Addons

[Ralf (Berlin)]

Addons may have special requirements, i.e. PHP 5.2.1 or they need an installed extension like gd, need a PEAR module or they are depending on the abilities of other modules a.s.o..

For this reason it will be usefull to check the requirements of an addon before installation with the target to prompt the user for missing system configurations and to avoid unattractive error messages...

Aldus has developed a practical producedure to check the requirements of addons.

All you have to do, is to add the require.php to your module and to declare the requirements of your module at the end of your info.php:

Code:

<?php
$module_require = array (
    'PHPVERSION'    => "5.2.1",
    
    'WB_VERSION'    => "2.7",
    
    'MODULES'        => array (
        'xFastTemplate2'    => "0.1.1",
        'x_cForm'            => "0.1.3",
        'x_find_class'        => "0.1.7.1" )
);

require_once ("require.php");
?>

Because WB is unzipping the module and accessing the info.php the require.php at the end of the info.php will be executed before the module is installed.

The require.php performs checks the requirements, defined by the $module_require array. In case of misconfiguration or missing a needed module, the require.php removes the temporary files and stop the installation by calling $admin->print_error(); otherwise the installationscript is running as usual...

At the moment the attached require.php is still under development, please test it and help us to bring it to the top 

Regards
Ralf

[Ruud]

I don't get it.. (great idea though)

A few things don't match.

1. The info.php should have the standard info for WB. Otherwise it will not install.
2. The attached zip is a snippet module, there is no require.php to "require_once()".

Did you attach the right stuff?

Some questions that come up:

1. Where is the GUID to use coming from?
2. Where is the GUID used?
3. The guid has no common guid format? Is there a reason?
4. What happens if the "require" module is not installed? Will my module install anyway?

Ruud

[Ralf (Berlin)]

@Ruud

The attached zip is a snippet module, there is no require.php to "require_once()"

please apologize for the inconvience, this was my fault  - for developing purpose we have put the require.php as include.php into a snippet an I have posted this snippet, sorry, I have corrected it...

1. Where is the GUID to use coming from?

The GUID is discussed in another thread (german), I have removed it to avoid misunderstanding.

4. What happens if the "require" module is not installed? Will my module install anyway?

At the moment you may deliver the require.php as additional file within your module - our target is to have the require.php with the next WB as part of core or as standard module which is always available.

Sorry again for the inconvience, it would be great if you want to participate at the development of the require.php.

Regards
Ralf


 

[doc]

Hello Ralf,

the module requirements check will be implemented into the WB core once the procedure is sufficently tested. Will replace some of my module on the Addons repository during this week to include the requirements check so we can gain some more information.

For sure, Aldus and yourself have done a great job on that.

Regards Christian

[aldus]

Hello

Here the "alpha" of the modul for more testings. The "require.php" is still the same, but
now we've got additional language-files-support (EN, DE). As for the testing itself
imho a simple "if file_exists" before the "require_once" could keep the installation-prozess on.

Edit
As for the GUID you can use a Code2 Page in WB and place

Code:

<?php
echo "my guid: ".exec ('uuidgen');

inside to generade a valid guid for your modul.

Regards
Aldus

[erpe]

Hi,

Aldus has implemented the GUID at AMASP into the module information
On those pages where no  GUID is shown, you are able to create one in the backend and copy and paste the GUID into the backend and save that number only one time, than it is not changable.
Please don't forget to put the following part into the  php.info of your module (including the home and the GUID)

Code:

$module_home        = '';
$module_guid        = '';

rgds

erpe

[doc]

When running PHP5, one can use the following statement to create a GUID.

Code:

<?php
echo 'my GUID: ' . com_create_guid();
?>

Regards Christian

[Ralf (Berlin)]

Code:

<?php
echo 'my GUID: ' . com_create_guid();
?>

The COM extension isl only under Windows (XAMPP) available.

Under *nix you may use the following function:

Code:

<?php
/**
 * Generate a globally unique identifier (GUID)
 * Uses COM extension under Windows otherwise
 * create a random GUID in the same style
 */
public function createGUID() {
  if (function_exists('com_create_guid')){
   return com_create_guid(); }
  else {
    return sprintf( '%04x%04x-%04x-%04x-%04x-%04x%04x%04x',
    mt_rand( 0, 0xffff ), mt_rand( 0, 0xffff ), mt_rand( 0, 0xffff ),
    mt_rand( 0, 0x0fff ) | 0x4000,
    mt_rand( 0, 0x3fff ) | 0x8000,
    mt_rand( 0, 0xffff ), mt_rand( 0, 0xffff ), mt_rand( 0, 0xffff ) );
  }
} // createGUID()
?>

Regards
Ralf

[erpe]

Or simply use this link to create a GUID

rgds

erpe

[Argos]

Nice idea, but it would be far more useful when compatible with PHP4 instead of 5.

[erpe]

But as announced on the offical pages:
wb 2.7 is the last to work with php4, so why don't look forward?

rgds

erpe

[Argos]

But as announced on the offical pages:
wb 2.7 is the last to work with php4, so why don't look forward?

The answer is in your reply: all existing versions work with PHP4, so why not make sure all modules are as compatible as possible with all WB versions? I don't have a clue if this module needs PHP5.2 itself, but if not, it would be better to make it backwards compatible. There are still lots of people that use PHP4 and also older WB versions are still in use (most of my own client sites are pre-WB2.7, as I don't update them if not absolutely needed). It wouldn't surprise me if the combination PHP4/pre-WB2.7 would be even the most common setting among WB users.

[Ruud]

The idea is that there will be a require module/tool/framework-include that will do the checking.
Not only for PHP5, but also other modules/snippets that the new module relies on.

The example in the first post just missed one line:

Code:

if (file_exists ( "require.php" ))
  require_once ("require.php");

Now the module will install on older versions too.

Implementing something like this has to start somewhere.
Old modules will not use it, old WB versions will not use it.

When both the platform and the module uses this, it will be a great addition. No more problems with modules that are not working but did install without any error or warning.

Ruud

[thorn]

Hello,

But as announced on the offical pages:
wb 2.7 is the last to work with php4, so why don't look forward?

i don't agree with that.
While releasing 2.7 we^* didn't realise that there could be another major version after 2.7 - we thought WB 3.0 would be released a few month later.
So,  whoever wrote this piece of text

WebsiteBaker 2.7 will be the last major update to the 2.x series with a minimum requirement for PHP 4.1.0.

just made the same mistake. (In my opinion)

The intention and the agreement was to keep a php4 compatible version (WB2.x) alongside Ryan's php5-only WB3.x.

I don't see a need for a php5-only WB2.x -- and i don't want it.

thorn.

we^*: doc, ruebenwurzel, myself, and a lot more, who make wb2.7 happen.

[BerndJM]

O.k.
PHP4 is "outdated" but in which mind?
In the mind of these people who think straight forward. But what's the reality?
There are so many hosters around which use already older versions of PHP and/or MySQL, much more as we could think about.
So I think a backward compatibility to PHP4 should be given at minimum for the rest of the 2.x releases.

BerndJM

[Ralf (Berlin)]

PHP4 is "outdated" but in which mind?

I don't see a need for a php5-only WB2.x -- and i don't want it.

Endless discussions and always step back instead looking forward.

ok - it's now finished for me, I'm not coding for PHP 4.

Good luck for you.

Regards Ralf

[Stefek]

Sorry, maybe I am not well informed about 'endless discussions' but I would like to know about the pro & contras by following a fully PHP5 oriented developement.

What is the subject all about?
Are you talking about the whole WB CMS or about some new Modules?
Is the case, that some new Modules won't be possible if the whole CMS is not 100% PHP5 oriented?

I can't understand either one of you - Ralf and Thorn.

At the other hand: what are the benefits in keeping the PHP4 orientation alive?
I know that some of my clients installations are running on PHP4 - but in the most cases I will make no big changes on those installations and new installations are -today - almost everywhere possible with PHP5.

When you want to rewrite the whole thingy on PHP5 - so what will happen to all the modules?
Will there be a need to rewrite them too?

I don't know about the differences between the "languages" 4 vs. 5

And at all - I don't understand if you are "discussing" about Modules or the Core.

I like the Idea of checking requirements for Modules (environment and further addons, snippets) before installing.

I also like the Idea to have future oriented tool for the requirements for designers and developers depends on tools.

I only know that you both - Thorn and Ralf - has done a lot good things for WB.
Even without any leadership of the WB Project at this time you are looking forward and still creative - thats impressive for me.

all existing versions work with PHP4, so why not make sure all modules are as compatible as possible with all WB versions? I don't have a clue if this module needs PHP5.2 itself, but if not, it would be better to make it backwards compatible. There are still lots of people that use PHP4 and also older WB versions are still in use (most of my own client sites are pre-WB2.7, as I don't update them if not absolutely needed).

I fully agree with Argos. "why not make sure all modules are as compatible as possible with all WB versions?"

I can see that PHP4 is outdated.
But maybe there is some overseen reason by Thorn by trying to keep as much compatibility as possible?

OK, hier auf Deutsch (ist ja nicht meine stärkste Ausdrucksweise, English, bekantlich):
Ich kann sehen, dass die Jahre ins Land ziehen und PHP4 Zeiten vorüberziehen.
Aber ich denke auch, dass Thorn einen guten Grund dafür haben wird, an seiner Einstellung festzuhalten, nicht NUR für PHP5 zu programmieren.

I don't see a need for a php5-only WB2.x -- and i don't want it.

Best Regards,
Stefek

[Ralf (Berlin)]

If you dont know the differences between PHP4, PHP5 and PHP6 please look at php.net or use Wikipedia or Google.

Saying we keep WebsiteBaker compatible to PHP4 means: we don't allow any PHP5 code.

Saying, the platform of WebsiteBaker 2.8x is PHP5 means: you need a server running PHP5, but it is no problem to have parts of the core or addons written in PHP4.

Saying: "I have running a server with PHP4 and WB 2.6 and it works fine, so I don't need to update to WB 2.7." It's ok, never touch a well running system. But please don't say: "You must grant that all new WB versions and addons are compatible to my sweet WB 2.6".

But exactly this happens, so I think its time to say goodbye and find another way.

Regards
Ralf

[Stefek]

Saying, the platform of WebsiteBaker 2.8x is PHP5 means: you need a server running PHP5, but it is no problem to have parts of the core or addons written in PHP4.

Thank you Ralf.
So thats the reason for the update checker. Good idea, obviously.

But please don't say: "You must grant that all new WB versions and addons are compatible to my sweet WB 2.6".

It wasn't me   

I only share this opinion:
"why not make sure all modules are as compatible as possible with all WB versions?"
But I also see that new modules won't do that.
I am willing to adjust my opinion in something which sounds like this:
"why not make sure that as much modules as possible are compatible with all WB versions?"
But I don't really care about 2.6

My biggest problem is to upgrade a running installation from 2.7 PHP4 to  >2.7 with a need for PHP5.
But as I stated above, there is not a big amount of Installations I will need to do so (cause they are running).

But there is one addition to this - and this is a problem (not only at the websitebaker.org addons page but also at the AMASP: There is no option to choose the Module depending on the WB Version. Older Modules are out of sight and one has to upgrade the whole CMS in order to use them.
I think if there was some attempt to bring more clarity into this, more people wouldn't be affraid about future Versions.

Regards,
Stefek

^{P.S: OK, der letzte Absatz war ein wenig am Thema vorbei und eher ein "Selbstgespräch".
Aber es ist heute wirklich schwierig Module für 2.6.5 zu finden, obwohl sie seinerzeit gegeben hatte.
Es wäre angebracht bestimmte Module einzufreezen (mit offener Hintertür für Bugfixes); entsprechend der Version. Und sie dann für die nächste Version in der Entwicklung fortzusetzen.}

[ruebenwurzel]

Hello,

so here a final statement from me.

WB 2.8 will definately use technics wich are only available in PHP5.

This means:
The installer and the upgrade-script will check if php5 is available. In the badest case, install and upgrade will not be possible if the server has no PHP5. In the best case it will install and upgrade but all new features wich require PHP5 will not be available. This depends from the final WB 2.8 version and if it is possible to have it run without some new features.

This means not:
That the developper must use PHP5. All addons and features can furthermore be written in lower PHP versions.

Hope this makes things clearer

Matthias

[Argos]

Thanks Matthias, that nicely rounds up this little discussion. When I posted my remark about being as compatible possible with all WB versions and PHP4, I meant that as a proposal. It's just nice to be backwards compatible. But I also see that moving forward sometimes means that this ideal cannot be reached. Personally I have no problems with that. When someone decides to code for PHP5.2 only, that's his good right.

It would be nice though to have the modules requirements checking module be compatible with as much as WB and PHP versions as possible, because of the nature of the module. It would be silly to need PHP5.2 to check if modules are PHP4 compatible... 

[Stefek]

..so here a final statement from me.

WB 2.8 will definately use technics wich are only available in PHP5.

This means:
The installer and the upgrade-script will check if php5 is available. In the badest case, install and upgrade will not be possible if the server has no PHP5. In the best case it will install and upgrade but all new features wich require PHP5 will not be available. This depends from the final WB 2.8 version and if it is possible to have it run without some new features.

This means not:
That the developper must use PHP5. All addons and features can furthermore be written in lower PHP versions.

Hope this makes things clearer

Thanks Matthias.

I think this is a road to go for WB CMS. But let me follow up the last replies.

We have this "different" meanings:

I don't see a need for a php5-only WB2.x -- and i don't want it. - Thorn

O.k.
PHP4 is "outdated" but in which mind?
In the mind of these people who think straight forward. But what's the reality?
There are so many hosters around which use already older versions of PHP and/or MySQL, much more as we could think about.
So I think a backward compatibility to PHP4 should be given at minimum for the rest of the 2.x releases. - BerndJM[/i]

Saying we keep WebsiteBaker compatible to PHP4 means: we don't allow any PHP5 code.
Saying, the platform of WebsiteBaker 2.8x is PHP5 means: you need a server running PHP5, but it is no problem to have parts of the core or addons written in PHP4. - Ralf (Berlin)

WB 2.8 will definately use technics wich are only available in PHP5. Matthias

So let give me a small hint:
Almost all the Modules and Techniques used so far, all the improvements done in the last month are still compatible on PHP4 Servers. Also the new Droplets Palette (as Module, I am not shure about someof the droplets coming) and also the Outputfilter.

At the other hand there is an attampt and a need for WB Developers and the entire System to look forward.
I agree with this - I was communicating with Ralf (Berlin) about his featurerich Modules and I know that these things are not possible with PHP4.

Let me be clear: There should be a Steps in between, before "implanting" a fully PHP5 Orientation for websitebaker. If you give it the Name "WB 3", good - the Confusion will calm up, because this was the original Statement by Ryan ("WB 3 will be PHP5.x only").
But we have a lot of Contributions and Additions in the last year that it was a waste to make this BIG STEP forward at once.
Consider another 2.x Version in between. Clean the WB 2.7 up in means of PHP4 Compatibility: Everybody wins in doing so.
- websitebaker2 is improved in usability
- Folks runniing 2.x will benefit from the new (mostly PHP4 compatible) features which are now Part of the SVN
- Such a Release can be put together in means of weeks/months
- No matter what you do with thenext Version, if there will be to much changes, so the HELP Documantation should be reworked and be available for both - so whith the last WB 2.x the Documantation will be adjusted (which is now outdated since 2.6.7)

- by doing so you will be able to set a final goal for WB 2.x thus giving you free attention for the BIG step WB3. You will not have the need to limit your Ideas for downwards compatibility, because everybody seemed to agree with "WB 3 will be PHP5.x only"
- no need to be to "carefully" innot overwhelming newbees with the Featurerichness of WB3.

I am sure that you will need some time in order to put the WB3 - PHP5 only Package together. I can imagine that there is a lot of discussions, pro&contras.
So just put a Version in between.
Make the last 2.x Version a nice rounded up Application (DE - "Abschlußwerkstück").
And a lot of confusion will be "removed" from the "roadmap".

There is also a advantage in it for the Marketing of WB.
Because the "in between" Release wouldn't take too long to put it together, we can rework the websitebaker.org Site quickly, rework the helppages for it and get attantion from outside.
I have done a lot "homework" for this task and I am sure that a lot of users will help me with the "Marketing/Design" Part as I have seen volunteer voices in the last time. The only reason I am not active at the "Marketing/Design" at this moment in time is the fact, that you need a product for this (and we decided to make the next WB Projekt Page Relaunch with a new WB Release).

As I said, the roadmap for the Marketing is done. But every Marketing and also Design Attempt is in need of a clear Purpose (and nature) of the Product. So this two things (Developement & Marketing) depends on each other if you really are about to make an impact.

We have a nice Package WB 2.x, let us put the rest of the PHP4 Compatible Parts together, give the Produkt a slightly more modern look, let's rework the Project Pages and we are done with this endless discussion.

And the WB 3 / PHP5 developers has also advantages - because at this point they are really aware about where they are and can see the future road much better.

So everybody will win with this option. No one will feel ignored or invalidated and we will get what we need:
1) Future Orientation with WB3
2) A final WB 2.x with more features (there are some really good once at the SVN and still possible with PHP4)

Feedback appraciated.

Regards,
Stefek

[ruebenwurzel]

Dear stefek,

please recognize that we don't discuss over this. The decision for PHP5 is already made last year. Please read on our startpage this here.

Thanks

Matthias

[Stefek]

Dear Matthias.

But if one didn't learn from the past, one will also have problems in the future   

Discussion where done for a different Idea.

http://start.websitebaker2.org/en/gophp5.html   date=30.dec.2008 16:45
WebsiteBaker 3 is starting full-time development in February 2008, and as of February 5th 2008 there will not be any more 2.x "minor"/feature releases on basis of PHP 4. However, basic bug fixes and security fixes will be supported for 2.7.x users.

// Edit: it was a waste of capabilities not putting the last PHP4 things together into a 2.7.x . Such a package would cost just weeks.

So stop - please - making communication impossible.
Because not every Communication == Tiring Discussion. For example: I didn't know a lot of factors which now are clear for me.

And as I remember we both talked about the possibility for a "in between" Release. Why don't talk about this?
A small minor release makes the Additions and Contributions available also for PHP4 environments.
Please consider this option. There are some good ones at the SVN 


// As I know you are not a Developer: Please let also the Developers reply on this idea/option.
Wy wasting capabilities?
The Future of WebsiteBaker is important to all of us. 

Regards,
Stefek

[thorn]

Hello,

WB 2.8 will definately use technics wich are only available in PHP5.

The decision for PHP5 is already made last year.

Oh, so i must been mistaken in what was said (or what I understand) once a year ago.
I'm not interested in being part of the (core-)Development-Team anymore under these circumstances.

Nevertheless, I will remain in the Addons-Team to keep my addons up-to-date.

thorn.