1
pstrasma
Re: Xoops blog abilities versus MovableType
  • 2004/1/7 7:20

  • pstrasma

  • Just popping in

  • Posts: 24

  • Since: 2003/12/23


I too am running both a small Movable Type community (3 blogs) and a XOOPS community (not blogging-oriented though). And I agree with Jackobo's comments.

With Movable Type, one danger is that you can quickly run into quite a bit of complexity with multiple blogs all running their own templates. Yes, you can fix that by restricting the blogs to a few central template files / style-sheets, but then you lose the custimizability that is one of the best parts of MT. The upside I see in MT is the straightforward way you can configure each blog with it's own URL and then lock down users so they can't mess with the internals / templates / etc... Plug-in wise, you'd probably want to consider at least mt-blacklist for spam and the permalinks hack to work around the way MT numbers articles in numerical sequence without regard to which blog is publishing it.

Running out of Xoops, I think you'd have to use both the WeBLog module and the one that lets you setup run multiple virtual hosts on a single installation. No experience with either of those tools, but I'm sure it could be done although I wonder how the backend.php RSS generator would handle it. The advantages I see with using XOOPS are the simplicity of offering blog owners & viewers) different themes using the built-in theme block and the ability to add many non-blog features.

Something you might want to investigate before making your decision is SixApart's product development plans. I recall reading somewhere that the two next big products after TypePad were 1) MT Pro, adding in the photo blogs & simplifying templates / styles & 2) Hosted TypePad for resellers. The later would seem to be ideal for your situation, maybe you can convince them to let you beta?



2
pstrasma
Re: Gallery with working Xoops search?
  • 2003/12/30 7:04

  • pstrasma

  • Just popping in

  • Posts: 24

  • Since: 2003/12/23


Just looking to grab the captions and descriptions. I'm setting up an alumni site and it would be nice to have a search on a person's name hit both the forums (used for class notes) and the gallery (for photos).

And nope, I don't see anything useful in the xoopsgallery_image table



3
pstrasma
Re: make it into a module?
  • 2003/12/30 7:00

  • pstrasma

  • Just popping in

  • Posts: 24

  • Since: 2003/12/23


Personally, I think the advatage of this particular solution is that is is pure and simple HTML (ok, a tad of JS). For simple needs, it lets one rely on PayPal for the heavy lifting. For more, go with osCommerce.

So just take the sample form & script and embed it in your favorite module, block, template, etc... The possibilities are endless. Want to tie it to the XOOPS user profile? No sweat, just drop in the XOOPS variable for the user-email and pass it as a hidden input to the form.



4
pstrasma
Re: Uploading avatars....
  • 2003/12/30 6:50

  • pstrasma

  • Just popping in

  • Posts: 24

  • Since: 2003/12/23


I felt a bit silly doing it, but I ended up just doing a copy / paste from a simple directory listing of filenames into an Excel spreadsheet. Then it was a simple forumula to create the SQL insert commands. Another copy/paste into myPHPadmin and all set to go.

And if you want, you can put the system avatars in a subdirectory of uploads. Just put the filename in the database as "subdir/filename.gif" Works like a charm and keeps everything neat.



5
pstrasma
Re: existing avator overwrire by user upload avator image
  • 2003/12/29 5:24

  • pstrasma

  • Just popping in

  • Posts: 24

  • Since: 2003/12/23


I've experienced the same problem when a user changes from a system avatar. The Avatar file previously in use by the user is deleted if the user A) uploads a custom Avatar, B) changes to a different system Avatar, or C) just selects no Avatar.

Just tested this with a brand-new user. Both the xoops_avatars record and the file are being deleted! This occurs even if another user has the same Avatar selected.

Ouch!



6
pstrasma
Re: This is a shopping cart script functional with wfsections
  • 2003/12/29 5:11

  • pstrasma

  • Just popping in

  • Posts: 24

  • Since: 2003/12/23


Great to see your implementation JackJ. After looking at your script, I made a few tweaks to my prior implementation and solved the strange window.open script behavior. Sample cart here, no longer requiring an IFRAME.

For a simple alternative paypal cart, just create a form with the following script:
<SCRIPT LANGUAGE=JAVASCRIPT TYPE="TEXT/JAVASCRIPT">
function 
openWin() {
l=(screen.width-525)/2
t
=(screen.height-300)/2
a
=window.open('','paypal','width=525,height=300,left='+l+',top='+t);
}
SCRIPT>

<
form target="paypal" action="https://www.paypal.com/cgi-bin/webscr" method="post" onSubmit="paypal=openWin();paypal.focus();">

<
input type="image" src="https://www.paypal.com/en_US/i/btn/x-click-but22.gif" border="0" name="submit" alt="Submit via PayPal" align="texttop" width="87" height="23">https://www.paypal.com/en_US/i/btn/x-click-but22.gif"
border="0" name="submit" alt="Submit via PayPal"
align="texttop" width="87" height="23">
<
input type="hidden" name="cmd" value="_cart">
<
input type="hidden" name="business" value="YOUREMAILHERE@DOMAIN">
<
input type="hidden" name="item_name" value="ITEM NAME">
<
input type="hidden" name="amount" value="PRICE">

FORM>


You can add a few more hidden inputs to document item options, currency, etc... There are also more buttons and a similar View Cart form available with full details at the PayPal merchant web cart site. I recommend you download the PDF manual and code your own forms as these offer many more options than their online HTML creation tool. It can be helpful to see some system-generated examples though.



7
pstrasma
Re: Odd javascript window.open behavior
  • 2003/12/28 5:09

  • pstrasma

  • Just popping in

  • Posts: 24

  • Since: 2003/12/23


Solved the problem! Live PayPal cart now embedded in WF-Sections here.

Solution was to change the OpenWin function from an OnClick in the submit button tag to an OnSubmit in the form tag. I also deleted the time delay -- can't even recall why that was needed originally. Current working code follows:

<SCRIPT LANGUAGE=JAVASCRIPT TYPE="TEXT/JAVASCRIPT">
function 
openWin() {
l=(screen.width-525)/2
t
=(screen.height-300)/2
a
=window.open('','paypal','width=525,height=300,left='+l+',top='+t);
}
SCRIPT>

<
form target="paypal" action="https://www.paypal.com/cgi-bin/webscr" method="post" onSubmit="paypal=openWin();paypal.focus();">

<
input type="image" src="https://www.paypal.com/en_US/i/btn/x-click-but22.gif" border="0" name="submit" alt="Submit via PayPal" align="texttop" width="87" height="23">https://www.paypal.com/en_US/i/btn/x-click-but22.gif"
border="0" name="submit" alt="Submit via PayPal"
align="texttop" width="87" height="23"
onClick="openWin()">
FORM>



8
pstrasma
Re: Odd javascript window.open behavior
  • 2003/12/28 5:06

  • pstrasma

  • Just popping in

  • Posts: 24

  • Since: 2003/12/23


Thought I'd tried that approach, but you never know...

This time around with the copy/pasted code, the behavior improved somewhat. Basically what happens now is that the script opens the new window and very briefly displays the Paypal cart as desired. Then it switches back to a XOOPS site submission, redisplaying the form again in the small window. If I use the browser back in the pop-up window, it nicely goes back to the shoppping cart.

The change in behavior might also have something to do with the auto-login hack I applied before going back to this wf-sections issue.

So any ideas on this more isolated problem of the second page request occuring in the module-based page vs. the stand-alone page?

Thanks in advance!



9
pstrasma
Re: Odd javascript window.open behavior
  • 2003/12/27 16:14

  • pstrasma

  • Just popping in

  • Posts: 24

  • Since: 2003/12/23


Ah, good call on those permissions. I'll open that up for the time being.

And thanks for the Framebrowser reference. It is helpful to see how others have tackled this problem. One still wonders what XOOPS is doing to mess with the target window...



10
pstrasma
Odd javascript window.open behavior
  • 2003/12/27 7:34

  • pstrasma

  • Just popping in

  • Posts: 24

  • Since: 2003/12/23


I am attempting to embed a HTML registration form as a content page. When submitted, this form opens up a new window to a Paypal shopping cart. Unfortunately, although I the page works perfectly when served as a straight HTML page, it changes behavior when put in as a XOOPS page in either TinyContent or WF-Sections. Instead of showing the proper paypal page, the pop-up window shows a XOOPS submission and then error. Any ideas on why this happens?

Here is the javascript code I'm using:

<SCRIPT LANGUAGE=JAVASCRIPT TYPE="TEXT/JAVASCRIPT">
function 
openWin() {
l=(screen.width-525)/2
t
=(screen.height-300)/2
a
=window.open('','paypal','width=525,height=300,left='+l+',top='+t);
document.forms[0].target='paypal';
setTimeout('document.forms[0].submit()',1000)
}
SCRIPT>

<
FORM target="paypal" action="https://www.paypal.com/cgi-bin/webscr" method="post">
<
input type="image" src="https://www.paypal.com/en_US/i/btn/x-click-but22.gif" border="0" name="submit" alt="Submit via PayPal" align="texttop" width="87" height="23" onClick="openWin()">
FORM>


If you'd like to take a look at the problem in action, here the WF-Section implementation: Failing Page

Here is a working version of the page, using TinyContent and an IFRAME to access the original page:
Work-around Page

Thanks in advance!

PS-it is safe to click the "Add to Cart" and "View Cart" buttons and open the shopping cart pop-up. Just don't go through the Paypal checkout unless you plan on donating money...




TopTop
(1) 2 3 »



Login

Who's Online

154 user(s) are online (105 user(s) are browsing Support Forums)


Members: 0


Guests: 154


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Nov 30
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits