Welcome to the forum Alessio.

No. The Page model depends on the Record class which is available in Framework.php... In essence you'd be loading a big part of Wolf CMS anyway.

You might get it to work, but you'll get no support with regards to bugs, etc. in that configuration. For obvious reasons. (I hope they're obvious anyway)

Anyway, in response to your original post...

Wolf CMS tries its best to let you do whatever you want in terms of design, html, css, etc... I've seen your site (very nice design ) and I believe its not very difficult to convert to Wolf CMS. As for your custom DB for your images... A model is very easily made in Wolf CMS and a plugin is also very easy (and low-effort) to make.

I'd probably write a simplistic plugin that provides a new model accessing the custom DB.

In any case, using Wolf CMS to host your site and include the custom DB is a lot less work than adapting or extracting parts of the functionality of Wolf CMS and insert them into an existing site. (which is what you're trying to do I believe?)

See the wiki and phpdocs for more details on Wolf's innards:

www.wolfcms.org/wiki/
www.wolfcms.org/phpdoc/

Undefined index means you made a coding mistake... most likely you are trying to use a field of an array that does not exist because it wasn't added or POSTed for example.

If you want to query an existing table like for example the "user" table, you can either use the model class itself (in this case "User") or the more generic Record class.

Example when using User:

$user = User::findById(1);
$user->name = "Some new name";
$user->save();

Example when using Record:

$user = Record::findByIdFrom('User', 1);
$user->name = "Some new name";
$user->save();

// Or even more directly...

$data = array(
    'name' => 'some name',
    'email' => 'some@some.com',
    'username' => 'someone',
    'language' => 'en',
    'created_on' => '2012-01-30 15:15:01',
    'updated_on' => '2012-01-30 15:15:01',
    'created_by_id' => '1',
    'updated_by_id' => '1'
);

Record::insert('User', $data);

When dealing with Wolf CMS core tables, its best to use their model classes (like "User"). When you have custom tables, its best to create a model class for them first. When you have one-off interactions with random tables, its probably best to use straight PDO at the moment.

Also see:

http://www.wolfcms.org/phpdoc/latest/
http://www.wolfcms.org/phpdoc/latest/Fr … tml#insert
http://www.wolfcms.org/phpdoc/latest/Fr … tml#update
http://www.wolfcms.org/phpdoc/latest/Fr … tml#delete

Thanks for the remarks concerning the issues. I'll make sure those work. I'm reworking the plugin anyway since its not very stable in its current form.

So in effect you're adding four lines for touch events using the new library? And modding the library to make it work?

Can't have everything I guess. Good looking site though.

One remark though: I was half expecting to be able to click on the round icons since they have a hover effect. Not sure if you should do something with that, but you could direct people to a page with some info on that subject for example.

Not a bad idea in my opinion.

As for "is it possible?":

Yes. The theme switcher is very easy to do in a plugin. The most basic version would be something like: you just use the Observer system to listen for the page_found event. Then you'd use the given $page object to replace the page's normally set Layout by the seasonal one.

One thing that might become difficult with the above is when some pages don't inherit the parent's Layout but use a custom Layout geared towards the page's content. Though I'm sure there are ways to handle that cleanly too... perhaps allow the user to setup a mapping of some sort... Normal Layout A belongs to Seasonal A1, A2, A3 and A4. Then when Normal Layout A is detected at page_found event, you'd select one of the seasonal's that was mapped to it.

The seasonal article picker could be as simple as writing a function that retrieves all articles tagged with a particular tag and randomly selecting one using PHP's random functions. Quite easy I believe.

I doubt upgrading Wolf CMS will help with your problem (though its never a bad idea to upgrade), the interface is based on HTML + JQuery + nestedSortable. The most likely culprit here is nestedSortable and/or JQuery since those are the generic components that handle user input in this case. It could also be in the bits of JS that was written specifically for Wolf CMS. We've not really tested the backend on mobile platforms like smartphones though.

Apple stuff I can't test at all since I don't have iPad, iPhone and the like.

Can you specify this a little more? SP1 is the same as 0.7.5 except for its adding some CSRF checks. How exactly did SP1 "kill your site"? I don't think it should...

An archive is actually available, we've just not linked to it. Oversight on our part, sorry.

I'll have to take a look at that...

Check if there's a space at the beginning of your file or something.

In any case, I've been contracted to fix and improve the Newsletter plugin and will be releasing it shortly.

I would not say your admin password was hacked. It was changed yes, but anyone that is able to add a htaccess file to your site can add any file, including PHP files (and later delete them) to allow them to run commands, change DB stuff etc...

I'm always interested in getting as much information about the avenues of attack that are used so I can try and close them. Either by improving Wolf CMS source code or by adding (for example) security advice to the security.php checker.

There is no way to disable a user as such. However, you could remove all roles from the user which will cause the user to lose backend access and change the user's password so they can't login anymore.

You really should've created a separate topic for this... so I split it off from the old topic.

To get to your question, what does the plugin do?

A: It automatically detects the language that is preferred by the user, using standard methods, and then automatically replaces a page's content with the content in the user's desired language if a translation was found.

So it does not... translate page names when translations are stored as parts, translate slugs or change the UI you built using a Layout.

If you choose to store translations using the "translations as page copy" option, it DOES allow translating page names. (only slugs remain untranslated)

So if you store translations as copies, it can also translate your menu if you built your menu in the correct manner.