[RFC|Rejected] MODX 2.0

[igorw]

I've posted a topic for MOD authors on phpBB.com to get some more input: http://www.phpbb.com/community/viewtopi ... &t=2092788

[RMcGirr83]

the name of the folder in the archive should be mod_name-1.0.0

How would Automod treat revisions to mods if this naming convention is used?

EG, let's say I have a zip called mod_name-1.0.0.zip and within it a directory mod_name, if I make a new revision mod_name-1.0.1.zip with the same directory mod_name but a different version number, what does automod do with that. Treat it as a new mod or overwrite the already existing and installed mod (this assumes one is using the FTP upload feature of Automod as opposed to the user doing it manually)? What would occur if it was mod_name-1.0.0 and mod_name-1.0.1?

[igorw]

The folder name also contains the version to prevent naming clashes. Ideally AutoMOD would detect that it's an update of an already installed MOD and use the supplied update instructions.

[keith10456]

Changes to file layout and naming conventions

The name of the archive should be mod_name-1.0.0.zip, the name of the folder in the archive should be mod_name-1.0.0. This prevents conflicts when extracting.

Here's an example directory structure:

• mod_name-1.0.0.zip
  • mod_name-1.0.0/
    • root/
      represents the board root, contains included files
    • info.xml
      mod info
    • changes.xml
      mod changes
    • update/
      mod version updates
      • update-1.0.1-rc1_1.0.1.xml
    • extra/
      extra language and style files
      • lang-de_x_sie.xml
      • style-prosilver.xml
      • style-prosilver-de_x_sie.xml
    • contrib/
      user-provided documentation and other random stuff

The "root/" folder will contain all files, also those of additional styles and languages. AutoMOD can only install those that are needed. The same applies to users, copying unused language files doesn't do any harm.

Often it's the small things that make a huge difference.

Great idea!!!

[Jhong]

Hi,

I posted a fairly detailed response on the forum in the initial Q&A thread -- upshot was basically that manual code edits should go the way of the dinosaurs and as such MODX wasn't so important in the grand scheme of things. (energy better spent on new hooks and filters).

However, in the interim, I'd find the following really useful:

1. An ability to package the "MODX packagage" as a single installation step in a larger process. The current packaging guidelines are too strict to allow for this. For example, step 1 could be "install software A" (or even "install phpBB"), then step 2 would be to deploy the MOD itself (and read the MODX file at this stage).

The easy way to get this to happen is to simply relax the packaging guidelines -- allow other content in the root folder, or the root folder to be a subfolder itself.

2. In terms of dependencies, I think the ability to specify them has the potential to be very useful. However, more useful than dependencies is exclusions -- i.e. this MOD will *NOT* work with x,y,z. I think several MODs would benefit from this. As you say, in order for this to work, you need a consistent naming system -- I like the idea of Java-like syntax for this.

This idea could even be expanded further -- you could specify code that exists in particular files. If it is found then the installation cannot proceed.

3. Ability to view MODX on the server. Perhaps this exists now, but it doesn't work for me, despite uploading the xml and xsl files. This would go some way to solving #1 above as I could link to installation packages and instructions during a wider install process.

John

[igorw]

1. An ability to package the "MODX packagage" as a single installation step in a larger process. The current packaging guidelines are too strict to allow for this. For example, step 1 could be "install software A" (or even "install phpBB"), then step 2 would be to deploy the MOD itself (and read the MODX file at this stage).

Mind to elaborate? One of the goals of the strict packaging was to make the information more useful for machines, easier parsing and semantics.

3. Ability to view MODX on the server. Perhaps this exists now, but it doesn't work for me, despite uploading the xml and xsl files. This would go some way to solving #1 above as I could link to installation packages and instructions during a wider install process.

I don't see why this wouldn't work. I've done it often.

[Jhong]

1. An ability to package the "MODX packagage" as a single installation step in a larger process. The current packaging guidelines are too strict to allow for this. For example, step 1 could be "install software A" (or even "install phpBB"), then step 2 would be to deploy the MOD itself (and read the MODX file at this stage).

Mind to elaborate? One of the goals of the strict packaging was to make the information more useful for machines, easier parsing and semantics.

Yup -- wp-united. To date it's been a 100% phpBB MOD -- once the MOD is installed it auto copies over wordpress plugin files into the wordpress install, so for the most part a phpBB MODX package worked for the purpose.

However I've had a change of heart -- I want to package it as a wordpress plugin instead. So users will download the plugin to their wordpress install, and part of the install will be a small phpBB MOD. (Ultimately I'm looking at pre-mods or patching on the fly, but will also retain the option to manually install a MOD).

So my dilemma is: how to package this? I guess I can package the phpBB MOD portion as a zip file sitting inside the plugin package, but that's not ideal -- it means extra packaging work as I will want to work on the source (in version control) in an uncompressed tree. WordPress can auto-package plugins from its SVN server...so zip files just add pain.

I imagine there are other circumstances where it would make sense to have other folders above root, or -- more likely -- folders with more striking names than "extra" or "contrib". The more flexible structure would also allow me to submit it to the phpBB MODDB when the time comes too.

John

[igorw]

Quick note, WP-specific code could be put in the contrib folder.

[Jhong]

Yep, I know that -- that's not going to cut it for me though. "contrib" hardly reflects what will be over 50% of the downloaded package. Even just renaming it to "non-phpbb/" would be better, but "contrib/" is not a good name -- kindof the entire point of the request.

[sajaki]

With 3.0 I'm having a hard time recalling a single mod that depends on another mod. Do such even exist? This is a perfect example where mod authors should be asked whether they would like to be able to depend on other mods.

Yes they exist. all the plugins of my main mod are implemented as MODX, and depend on it. :

They modify a constants file, like this :

Code: Select all

<open src="includes/bbdkp/constants_bbdkp.php"> 
 <edit> 
 <comment lang="en">adding required constants to bbdkp constants</comment>  
 <find><![CDATA[// APPLY]]></find> 
 <action type="after-add"><![CDATA[  
 define('APPTEMPLATE_TABLE', $bbdkp_table_prefixx . 'apptemplate'); 
 ]]></action> 
 </edit> 
 </open> 
 

So they "depend" on the main mod being there. so i make use of the dependency tag.

Code: Select all

<link-group> 
 <link type="dependency" lang="en-gb" href="http://www.bbdkp.com/viewtopic.php?f=2&t=1320">bbDKP 1.1</link> 
 <link type="dependency" lang="en-gb" href="http://www.bbdkp.com/viewtopic.php?f=2&t=1306">bbTips 0.3.6</link> 
 <link type="template" lang="en-gb" href="contrib/subsilver2.xml">Manual for subsilver2 Style</link> 
 </link-group>  
 

Also i have plugins (apply mod) that depend on another mod (bbtips) that implements a custom bbcode.

http://code.google.com/p/bbdkp/source/b ... 10/plugins

I need to follow this way of working because i can't possibly stuff all desired functionality in one mod.

however none of these have made it to the mod db yet.