Using regular expressions in a modification.xml...

[Arantor]

Try rewriting it thus:

Code Select Expand

<?xml version="1.0"?>
<!DOCTYPE modification SYSTEM "http://www.simplemachines.org/xml/modification">
<modification xmlns="http://www.simplemachines.org/xml/modification" xmlns:smf="http://www.simplemachines.org/">
    <id>tmarques:Mod_Skin_2009_Metodo</id>
    <type>modification</type>
    <version>0.0.1</version>
    <file name="$sourcedir/Admin.php">
         <operation>
            <search position="before"><![CDATA[// Mod Authors for a "ADD AFTER" on this line. Ensure you end your change with a comma. For example:]]></search>
            <add><![CDATA[
'mdtheme' => array($txt['mods_cat_mdtheme']),]]></add>
         </operation>
     </file>
     <file name="$sourcedir/ManageSettings.php">
         <operation>
            <search position="before"><![CDATA[// Mod authors, once again, if you have a whole section to add do it AFTER this line, and keep a comma at the end.]]></search>
            <add><![CDATA[
'mdtheme' => 'ModifyMDThemeSettings',]]></add>
         </operation>
     </file>
</modification>


Basically, if you're doing a position="before", you don't have to match the entire line, just enough to match its position, so you can completely discount the tab at the start of that block (and thus not use regexp)

Note that the ideal is to use tabs in the replacements (and not using tabs is a reason for not approving a mod), and I've replaced the leading spaces with two tabs, since IIRC that's the indentation necessary to keep it in style with the rest of the array.

[tmarques]

It doesn't work Arantor, now it all fails.
I'm remotely accessing the machine and am using Vim. I disabled expandtab, so it's just puting tabs there.
Any ideas?

Try rewriting it thus:

Code Select Expand

<?xml version="1.0"?>
<!DOCTYPE modification SYSTEM "http://www.simplemachines.org/xml/modification">
<modification xmlns="http://www.simplemachines.org/xml/modification" xmlns:smf="http://www.simplemachines.org/">
    <id>tmarques:Mod_Skin_2009_Metodo</id>
    <type>modification</type>
    <version>0.0.1</version>
    <file name="$sourcedir/Admin.php">
         <operation>
            <search position="before"><![CDATA[// Mod Authors for a "ADD AFTER" on this line. Ensure you end your change with a comma. For example:]]></search>
            <add><![CDATA[
'mdtheme' => array($txt['mods_cat_mdtheme']),]]></add>
         </operation>
     </file>
     <file name="$sourcedir/ManageSettings.php">
         <operation>
            <search position="before"><![CDATA[// Mod authors, once again, if you have a whole section to add do it AFTER this line, and keep a comma at the end.]]></search>
            <add><![CDATA[
'mdtheme' => 'ModifyMDThemeSettings',]]></add>
         </operation>
     </file>
</modification>


Basically, if you're doing a position="before", you don't have to match the entire line, just enough to match its position, so you can completely discount the tab at the start of that block (and thus not use regexp)

Note that the ideal is to use tabs in the replacements (and not using tabs is a reason for not approving a mod), and I've replaced the leading spaces with two tabs, since IIRC that's the indentation necessary to keep it in style with the rest of the array.

[Arantor]

Both operations fail? No reason they should do that.

[tmarques]

Both operations fail? No reason they should do that.

Yup. That's why I had said that I used the regular expression to make it work but only the first one did.
What's the consensus about using vim and editing the files on site? Could it be related?
I'm using SMF 2.0 RC1.2

Best regards

[Arantor]

Does vim definitely save the tabs correctly?

[tmarques]

Does vim definitely save the tabs correctly?

I think so. At least it behaved as such.
Can you take a look at the file for me?
I'll try editing it with notepad but that really isn't how I'd like to proceed from now on, as I only have windows installed on a VM and usually do all development remotely. I still have some months of work in SMF ahead of me and it would be very nice if this worked better. Do you think I can help improve this package manager "problem"?

Best regards

[Arantor]

Can you attach that package here please?

[Dannii]

Regex's shouldn't be used just for formatting like that... I think a more valid use case is for removing something from an array (like a menu item) if other things have been inserted into the array after the mod was installed.

[tmarques]

Can you attach that package here please?

Sure. I have a bit more code in the original package than the one I posted here, but I have formatted it with tabs either way. The full code is in attach.
I also had tried the boardmod format but it was even worse, allways telling me that no "Install operations defined in the package" or something like that.

Best regards

[Arantor]

Well, I note you're still using \t at the start - with what I suggested, take that out.

I would also suggest not using 2.0 RC1-1 in the package info file, as there are known issues with that (which is why RC1.2 is 1.2 not 1-2)

[tmarques]

Well, I note you're still using \t at the start - with what I suggested, take that out.

I would also suggest not using 2.0 RC1-1 in the package info file, as there are known issues with that (which is why RC1.2 is 1.2 not 1-2)

My bad, I forgot to remove the \t* on those. Did as you said right now but I'm still getting the same failed test on all of them. I also had some missing tabs in code to be added, also fixed that now.
See the attachment please.
Best regards

[Arantor]

In the actual file there is a line break between the end of the <search> and the start of the CDATA. As per XML, that's still part of the search string, because it's the contents of the search tag.

[tmarques]

In the actual file there is a line break between the end of the <search> and the start of the CDATA. As per XML, that's still part of the search string, because it's the contents of the search tag.

Thanks Arantor, that fixed it. This completely screws up formatting of the XML, which is very unfortunate, since it becomes a bit of a hindrance to maintain mods.
Are there any plans to fix this?

[Arantor]

Not really because it's not fixable by definition. It is following the schema precisely; find the contents of <search> and add in the content for <add>. <![CDATA[ as per XML specification simply says that the data in it should not be parsed by the XML parser, so you don't have entity issues. I would note that this is inherited from the original SGML specification which is now decades old.

How would you change it without it not being XML?

The fact is, unless you either have a modified XML parser (meaning that those of us that use XML generation tools will have to modify them too) or you don't use XML at all, it is unavoidable.

[Dannii]

How does it screw up the formatting??

[tmarques]

Not really because it's not fixable by definition. It is following the schema precisely; find the contents of <search> and add in the content for <add>. <![CDATA[ as per XML specification simply says that the data in it should not be parsed by the XML parser, so you don't have entity issues. I would note that this is inherited from the original SGML specification which is now decades old.

How would you change it without it not being XML?

The fact is, unless you either have a modified XML parser (meaning that those of us that use XML generation tools will have to modify them too) or you don't use XML at all, it is unavoidable.

I see, I have no idea about XML, that was why I was asking. I was suggesting that we do as we like inside the CDATA, and then SMF would take care of it, independent of the leading spaces or tabs, something like that. I don't know much about parsing, so I don't know if this is something feasible to implement, I'm just saying after looking at the parsing code that uses just tabs.
If there isn't any easy fix, guess I have to live with it.
Thanks for everything.

Best regards

[tmarques]

How does it screw up the formatting??

I was referring to readability of the code after. The mod was a lot "cleaner" when I had the code I indented my way but that didn't work.

[Arantor]

Do you mean the readability of the mod's XML file, or the readability of the code injected into the source files? The two are quite different, the latter is vastly easier to deal with since you as mod author have the ability to manage that.

[Dannii]

I was referring to readability of the code after. The mod was a lot "cleaner" when I had the code I indented my way but that didn't work.

Didn't look clean to me... you have the search and add tags at the same level as the operations etc.

[tmarques]

I was referring to readability of the code after. The mod was a lot "cleaner" when I had the code I indented my way but that didn't work.

Didn't look clean to me... you have the search and add tags at the same level as the operations etc.

I know, it was kind of misaligned but was more readable to me. I still have a lot to learn when it comes to indent code, especially on something I haven't had much experience with :/