Little correction:

Modify index.php, NOT view.category.php. The modifications are the same ones.

index.php, around line 92:


index.php, around line 117:

Shouldn't matter where exactly you drop it within the array. The red lines are the ones you would have to add.

Then, you can modify your template article_inc_category.html and use <{$article.source}> as a smarty variable wherever it suits you, for instance on line 70 of the template you use on your site, behind <{$article.time}>.

Now tested, no guarantees against strange behaviour down the line, don't forget to update the module every time you modify a template.

<{$article.source}> is a smarty variable that is probably not defined at that point. It's not the content of the database, but a variable that would have to be defined and populated in the corresponding php script.

It seems to me that we're talking about view.category.php here. Now, it's late at night, and I'm tired. But off the top of my hat (or head really), it looks to me like it might make sense to try out the following:

1.) Locate view.category.php line 128

and insert "art_source" after "writer_id" (that's to fetch the value from the database)

2.) Locate view.category.php around line 164:

and insert the following line wherever you like. Make sure that each but the last of the similar lines ends with a comma:

(that's to assign the value to the variable)

Now try again if you get anything to show if you drop <{$article.source}> into the template as you've done before.

Please remember that you have to update the module everytime you change a template. If you change a php script, you don't have to update the module for the change to be reflected.

This is looking onto the situation through two tired eyes and without any evidence it might work other than a very rough guess. Let me know if it works. If not, I might have a closer look at it one of these days.

Hehehe, I knew I was right and you hadn't made the changes correctly

Not sure I understand, but that's how I figure it looks more or less:

general /galleries directory for all user directories (albums)

individual /galleries/album directories for individual users.

If /galleries is chmod'd to 555, than nobody (not even you) can add or delete anything to/from that directory. That's what I understood you wanted. To be able to manipulate its contents, you'd have to chmod them to 755 and be the owner, or to 775 and be member of group, or to 777. You may not be able to chmod if you're not the owner of the directory. Owner here always being the first name when you do an ls -l

If /galleries/album directories are chmod'd to 755, then users should be able to write something to them, and to delete something inside them, but not to remove the entire directory /galleries/album, because that's protected one level up. Now, this is on the assumption that users are accessing the directory as owner (or that the first 7 applies to them), which would normally be the case only if they are owned by the user who runs the webserver. If the directories are not owned by the user who runs the webserver, then 775 or 777 might be the correct choice for the subdirectories.

In any case, 555 for /galleries/album directories should not be what you want. After all, your users are supposed to upload files to those directories, aren't they?

Quote:
Irmtfan has a package of all things needed for the article module (+ Farsi language files and tiny editor + cbb) athttp://www.irxoops.org/modules/wfdownloads/singlefile.php?lid=88. His instructions might be in Farsi

Well, you might have to see whether it works with 2.2.4 or 2.2.5. Might be a very good idea to upgrade, anyway. Or to look into how to downgrade to 2.0.16. There's a script somewhere, but I assume it's a high risk operation.

You're getting just one error, the one with the foreachq tag not being recognized, which I have a hard time attributing to anything else than to the fact that smarty doesn't find the foreachq function which is defined in compiler.foreachq.php which, you say, is now in its correct place.

All the other notices are just that: Notices and Warnings. But they shouldn't be critical. And as far as I can see, they mostly refer to some language strings not being defined correctly, that sort of stuff. I don't have that phpmyadmin for XOOPS you apparently have there, but I don't think it should interfere. The "xoops_module_header" stuff is a little odd, but I also don't think it should throw smarty off balance.

It might point to your Smarty and template handling files being outdated or corrupt, though. Perhaps, this is being solved by updating to the current versions.

Are there any other strange behaviors on your site? Is it the first time a module isn't updating correctly? Do you have some local install which you can use to test run the trouble shooting steps?

You might also want to switch on the smarty debug option in general settings, and perhaps post the output here. But that's going to be a lot of gibberish.

In any case, I hope somebody else can step in, because I'm pretty much at the end of my wits.

Wow, that's strange. Are you sure the two files are in /class/smarty/plugins ? Alongside a whole bunch of other files? You haven't made any additional subdirectory to mirror the XOOPS 2.16 file structure? Something like /class/smarty/xoops_plugins? That would be wrong!

Have you also replaced the xoops.js?

Sorry I'm insisting. But the error you're getting is rather unequivocal. The update script is specifically choking on the foreachq function which is defined in compiler.foreachq.php.

As it chokes, it doesn't read the templates into the database --> no templates to display your content --> none of your content being displayed.

Other than that, the only thing that I could imagine is that your Frameworks folder contains an old version? Can you replace the entire Frameworks directory with the newest version, not just overwrite duplicate files? Can you also make sure there're no files other than those that come with the latest article version in your /modules/article directory?

These last two suggestions would be pretty desperate and unmotivated measures. I firmly believe that the problem is with compiler.foreachq.php not being in the right location.

Oops, sorry. I think there's a little bug in phppp's instructions, at least as they're on this page. Irmtfan is actually mentioning it a few posts into comments, down that page. Try dropping compiler.includeq.php and compiler.foreachq.php into /class/smarty/plugins (one directory deeper than in the instructions).

As for the editors: It should be fine how you've done it. Each subdirectory in /class/xoopseditor corresponds to a different editor. You can just remove the ones you don't intend to use. The directory is being parsed for whatever is in there.

Quote:
Nope, hehehe. That means that you should closely follow the installation and updating instructions. What's happening? You get a critical error/abortion at
Quote:

Am I correct to infer that you're using the 2.2 branch? See whether you've dropped compiler.includeq.php and compiler.foreachq.php correctly as per instructions.

Okay, quick and dirty:

It does, indeed, seem to do the trick if you flush the variable before you use it in the form. In /modules/article/include/form.article.elements.php around line 184:



That is phppp's suggestion from here, plus an additional first line to initialize the variable (in red).

Ideally, you would read out the value from the database and preselect an element of the array accordingly, but that's too much for me now. In any case, this seems to write a correct new value to the db if one is selected, and leave the old one intact if none is selected. Don't ask me why and how, though. Let me know whether it works.

I hear your pain re our intended audiences never realizing the brilliance and usefulness of our sites. By the way: I'm getting a good chunk of all my traffic from people looking for satellite images, and I'm scoring terribly high on searches in all the LA googles for satellite images, and that's all for the googlemaps module and inspite of the fact it doesn't really have a whole lot to do with my site. Of course, most visitors just bounce off, but a good 20% seem to look at at least a second page.